структурированная / комбинированная регистрация с Log4J

Question

Надеюсь, вы мне поможете.

У меня есть веб-сервис, который должен регистрировать транзакции. Поскольку имеется много обращений, операторы журнала кажутся несвязанными / фрагментированными в файле журнала.

Я рассмотрел прохождение экземпляра StringBuilder через слои и добавление операторов к этому экземпляру, затем я записываю его содержимое один раз в самом конце (предложение finally в главном контроллере) перед возвратом ответа клиенту. Это кажется ненужным, и я уверен, что есть более чистый способ сделать это с Log4J.

Может кто-нибудь пролить свет на эту проблему?

Спасибо

Answer 1

хорошо то, что вы используете Log4j. Сама библиотека реализует понятие вложенного диагностического контекста (org.apache.log4j.NDC) и отображенного диагностического контекста (org.apache.log4j.MDC). Я считаю, что вам определенно стоит взглянуть на оба, потому что они позволяют вам создать некоторый контекст, который вы можете использовать в макете вывода журнала.

Answer 2

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

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

grep userId *.log

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

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

Answer 3

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

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

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

Answer 4

Еще одна идея, вместо того, чтобы передавать экземпляр StringBuilder через слои, что может привести к довольно неловкому API (дополнительные параметры метода), вы можете рассмотреть возможность использования java.lang.ThreadLocal для хранения текущего контекста это может быть сброшено в журнал в самом конце.

Answer 5

Нам нужно было решить нечто подобное в прошлом. Мы создали конвертированный объект сообщения, содержащий также метаданные о сообщении (например, идентификатор пользовательской транзакции) и пользовательский класс appender. В этом классе appender мы используем оператор instanceof для получения метаданных из конверта, вместо этого просто вызывая toString (который должен вернуть хороший журнал для обычных appenders).

Или вы можете рассмотреть возможность использования SLF4J, и это стандартная возможность передавать Marker объекты с сообщениями журнала. Например. см. Javadoc для их отладки (маркерный маркер, строковое сообщение) перегрузка метода.