Flume Appender Проблема: потоки приложений зависают, когда агенты Flume не работают во время интенсивной регистрации - PullRequest
Новая
       18

Flume Appender Проблема: потоки приложений зависают, когда агенты Flume не работают во время интенсивной регистрации

0 голосов
/ 01 февраля 2019

В настоящее время мы используем следующие jar-файлы log4j

log4j-core-2.6.2, log4j-flume-ng-2.6.2 

<Flume name="aggregatorApp" compress="false" type="Avro"
ignoreExceptions="true" batchSize="10" blocking="false" >
<Agent host="${flumeHostPrimary}" port="${flumePortPrimary}" />
<Agent host="${flumeHostSecondary}" port="${flumePortSecondary}" />
<FlumeEventFactory logType="APPLICATION"/>
<PatternLayout header="app" pattern="[%-5p] %d %c %X{correlationId} - %m" />

<AsyncLogger name="com.xyz.abc" level="debug"
additivity="false" blocking="false">
<AppenderRef ref="IDRESTSERVICELOG" />
<AppenderRef ref="aggregatorApp" level="INFO" />
<AppenderRef ref="CONSOLE" level="INFO"/>
</AsyncLogger>
  1. Когда агент для сбора жидкостии работает приложение работает гладко, и события журнала успешно публикуются в агентах flume
  2. Если агенты flume не работают в течение некоторого времени, потоки приложения застряли с нижеуказанными исключениями 

Exception in thread "elasticsearch[_client_][generic][T#3]" java.lang.OutOfMemoryError: GC overhead limit exceeded
2019-02-01 07:43:23,618 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] WARN  org.apache.catalina.valves.StuckThreadDetectionValve- Thread "http-apr-8080-exec-7" (id=167) has been active for 20,392 milliseconds (since 2/1/19 7:42 AM) to serve the same request for htpps://xyz//directories/v1.0/search and may be stuck (configured threshold for this StuckThreadDetectionValve is 20 seconds). There is/are 1 thread(s) in total that are monitored by this Valve and may be stuck.
2019-02-01 07:46:18,619 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] ERROR org.apache.catalina.core.ContainerBase- Unexpected death of background thread ContainerBackgroundProcessor[StandardEngine[Catalina]]
java.lang.OutOfMemoryError: GC overhead limit exceeded
Exception in thread "http-apr-8080-exec-42" java.lang.OutOfMemoryError: GC overhead limit exceeded
Exception in thread "http-apr-8080-exec-50" Exception in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" Exception in thread "I/O dispatcher 23" 
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "ContainerBackgroundProcessor[StandardEngine[Catalina]]"
Exception in thread "http-apr-8080-exec-38" Exception in thread "http-apr-8080-exec-46" Exception in thread "http-apr-8080-exec-53" Exception in thread "I/O dispatcher 17" 
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "http-apr-8080-exec-31"

Вышеуказанные исключения случаются при большой нагрузке (ведение журнала 1 МБ на запрос). Примечание: мы выполняем нагрузочное тестирование

Поскольку приложение интенсивно ведет журнал, но приложение Flume не может использовать еготемп.Мы подозреваем, что заполнение кольцевого буфера Log4j блокирует потоки приложений и создает исключения из памяти.

Мы попробовали несколько действий, учитывая, что что-то есть с приложениями Log4J,

-Dlog4j2.AsyncQueueFullPolicy= Discard -Dlog4j2.enable.threadlocals = true -Dlog4j2.enable.direct.encoders = true

Но указанные выше системные свойства не используются.мы что-то упускаем?

1 Ответ

0 голосов
/ 03 февраля 2019

Я бы согласился, что RingBuffer для AsyncLogger вызывает у вас нехватку памяти.Размер кольцевого буфера по умолчанию составляет 256 КБ.Каков размер кучи для JVM?

Альтернативным подходом может быть использование встроенного или постоянного варианта FlumeAppender.Они будут кэшировать события в локальном файловом канале перед отправкой агенту Flume.Это позволит вам контролировать, как долго сервер может выдерживать перебои, регулируя объем доступного дискового пространства.Вы по-прежнему будете пользоваться преимуществами асинхронного регистратора, но будете защищены от перебоев.

...