Найкращі практики ведення журналу та відстеження в .NET

Я багато читав про відстеження та ведення журналів, намагався знайти якесь золоте правило для найкращих практик у цьому питанні, але такого немає. Люди кажуть, що хороші програмісти дають хороші кадри, але це так, і це має виходити з досвіду.

Я також читав подібні запитання тут і через Інтернет, і вони насправді не те саме, про що я запитую, або не мають задоволеної відповіді, можливо тому, що на запитання не вистачає деталізації.

Отже, люди кажуть, що трасування має на зразок повторити досвід налагодження програми у випадках, коли ви не можете приєднати налагоджувач. Він повинен забезпечити достатній контекст, щоб ви могли бачити, який шлях пройдений у кожній контрольній точці програми.

Заглибившись, ви навіть можете розрізнити трасування та журнал подій, оскільки "журнал подій відрізняється від трасування тим, що він фіксує основні стани, а не детальний потік контролю".

Тепер, скажіть, я хочу робити свій пошук і ведення журналів, використовуючи лише стандартні класи .NET, ті, що знаходяться в System.Diagnosticsпросторі імен. Я зрозумів, що клас TraceSource краще для роботи, ніж статичний клас Trace, тому що я хочу диференціюватися між рівнями слідів і за допомогою класу TraceSource я можу передавати параметр, що інформує тип події, при цьому використовуючи клас Trace, який я повинен використовувати Trace.WriteLineIfа потім перевірити такі речі, як SourceSwitch.TraceInformationі SourceSwitch.TraceErrors, і навіть у них немає властивостей, як TraceVerboseабо TraceStart.

Зважаючи на це, чи вважаєте ви гарною практикою такі дії:

• Простежте подію "Пуск" під час запуску методу, який повинен представляти одну логічну операцію або конвеєр, а також рядкове подання значень параметрів, переданих методу.
• Простежте подію "Інформація", вставляючи елемент у базу даних.
• Простежте подію "Інформація" під час проходження того чи іншого шляху у важливому операторі if / else.
• Простежте "критичну" або "помилку" в блоці вилову залежно від того, чи є помилка, яку можна відновити.
• Простежте подію "Стоп", коли закінчуєте виконання методу.

А також, будь ласка, уточнюйте, коли найкраще простежити типи подій Verbose та Warning. Якщо у вас є приклади коду з гарним відстеженням / реєстрацією та готові поділитися, це було б чудово.

Примітка. Тут я знайшов хорошу інформацію, але все ще не те, що шукаю: http://msdn.microsoft.com/en-us/magazine/ff714589.aspx

Важливість типів слідів слід вибирати не тому, де слід знаходиться в коді, а тому, що відстежуване повідомлення має більш-менш важливе значення. Приклад:

Простежте подію "Пуск" під час початку методу, який повинен представляти одну логічну операцію або конвеєр, а також рядкове подання значень параметрів, переданих методу.

Використовуйте тип запуску під час запуску логічної операції. Це не означає, що початковий слід повинен знаходитись на початку методу, а також не повинен означати, що метод повинен мати початковий слід.

Це, в більшості випадків, логічна операція дійсно розпочнеться на початку методу. В іншому випадку слід запитати себе, чи правильно відремонтовано код.

Параметри відстеження також можуть бути поганою ідеєю . Ви повинні подумати, що простежити, від випадку до випадку. Наприклад, дуже погано відстежувати параметри методу void Authenticate(string userName, string plainPassword).

Простежте подію "Інформація", вставляючи елемент у базу даних.

Це залежить. Деякі елементи повинні бути простежені, але не кожен.

• Наприклад, уявіть, що ви фактично вставляєте елемент журналу у свою базу даних. Ви б простежили журнали? А потім журнали слідів? А потім простежити реєстрацію сліду?
• Інший приклад: ви вставляєте конфіденційні дані. Для цього потрібен аудит. Оскільки ви перевіряли вставку, навіщо її відстежувати?

Простежте подію "Інформація" під час проходження того чи іншого шляху у важливому операторі if / else.

Знову ж таки, це залежить.

Простежте "критичну" або "помилку" в блоці вилову залежно від погоди, це помилка, яку можна виправити.

Дія, вжита після непоправної помилки, може бути більше, ніж простежити. Наприклад, на стороні сервера, ви хочете зберегти виняток у базі даних для подальшого аналізу. Також деякі винятки менш важливі, ніж інші, і не вимагають їх відстеження.

Простежте подію "Стоп", коли закінчуєте виконання методу.

Дивіться перший пункт.

будь ласка, уточнюйте, коли найкраще простежити типи подій у верболозі та попередженні

Багатослівний:

Дослідне слово використовується для того, щоб простежити, що потрібно простежити, коли щось піде не так. Це означає, що в більшості випадків ви відключите відслідковування багатослівних повідомлень, але іноді вам доведеться налагоджувати деякі частини коду, щоб зрозуміти, чому щось не виходить у кращому регістрі.

Зазвичай у вас є багато багатослівних повідомлень, які дозволяють вам дуже добре зрозуміти потік додатків. Це також означає, що ці повідомлення повинні бути відключені більшу частину часу, оскільки:

• інакше журнал буде рости дуже швидко,
• вони вам не потрібні більшість часу,
• вони можуть містити конфіденційні дані про потік додатків.

Подумайте про багатослівність як про інструмент, який ви повинні використовувати, коли у вас немає доступу до налагоджувача.

Увага:

Шлях типу попередження використовується, коли трапляється щось не так і важливе, але не є надто важливим, щоб трактуватись як помилку. Наприклад, низька оперативна пам'ять може надсилати попередження, але немає причин простежувати помилку, оскільки ваше додаток може продовжуватися, навіть якщо воно буде повільніше, ніж зазвичай.

Приклади:

• Приклад 1: програма не відкрила файл, який користувач просив відкрити. Файл існує і не використовується, дозволи встановлені правильно, але щось блокує відкриття файлу. У цьому випадку ви простежите помилку , оскільки ваша програма не може керувати цією справою і продовжує працювати так, як очікував користувач (тобто фактично читає файл).

• Приклад 2: після перевірки помилки в першому прикладі ви виявите, що помилка викликана тим, що шлях до файлу довший 259 символів. Таким чином, ви рефакторний код, щоб зловити PathTooLongException. Коли в наступний раз користувач намагається відкрити той самий файл, у новій версії програми з'являється повідомлення, що пояснює, що файл занадто довгий і його потрібно перенести в іншу папку, щоб скоротити повний шлях, щоб відкрити цей файл у ця програма. Ви також відстежуєте повідомлення .

• Приклад 3: Ваша програма провела двадцять секунд, відкриваючи та аналізуючи невеликий файл, тоді як для більшості файлів потрібно десять-сто мілісекунд, щоб відкрити та проаналізувати. Ви відстежуєте попередження відповідною інформацією: тип диска, де файл насправді є, файлова система, розмір файлу, точний витрачений час, час роботи комп'ютера тощо. Коли користувач скаржиться, що йому потрібно двадцять секунд, щоб відкрити файл, ви знайдете слід, щоб знайти, що відбувається. Ви виявляєте, наприклад, що завантаження файлів із мережевого спільного доступу займає стільки часу, коли комп'ютер тільки запустився. Ви пояснюєте користувачеві, що затримка пов’язана з мережею і не пов'язана з вашою заявою.

• Приклад 4: відкритий файл відображається неправильно. Ви включаєте багатослівний слід, де ви дійсно бачите, як дані завантажуються з файлу та потім аналізуються, крок за кроком.

 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics це чудово, тому що ви можете налаштувати, куди слід відстежувати інформацію (файл, eventlog, база даних, ....)

На жаль, якщо ви хочете скористатись, System.Diagnosticsви повинні заздалегідь знати ( у призначений час ), які потоки слідів слід прослідкувати. (У прикладі статті це передача, відновлення, призупинення, ...). Вони можуть бути налаштовані для вимкнення, відлагодження або помилки.

Я вважаю за краще мати систему ведення журналів, де я можу вирішити під час виконання на classlevel / namespacelevel , наскільки детальною повинна бути реєстрація. Наприклад, всі налагодження і вище від, MyNamespace.Business.*але ні MyNamespace.Business.Calculations.

Якщо ви використовуєте log4net (або Common.logging), кожен клас отримує свій власний реєстратор, тож ви зможете легко визначити, які класи будуть реєструватися на якому рівні.

Оскільки операції з базою даних перебувають в окремому класі, більше немає необхідності в окремому правилі

Trace an "Information" event when inserting an item into the database.

Натомість я вважаю за краще:

• Tracelevel повинен показувати основний робочий процес
• Debuglevel повинен показувати детальні дані та обробку в робочому процесі, включаючи рішення в програмному потоці з причинами (Створення нового елемента, оскільки елемент не існував у БД)
• Інформаційний рівень для запуску / зупинки послуг та один запис для кожного запущеного робочого процесу / GUI

Ви можете випробувати рамку Story , вона має унікальний підхід до ведення журналів, оскільки "змушує" ви писати всі журнали (і додавати іншу відповідну інформацію) в контексті, тож коли вам потрібно буде прочитати її пізніше, ви отримаєте все необхідне.

Це автоматично додасть поняття "початок" і "стоп" як початок і кінець історії.

А за допомогою системи, заснованої на правилах, ви можете керувати тим, що робити з кожною історією (контекстом), виходячи з інформації, яку вона має, наприклад, надрукувати всі історії, які мають помилку або походять від користувача "адміністратора".

Також більше інформації про це повідомлення в блозі