Рівні журналу - Зворотний зв'язок - правильне зображення для призначення рівнів журналу

Я використовую логін в поточному проекті.

Він пропонує шість рівнів ведення журналу: TRACE DEBUG INFO WARN ERROR OFF

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

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

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

• помилка : система переживає проблеми, клієнти, мабуть, страждають (або скоро будуть), і виправлення, ймовірно, вимагає втручання людини. Тут діє правило "2:00" - якщо ви дзвоните, чи хочете ви прокинутися о 2:00, якщо ця умова станеться? Якщо так, то запишіть це як "помилку".

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

• info : речі, які ми хочемо побачити на великій гучності, якщо нам потрібно буде проаналізувати проблему. Сюди йдуть події життєвого циклу системи (запуск, зупинка системи). Сюди йдуть події життєвого циклу "сеанс" (вхід, вихід та ін.). Слід також враховувати значні граничні події (наприклад, дзвінки до бази даних, віддалені виклики API). Сюди можуть йти типові винятки для бізнесу (наприклад, помилка входу через погані облікові дані). Будь-яка інша подія, яку ви думаєте, що вам потрібно буде побачити у виробництві з великим обсягом, йде тут.

• налагодження : майже про все, що не робить "інформацію" вирізаною ... будь-яке повідомлення, яке корисно відстежувати потік через систему та виділяти проблеми, особливо під час етапів розробки та забезпечення якості. Ми використовуємо журнали рівня «налагодження» для входу / виходу більшості нетривіальних методів та маркування цікавих подій та точок прийняття рішень всередині методів.

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

Оскільки важливіше, ніж вибір правильних рівнів журналу, - це те, щоб журнали були значущими та мали необхідний контекст. Наприклад, ви майже завжди хочете включити ідентифікатор потоку в журнали, щоб ви могли дотримуватися одного потоку, якщо це потрібно. Ви також можете використовувати механізм для прив’язки інформації про бізнес (наприклад, ідентифікатор користувача) до потоку, щоб він також входив у систему. У своєму повідомленні журналу потрібно включити достатню кількість інформації, щоб переконатися, що повідомлення може бути доступним. Журнал на кшталт "FileNotFound виняток вилучений" не дуже корисний. Краще повідомлення - "Виняток FileNotFound, що потрапив під час спроби відкрити конфігураційний файл: /usr/local/app/somefile.txt. UserId = 12344."

Існує також ряд хороших посібників з ведення журналу ... Наприклад, ось відредагований фрагмент від JCL (Jakarta Commons Logging) :

• помилка - інші помилки виконання або несподівані умови. Очікуйте, що вони будуть відразу видно на консолі статусу.
• застереження - використання застарілих API, погане використання API, "майже" помилки, інші ситуації виконання, які є небажаними або несподіваними, але не обов'язково "неправильними". Очікуйте, що вони будуть відразу видно на консолі статусу.
• info - Цікаві події виконання (запуск / вимкнення). Очікуйте, що вони будуть помітні відразу на консолі, тому будьте консервативні і дотримуйтесь мінімуму.
• налагодження - детальна інформація про потік через систему. Очікуйте, що вони будуть записані лише в журнали.
• слід - більш детальна інформація. Очікуйте, що вони будуть записані лише в журнали.

Мій підхід, я думаю, що з точки зору операцій більше, ніж з точки зору операцій, такий:

• Помилка означає, що виконання якогось завдання не вдалося виконати; не вдалося надіслати електронний лист, не вдалося винести сторінку, деякі дані не вдалося зберегти в базі даних, щось подібне. Щось остаточно пішло не так.
• Попередження означає, що сталося щось несподіване, але виконання може тривати, можливо, у деградованому режимі; файл конфігурації відсутній, але використовувались параметри за замовчуванням, ціну розраховували як негативну, тому вона була затиснута до нуля і т. д. Щось невірно, але воно не пішло неправильно - попередження часто є ознакою того, що буде помилка дуже скоро.
• Інформація означає, що сталося щось нормальне, але значне; система запустилася, система зупинилася, щоденні завдання оновлення інвентаря виконувались і т. д. Не повинно бути постійного потоку таких, інакше читати просто забагато.
• Налагодження означає, що сталося щось нормальне та незначне; на сайт зайшов новий користувач, надіслана сторінка, прийнято замовлення, оновлена ​​ціна. Це речі, виключені з інформації, оскільки їх було б занадто багато.
• Трейс - це те, чого я ніколи фактично не використовував.

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

Наприклад :

• "Чи дійсно буде введено рядок коду журналу, який реєструється в WARN, на моєму розгортанні налаштовано ERROR?" У таблиці сказано: НІ.
• "Чи дійсно буде введено рядок коду журналу, який реєструється в WARN, на моєму розгортанні налаштовано DEBUG?" У таблиці сказано, ТАК.

з документації щодо зворотного зв'язку :

Більш графічно, ось як працює правило вибору. У наступній таблиці вертикальний заголовок показує рівень запиту реєстрації даних, позначений p, тоді як горизонтальний заголовок показує ефективний рівень реєстратора, позначений q. Перетин рядків (запит рівня) та стовпців (ефективний рівень) є булевим, що є результатом основного правила вибору.

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

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

• ПОМИЛКА - У цього компонента стався збій, і причина, як вважають, є внутрішньою (будь-яка внутрішня, необроблена виняток, збій інкапсульованої залежності ... наприклад, база даних, приклад REST, якщо він отримав 4xx помилку від залежності). Виведіть мене (підтримувача цього компонента) з ліжка.

• ПОПЕРЕДЖЕННЯ - Цей компонент мав помилку, спричинену залежним компонентом (прикладом REST було б статус 5xx від залежності). Встаньте обслуговуючого складу ТОГО компонента з ліжка.

• ІНФОРМАЦІЯ - Все, що ми хочемо дістати до оператора. Якщо ви вирішили реєструвати щасливі шляхи, то я рекомендую обмежитись 1 повідомленнями журналу на значну операцію (наприклад, на вхідний запит http).

Для всіх повідомлень журналу обов'язково записуйте корисний контекст (і надайте пріоритет для того, щоб зробити повідомлення зрозумілими / корисними для людей, а не мати пучки "кодів помилок")

• DEBUG (і нижче) - Не слід застосовувати взагалі (і, звичайно, не у виробництві). У розробці я б порадив використовувати комбінацію TDD та налагодження (де це необхідно) на відміну від забруднювального коду з операторами журналу. У виробництві вищевказаний журнал INFO у поєднанні з іншими показниками повинен бути достатнім.

Хороший спосіб візуалізації вищевказаних рівнів ведення журналу - це уявити набір екранів моніторингу для кожного компонента. Якщо все працює добре, вони зелені, якщо компонент записує ПОПЕРЕДЖЕННЯ, тоді він перейде в помаранчевий (бурштиновий), якщо що-небудь записує помилку, то він переходить у червоний колір.

У випадку інциденту у вас повинен бути один (першопричиною) червоний колір, а всі постраждалі компоненти повинні перейти в оранжевий / бурштиновий.

Не відрізняється від інших відповідей, у мене рамки майже однакові:

1. Помилка: критичні логічні помилки в застосуванні, наприклад, час очікування з'єднання з базою даних. Те, що вимагає виправлення помилок найближчим часом
2. Попередження: проблеми не порушують, але на що слід звернути увагу. Як і запитувана сторінка не знайдена
3. Інформація: використовується у функціях / методах перший рядок, щоб показати процедуру, яку було викликано, або якийсь крок вийшов нормально, як виконаний запит вставки
4. log: логічна інформація, як результат оператора if
5. налагодження: змінне вміст, релевантний для постійного перегляду