Я пробую варианты выталкивать журналы из лямбда-сервисов вasticsearch.
У нас уже есть решение, которое сканирует потоки журналов CloudWatch по умолчанию, но предпочло бы передавать любые пользовательские метрики напрямую.
Минимальное приложение, написанное специально для этого теста, прекрасно работает из IDE и не возвращает никаких ошибок кросс-конфигурации log4j в лямбде.
Это также не выдвигает почти любые журналы от лямбды.
Мы получаем случайные записи в упругой форме, но они попадают или не попадают даже при использовании одного и того же фляги и тестового запроса.
Из других тестов мы уже знаем, что лямбда убивает или замораживает потоки сразу после отправки ответа, и это похоже на проблему такого же рода.
Мы просим log4j отправить запись в журнале, она начинает буферизоваться, но прежде чем что-либо случится, поток будет остановлен. По крайней мере, это текущее предположение.
Уже пытались изменить параметры Socket appender instantFlush и bufferedIO без заметного изменения скорости доставки.
Попытки с выходом из системы дали похожие результаты.
Публикация текущей рабочей (только иногда на лямбда) log4j2.xml.
Тестовый проект может быть клонирован из: https://github.com/Slaszor/lambda-logger
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss} |%X{AWSRequestId}| %-5p %c:%L - %m%n"/>
</Console>
<Socket name="socket" host="logstash.test.domain.com" port="5000">
<JsonLayout complete="false" compact="true">
<KeyValuePair key="app_name" value="java-echo-service"/>
</JsonLayout>
</Socket>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="Console"/>
<AppenderRef ref="socket"/>
</Root>
</Loggers>
</Configuration>
У кого-нибудь есть идеи, как заставить log4j надежно передавать эти журналы?