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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробности здесь:

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