Найкращі практики використання маркерів у SLF4J / Logback

Ми вже деякий час використовуємо комбінацію SLF4J + Logback у нашому проекті і дуже задоволені цим, але наша стратегія ведення журналів досить проста, використовуючи прості реєстратори на основі класу та ніяких фантазійних речей, таких як MDC чи маркери.

Що я хочу знати, якщо хтось із спільноти насправді використовує ці функції та як вони використовуються для покращення журналу / фільтрації.

Мене спеціально цікавить, де, чому і як можна використовувати ^[1] Маркери для ведення журналів. Вони вважають мене досить акуратною особливістю для додавання семантичного контексту в журнал - наприклад, хоча клас може обробляти багато питань, можна використовувати конкретні маркери завдання / занепокоєння для дискримінації операторів журналу.

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

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

^[1] - Запитуючи, як використовувати маркери, я насправді не запитую, як використовувати API (це насправді досить прямо) - я скоріше маю на увазі більш загальний рівень того, як можна налаштувати ведення журналу, використовуючи маркери послідовно

По-перше, як сказав @darioo:

• MDC використовується для асоціації кількох подій з кількома "сутностями"
• [Маркери] використовуються для "спеціальних" подій, які ви хочете відфільтрувати зі звичайних

Отже, ваше твердження, що ви хочете використовувати для цього MDC. Маркери призначені для виділення "спеціальних" подій - фільтрування, якщо ви хочете - а не для "нарізки". Наприклад, ви можете нарізати фрагмент на основі конкретного користувача, але відфільтрувати за будь-якими несподіваними винятками. У цьому випадку ви створили б розмір MDC користувача та маркер несподіваного збільшення .

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

MDC призначений для нарізки та нарізки , а маркери - для фільтрації . Ці заходи проводяться під час випробувань та у виробництві . Таким чином, вам потрібно вирішити, за якими розмірами, на вашу думку, може бути корисним нарізати дані журналу, і в яких випадках може бути корисно відфільтрувати їх, коли відбувається тестування / виробництво. Кожен вимір отримує розмір MDC. Кожен випадок отримує маркер. Це так просто.

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

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

Що стосується прийняття рішення про політику, це просто означає визначення того, в яких випадках потрібно використовувати заданий розмір Маркер або МДЦ . Тримайте це чітко (централізовано, навмисно), але дозволяйте отримувати зворотній зв'язок від розробників, якщо вони вважають, що набір габаритів і маркерів недостатній для виконання завдання. Перегляньте / додайте параметри та / або атрибути, якщо це доречно.

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

По-перше, MDC.

MDC дійсно корисний у середовищі, коли у вас є одна "сутність", яка пов'язана з деякою поведінкою. Типовий приклад: користувач взаємодіє з веб-додатком. Отже, скажімо, у вас багато користувачів, що вадять веб-додаток. Використовуючи MDC, ви можете легко відстежувати їх без зайвих клопотів. Спрощений приклад:

...[Sandy][abcd] clicked on "change profile"
...[Joe][1234] clicked on "weather reports"
...[Joe][1234] clicked on "Europe"
...[Sandy][abcd] clicked on "logout"
...[Joe][1234] clicked on "logout"
...[Sandy][efgh] logged in

Тут ви використовуєте MDC у двох місцях: для імені користувача та для ідентифікатора сесії. Таким чином, ви можете легко зібрати сеанс одного користувача, щоб побачити все, що вони роблять.

По-друге, маркери.

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

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

Практичне правило:

• MDC використовується для асоціації кількох подій з кількома "сутностями"
• маркери використовуються для "спеціальних" подій, які ви хочете відфільтрувати зі звичайних

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

1. Запуск : деякого додатка можна доручити вжити заходів за наявності певного маркера. Наприклад, SMTPAppenderможе бути налаштовано для надсилання електронного листа кожного разу, коли подія реєстрації позначена NOTIFY_ADMINмаркером незалежно від рівня журналу. Див. Ініціювання на основі маркера в документації із зворотного зв'язку. Ви також можете комбінувати рівні журналів та маркери для запуску.

2. Фільтрування : Ви можете, наприклад, розфарбувати / позначити всі ваші журнали, пов’язані зі стійкістю (у файлах різних класів та декількох класів) кольором "DB". Потім можна фільтрувати за "DB": відключити ведення журналу, за винятком виписок журналу, позначених DB. Для отримання додаткової інформації дивіться розділ про фільтри в документації для зворотного зв'язку (шукайте MarkerFilter).

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

Деталі дивіться тут:

https://github.com/logstash/logstash-logback-encoder#loggingevent_custom_event