Лучшие практики использования маркеров в SLF4J / Logback

Question

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

Что я хочу знать, так это то, что кто-то в сообществе действительно использует эти функции и как они используются для улучшения ведения журнала / фильтрации.

Меня особенно интересует, где, почему и как можно использовать ^[1] Маркеры для регистрации.Они кажутся мне довольно удобной функцией для добавления семантического контекста в журналирование - например, когда класс может обрабатывать несколько задач, можно использовать специальные маркеры задачи / задачи для различения операторов журнала.

Что может быть лучшимпрактики, соглашения или стратегии для создания и использования маркеров при ведении журнала.

Обновление: Полагаю, что я действительно ищу, это не так много , почему использовать маркеры,а скорее часть how - есть ли хорошие практики именования маркеров (например, использование обычного текста с пробелами или имен стилей ключевых слов с разделителями в виде тире / подчеркивания / пунктуации), если существует какой-то пул «стандартных имен»", называя вещи, основанные на бизнес-функциях.Вопросы, которые я, вероятно, могу выяснить для себя, но если я хочу систематически использовать эти функции и представить их команде разработчиков, имеет смысл иметь некоторый формализуемый набор руководящих принципов ...

---

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

Answer 1

Во-первых, как сказал @darioo:

• MDC используется для связывания нескольких событий с несколькими «сущностями»
• [Маркеры] используются для «специальных» событий, которые вы хотитеотфильтровать от обычных

Итак, ваше утверждение, что вы хотите использовать MDC для этого.Маркеры предназначены для выделения «специальных» событий - фильтрации, если хотите - вместо «нарезки».Например, вы можете срезать на основе конкретного пользователя, но фильтровать на основе любых непредвиденных исключений.В этом случае вы бы создали User MDC измерение и UnexpectedException Marker.

---

Но, очевидно, это не решает вопрос, который вы имели в виду,Вы «скорее ссылаетесь на более общий уровень того, как можно настроить ведение журнала с использованием маркеров последовательно».Итак, обратимся к следующему:

MDC для нарезки и нарезки , а маркеры для фильтрации . Эти действия выполняются во время испытаний и на производстве .Таким образом, вам нужно решить, какие измерения, по вашим ожиданиям, могут быть полезны для нарезки данных журнала, и в каких случаях было бы полезно отфильтровать их, когда начнется тестирование / производство. Каждое измерение получает измерение MDC.Каждый случай получает Маркер. Это так просто.

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

Этот же человек или группа должны принять решение по соглашению об именах. Это совершенно произвольно .Выберите что-то, что эстетично, , информативно (самое важное) и достаточно конкретное, чтобы не вступать в конфликт с последующими дополнениями.Подчеркивание в дефисах против чрезвычайно придирчиво и тревожно не относится к делу, но обратите внимание, что сотрудники ESL могут быть менее запутанными при чтении подчеркиваний (по крайней мере по сравнению с CamelCase);в то же время это, как сообщается, раздражает некоторых разработчиков из-за неловкости в достижении необходимых ключей.

Что касается выбора политики, то это просто означает определение, в каких случаях данное измерение маркера или MDCдолжен быть занят .Держите это строго (централизованно, преднамеренно), но учитывайте обратную связь от разработчиков, если они чувствуют, что набор измерений и маркеров недостаточен для поставленной задачи.Пересмотрите / добавьте размеры и / или атрибуты в зависимости от ситуации.

Поймите Эта политика почти обязательно будет зависеть от проекта .Не каждый проект требует такого же анализа журналирования.Изобразите некоторые кошмарные сценарии.Затем представьте, как вы хотели бы иметь возможность анализировать журналы в этом сценарии.Вы, вероятно, не хотите писать сложный сценарий, чтобы попытаться отследить, какое сообщение принадлежит какому контексту и какое состояние в какое время и в какое время, верно?Кодируйте любую необходимую информацию, такую ​​как размеры и маркеры, и избавьте себя от хлопот, если что-то пойдет не так.

Answer 2

Во-первых, 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 используется для связывания нескольких событий с несколькими «сущностями»
• маркеры используются для "особых" событий, которые вы хотите отфильтровать от обычных

Answer 3

Маркеры могут использоваться для цвета или для отметки одного оператора журнала.Что вы делаете с этими цветами, то есть маркерами, полностью зависит от вас.Тем не менее, два шаблона, как представляется, являются общими (первый более распространенный, чем второй) для использования маркера.

1. Запуск : Некоторому аппендиату может быть дано указание предпринять действиепри наличии определенного маркера.Например, SMTPAppender можно настроить для отправки электронной почты всякий раз, когда событие регистрации помечается маркером NOTIFY_ADMIN независимо от уровня журнала.См. запуск на основе маркера в документации по возврату.Вы также можете комбинировать уровни журналов и маркеры для запуска.

2. Фильтрация : Вы можете, например, раскрасить / пометить все свои журналы, связанные с постоянством (в различных и нескольких файлах классов).) с цветом "БД".Затем можно выполнить фильтрацию по «БД»: отключить ведение журнала, за исключением операторов журнала, помеченных знаком БД.См. Главу о фильтрах в документации журнала для получения дополнительной информации (поиск MarkerFilter).

Answer 4

Точно так же, как дополнение, если вы используете logstash и включили ведение журнала json, есть еще одно потенциальное использование Marker - для регистрации переменных, связанных с конкретным сообщением журнала. Это более согласованно и проще для анализа, чем включение его в тело сообщения. Очень полезно, если оно подходит для вашего варианта использования.

Подробнее см. Здесь:

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