Коли використовувати різні рівні журналу

Існують різні способи реєстрації повідомлень у порядку фатальності:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Як вирішити, коли використовувати який?

Що добре використовувати евристику?

Я, як правило, підписуюся на наступну конвенцію:

• Trace - Тільки тоді, коли я б "простежував" код і намагався знайти одну частину функції конкретно.
• Налагодження - інформація, яка діагностично допомагає людям більше, ніж просто розробникам (IT, sysadmins тощо).
• Інформація - загально корисна інформація для ведення журналу (старт / зупинка послуги, припущення щодо конфігурації тощо). Інформація, яку я хочу завжди мати, але зазвичай це не турбується за звичайних обставин. Це мій вихідний рівень конфігурації.
• Попереджаю - все, що потенційно може спричинити диваки у застосуванні, але я автоматично одужую. (Наприклад, перехід з основного на резервний сервер, повторна операція, відсутні вторинні дані тощо)
• Помилка - будь-яка помилка, фатальна для операції , але не служба або додаток (не вдається відкрити потрібний файл, відсутні дані тощо). Ці помилки змусять втручання користувача (адміністратора чи прямого користувача). Зазвичай вони зарезервовані (у моїх програмах) для неправильних рядків з'єднання, відсутніх служб тощо.
• Фатальна - будь-яка помилка, яка змушує відключити послугу чи додаток для запобігання втрати даних (або подальшої втрати даних). Я залишаю за собою лише найбільш грізні помилки та ситуації, коли гарантується, що сталося пошкодження чи втрата даних.

Ви хочете, щоб повідомлення про те, щоб посеред ночі встати з ліжка системного адміністратора?

• так -> помилка
• ні -> попереджають

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

Фатальний / критичний : Загальна несправність програми або системи, яку слід негайно дослідити. Так, прокинься SysAdmin. Оскільки ми віддаємо перевагу нашим сповіщенням SysAdmins та добре відпочившим, цю суворість слід застосовувати дуже рідко. Якщо це відбувається щодня і це не BFD, це втрачає сенс. Зазвичай фатальна помилка трапляється лише один раз у процесі роботи, тому якщо файл журналу прив’язаний до процесу, це, як правило, останнє повідомлення в журналі.

Помилка . Однозначно проблема, яку слід дослідити. Про SysAdmin слід отримувати сповіщення автоматично, але його не потрібно перетягувати з ліжка. Фільтруючи журнал для перегляду помилок і вище, ви отримуєте огляд частоти помилок і можете швидко визначити ініціюючий збій, який міг призвести до каскаду додаткових помилок. Коефіцієнт помилок відстеження в порівнянні з використанням програми може дати корисні показники якості, такі як MTBF, які можна використовувати для оцінки загальної якості. Наприклад, цей показник може допомогти інформувати рішення про те, чи потрібен інший цикл бета-тестування перед випуском.

Попередження : ЦЕ МОЖЕ бути проблемою, а може й ні. Наприклад, очікувані перехідні умови навколишнього середовища, такі як коротка втрата підключення до мережі або бази даних, слід записувати як попередження, а не помилки. Перегляд журналу, відфільтрованого для відображення лише попереджень та помилок, може дати швидке розуміння ранніх підказок про першопричину наступної помилки. Попередження слід використовувати ощадливо, щоб вони не стали безглуздими. Наприклад, втрата доступу до мережі повинна бути попередженням або навіть помилкою в серверній програмі, але може бути лише інформацією в настільному додатку, призначеному для випадкових відключених користувачів ноутбуків.

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

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

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

Ось перелік того, що мають "лісоруби".

Apache log4j: §1 , §2

1. FATAL:

   [ v1.2 : ..] дуже серйозні події помилок, які, ймовірно, призведуть до того, що програма скасовує.

   [ v2.0 : ..] сильна помилка, яка не дозволить додатку продовжуватися.

2. ERROR:

   [ v1.2 : ..] події помилок, які все ще можуть дозволяти програмі продовжувати працювати.

   [ v2.0 : ..] помилка в додатку, можливо, виправлена.

3. WARN:

   [ v1.2 : ..] потенційно шкідливі ситуації.

   [ v2.0 : ..] подія, яка може [ sic ] призвести до помилки.

4. INFO:

   [ v1.2 : ..] інформаційні повідомлення, які висвітлюють хід роботи програми на грубозернистому рівні.

   [ v2.0 : ..] подія з інформаційною метою.

5. DEBUG:

   [ v1.2 : ..] дрібнозернисті інформаційні події, які найкорисніші для налагодження програми.

   [ v2.0 : ..] загальна подія налагодження.

6. TRACE:

   [ v1.2 : ..] дрібнозернисті інформаційні події, ніж DEBUG.

   [ v2.0 : ..] дрібнозернисте повідомлення про налагодження, як правило, фіксуючи потік через додаток.

Apache Httpd (як завжди) любить піти на надмір: §

1. виникають :

   Надзвичайні ситуації - система непридатна.

2. попередження :

   Дія повинна бути вжита негайно [але система все ще доступна].

3. критичний :

   Критичні умови [але вживати заходів не потрібно негайно].

   • " socket: не вдалося отримати розетку, що виходить з дитини "

4. помилка :

   Умови помилок [але не критичні].

   • " Передчасний кінець заголовків сценарію "

5. попередити :

   Умови попередження. [близько до помилки, але не помилки]

6. повідомлення :

   Нормальний, але значний [ помітний ] стан.

   • " httpd: спіймано SIGBUS, намагаючись скинути ядро ​​у ... "

7. інформація :

   Інформаційна [і непомітна].

   • [" Сервер працює протягом x годин. "]

8. налагодження :

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

   • " Відкриття конфігураційного файлу ... "

9. trace1 → trace6 :

   Повідомлення про відстеження [тобто повідомлення, що реєструються задля відстеження ].

   • " проксі: FTP: з'єднання управління завершено "
   • " проксі: CONNECT: надсилання запиту CONNECT на віддалений проксі "
   • " openssl: Handshake: start "
   • " читати з буферизованої бригади SSL, режим 0, 17 байт "
   • "Пошук карти не вдався:map=rewritemap key=keyname "
   • " пошук кешу не вдався, примушуючи шукати нову карту "

10. trace7 → trace8 :

    Простежте повідомлення, скидаючи велику кількість даних

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache commons-logging: §

1. смертельний :

   Сильні помилки, які спричиняють передчасне припинення. Очікуйте, що вони будуть відразу видно на консолі статусу.

2. помилка :

   Інші помилки виконання або несподівані умови. Очікуйте, що вони будуть відразу видно на консолі статусу.

3. попередити :

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

4. інформація :

   Цікаві події виконання (запуск / вимкнення). Очікуйте, що вони будуть помітні відразу на консолі, тому будьте консервативні і дотримуйтесь мінімуму.

5. налагодження :

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

6. слід :

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

"Кращі практики" для використання корпорацією Apache commons-logging розрізняють налагодження та інформацію залежно від того, які межі вони перетинають.

Межі включають:

• Зовнішні межі - очікувані винятки.

• Зовнішні межі - несподівані винятки.

• Внутрішні межі.

• Значні внутрішні межі.

(Див. Посібник із загального журналу для отримання додаткової інформації про це.)

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

Я б рекомендував прийняття рівнів серйозності Syslog: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Дивіться http://en.wikipedia.org/wiki/Syslog#Severity_levels

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

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

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

Наприклад, скажімо, що ви вводите / імпортуєте ім’я "Angela Müller"у свою програму (зверніть увагу на вступник над u). Ваш код / ​​база даних може бути лише англійською мовою (хоча це, мабуть, не повинно бути в цей день і вік), і тому може попередити, що всі "незвичні" символи були перетворені на звичайні англійські символи.

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

Як говорили інші, помилки - це проблеми; попередження - це потенційні проблеми.

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

Але так, це зводиться до аспектів відновлення та актуальності. Якщо ви зможете відновитись, це, мабуть, попередження; якщо це призводить до того, що щось насправді виходить з ладу, це помилка.

Я думаю, що ПОЗИЦІЯ про рівні SYSLOG та ALERT / EMERGENCY значною мірою зайві для ведення журналів на рівні додатків - в той час як CRITICAL / ALERT / EMERGENCY можуть бути корисними рівнями попередження для оператора, які можуть викликати різні дії та сповіщення, адміністратору програми все те саме, що FATAL. І я просто не можу в достатній мірі розрізнити отримання повідомлення або певної інформації. Якщо інформація не заслуговує уваги, це насправді не інформація :)

Мені найбільше подобається інтерпретація Джея Сінкотти - відстеження виконання коду - це щось дуже корисне в технічній підтримці, і слід вдосконалювати введення коду слідів у код, особливо в поєднанні з динамічним механізмом фільтрації для реєстрації повідомлень про сліди від конкретних компонентів програми. Однак рівень DEBUG для мене вказує на те, що ми все ще знаходимо процес з'ясування того, що відбувається - я бачу вихід DEBUG як варіант, який є лише розвитком, а не як щось, що коли-небудь повинно з’являтися у виробничому журналі.

Однак є рівень реєстрації, який мені подобається бачити в моїх журналах помилок під час носіння капелюха sysadmin стільки, скільки у технічної підтримки або навіть розробника: OPER, для ОПЕРАЦІЙНИХ повідомлень. Це я використовую для реєстрації часової позначки, типу операції, що викликається, наданих аргументів, можливо, (унікального) ідентифікатора завдання та виконання завдання. Він використовується, коли, наприклад, звільняється автономна задача, що є справжньою викликом з-за великого довго працюючого додатка. Це те, про що я хочу завжди реєструватися, незалежно від того, що щось піде не так, чи ні, тому я вважаю, що рівень OPER є вищим за FATAL, тому ви можете вимкнути його, лише перейшовши на повністю безшумний режим. І це набагато більше, ніж прості дані журналу INFO - рівень журналу часто зловживають для створення спам-журналів із незначними операційними повідомленнями, які не мають жодної історичної цінності.

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

З RFC 5424, протокол Syslog (IETF) - Сторінка 10:

Кожне повідомлення "Пріоритет" також має десятковий індикатор рівня серйозності. Вони описані в наступній таблиці разом з їх числовими значеннями. Значення тяжкості ОБОВ'ЯЗКОВО повинні бути в межах від 0 до 7 включно.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

День,

Як наслідок цього питання, повідомте свої інтерпретації рівнів журналу та переконайтесь, що всі люди в проекті вирівняні у своїй інтерпретації рівнів.

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

Надайте, якщо можливо, приклади різних рівнів ведення журналу. І будьте послідовними в інформації, яку потрібно увійти в повідомлення.

HTH

Я повністю згоден з іншими, і думаю, що GrayWizardx сказав це найкраще.

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

Тепер ви можете зрозуміти, що може бути фатальним? Ви знаєте, що фатально означає, чи не так? Отже, які пункти у вашому списку є фатальними.

Гаразд, це фатально розібралося, тепер давайте розглянемо помилки ... промийте та повторіть.

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

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

Ось кілька прикладів:

Фатально - не може виділити пам'ять, базу даних тощо - не може продовжуватися.

Помилка - немає відповіді на повідомлення, трансакція перервана, не вдається зберегти файл тощо.

Попередження - розподіл ресурсів досягає X% (скажімо, 80%) - це ознака того, що ви можете змінити розмір свого.

Інформація - користувач увійшов / вийшов, нова транзакція, файл, створений у файлі, нове поле d / b або поле видалено.

Налагодження - дамп внутрішньої структури даних, рівень Any Trace з назвою файлу та номером рядка.
Простежити - дія вдалася / не вдалася, оновлено оновлення d / b.

Помилка - це щось неправильне, явно неправильне, ніякого способу цього не потрібно, і це потрібно виправити.

Попередження - це знак шаблону, який може бути неправильним, але тоді також може бути.

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

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

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

Я будував системи до цього, використовуючи наступне:

1. ПОМИЛКА - означає, що щось серйозно не так, і конкретна тема / процес / послідовність не може продовжуватись. Потрібно певне втручання користувача / адміністратора
2. ПОПЕРЕДЖЕННЯ - щось невірно, але процес може тривати, як і раніше (наприклад, одна робота в наборі 100 не вдалася, але решту можна обробити)

У створених мною системах адміністратори проходили інструкцію щодо реагування на ПОМИЛКИ. З іншого боку, ми б спостерігали за ПОПЕРЕДЖЕННЯми та визначали для кожного випадку, чи потрібні якісь зміни системи, переналаштування тощо.

До речі, я великий шанувальник захоплення всього та фільтрування інформації пізніше.

Що буде, якщо ви захопили на рівні попередження і хочете отримати інформацію про налагодження, пов’язану з попередженням, але не змогли відтворити попередження?

Зробіть все і відфільтруйте пізніше!

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

Захопіть усе і фільтруйте пізніше !!

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

Мої два центи про рівні FATALта TRACEжурнал помилок.

ERROR це коли трапляються якісь ПОМИЛКИ (винятки).

FATAL насправді ДВОЙНА НЕПРАВИЛЬНА: коли винятки виникають під час обробки виключення.

Це легко зрозуміти для веб-сервісу.

1. Запит приходить. Подія реєструється якINFO
2. Система виявляє мало місця на диску. Подія реєструється якWARN
3. Для обробки запиту викликається деяка функція. Поки відбувається ділення на нуль. Подія реєструється якERROR
4. Обробник винятків веб-служби називається для обробки поділу на нуль. Веб-служба / фреймворк надсилатиме електронну пошту, але це не може, оскільки служба поштового зв’язку зараз офлайн. Цей другий виняток не може оброблятися нормально, оскільки обробник винятків веб-служби не може обробляти винятки.
5. Називається інший обробник винятків. Подія реєструється якFATAL

TRACEце коли ми можемо простежити вхід / вихід функції. Йдеться не про ведення журналів, оскільки це повідомлення може генеруватися деяким налагоджувачем, а ваш код взагалі не закликає log. Тож повідомлення, які не належать до вашої програми, позначаються як TRACEрівень. Наприклад, запустіть свою програму за допомогоюstrace

Так зазвичай у вашій програмі ви робите DEBUG, INFOі WARNведення журналу. І лише якщо ви пишете якусь веб-службу / рамку, яку будете використовувати FATAL. А під час налагодження програми ви отримаєте TRACEвхід із цього типу програмного забезпечення.

Я пропоную використовувати лише три рівні

1. Фатальна - Що б порушило додаток.
2. Інформація - Інформація
3. Налагодження - Менш важлива інформація