Согласно руководству :
Logback собирает свои внутренние данные состояния в объекте StatusManager, доступном через LoggerContext.
.StatusManager вы можете получить доступ ко всем данным состояния, связанным с контекстом возврата.Чтобы сохранить использование памяти на разумных уровнях, стандартная реализация StatusManager хранит сообщения о состоянии в двух отдельных частях: часть заголовка и хвостовая часть.Часть заголовка хранит первые H сообщений о состоянии, тогда как хвостовая часть хранит последние T сообщений.В настоящее время H = T = 150, хотя эти значения могут измениться в будущих выпусках.
Похоже, что цель состоит в том, чтобы позволить прослушивать входящие сообщения журнала, также просматривая их через сервлет.
В нашем случае мы используем logstash-logback-encoder и отправляем наши сообщения Logback на консоль, чтобы fluentd / Filebeat и т. Д. Могли отправлятьсяк удаленному Logstash - и поэтому нашим микросервисам нет необходимости проверять или прослушивать их.
Поэтому возникает вопрос: можем ли мы переопределить значение по умолчанию BasicStatusManager (с реализацией NOOP)для подавления внутреннего хранения этих сообщений, или кто-нибудь знает, зависит ли кодер Logstash, или подключается к самому механизму состояния?
Наши logback.xml довольно просты:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="lsAppender" class="ch.qos.logback.core.ConsoleAppender">
<encoder class="net.logstash.logback.encoder.LogstashEncoder"/>
</appender>
<logger name="a.b.c" level="debug"/>
<root level="debug">
<appender-ref ref="lsAppender"/>
</root>
</configuration>
Моя секунда причина для того, чтобы спросить, что мы недавно получили OOMEs от микросервисов с кучей 120 МБ.Конечно, эти отдельные сообщения журнала слишком велики, но это проблема, только если они задерживаются самим Logback, а не отсылаются и забываются.Это будет на одну проблему меньше масштабируемости.
Снимок экрана вывода YourKit:
