Рекомендации по использованию маркеров в SLF4J/Logback

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Но это, по-видимому, не затрагивает вопрос, который вы имели в виду. Вы скорее ссылаетесь на более общий уровень того, как можно настроить ведение журнала с использованием маркеров последовательно ". Поэтому позвольте адресовать, что:

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

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

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

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

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

Ответ 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 в двух местах: для имени пользователя и для идентификатора сеанса. Таким образом, вы можете легко grep один сеанс пользователя увидеть все, что они делали.

Во-вторых, маркеры.

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

Или, когда пользователь выходит из вашей службы, он обычно переходит в журнал INFO, но вы также можете использовать маркер для таких экземпляров, если вы хотите, чтобы такие события, как этот, отправлялись в отдельный файл журнала, так что вы может легче контролировать его для статистического сбора пользователей, покидающих.

Общее правило:

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

Ответ 3

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

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

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

Ответ 4

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

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

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