log4j - адаптивный уровень журнала - функция

Question

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

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

Наша система использует log4j.

Основной корень проблемы заключался в том, что первоначальные разработчики были, мягко говоря, «экономичными» при обнаружении неизвестной ошибки. Конечно, уровень DEBUG будет полезен в большинстве случаев, но, конечно, производственные журналы устанавливаются только на уровне ОШИБКИ: (

Теперь я пытаюсь сделать мир лучше для наших детей и хочу расширить систему ведения журналов, чтобы быть более «прощающей» в отношении уровня ведения журнала.

То, что я имею в виду, выглядит так:
Поскольку окружающие журналы уровня DEBUG (N до и M после журнала ERROR) могут содержать важные данные, почему бы не понизить уровень журнала системы вокруг ERROR.

Моя идея:

1. давайте предположим, что уровень журнала ERROR установлен для системы
2. использовать какой-нибудь буфер записи ролловера размера X. Каждый журнал входит туда и пересылается в log4j.
3. Когда буфер получает журнал ERROR, он также может выводить контекст N предыдущих и M следующих сообщений журнала либо
   1. искусственно поднимая уровень журнала до состояния ОШИБКИ (и, конечно, отмечая это) или
   2. просто зарегистрируйте этот контекст через введенный журнал ERROR

Есть некоторые проблемы, которые нужно решить, но в целом это может сработать.

Есть идеи?

Приветствия

Answer 1

BufferingForwardingAppender может быть решением.Документация, связанная с примером, гласит: «Это означает, что события будут доставлены, только когда будет зарегистрировано сообщение с уровнем WARN или более высоким уровнем. До 512 (BufferSize) предыдущих сообщений любого уровня также будет доставлено для предоставления контекстной информации.Не отправленные сообщения будут отброшены. "

См .: http://logging.apache.org/log4net/release/config-examples.html#buffering

Для загруженных веб-приложений это, вероятно, не лучший подход.В большинстве случаев вас интересуют сообщения журнала, связанные с конкретным сеансом или запросом, вызвавшим ОШИБКУ.Поскольку один запрос обычно обрабатывается одним потоком, это может быть достигнуто путем сохранения буфера «на поток» для сообщений журнала.Добавляя фильтр сервлетов, можно очищать буфер каждый раз, когда сервер начинает обрабатывать новый запрос от клиента.

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