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

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



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



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



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



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




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

741   4  

4 ответов:

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

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

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

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

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

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

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

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

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

86  
2014-04-10 21:32:35

во-первых, 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 используется для связывания нескольких событий с несколькими "сущностями"
  • маркеры используются для "специальных" событий, которые вы хотите отфильтровать от обычных
63  
2010-11-12 19:18:42

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

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

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

26  
2013-05-29 21:04:42

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

подробнее здесь:

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

7  
2015-04-09 14:23:45

Comments

    Ничего не найдено.
Click here to cancel reply.