Рекомендации по использованию маркеров в 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