Вход с Java-приложения в ELK без необходимости обработки журналов

Я хочу отправить журналы из приложения Java в ElasticSearch, и традиционный подход, похоже, заключается в настройке Logstash на сервере, на котором запущено приложение, и logstash анализирует файлы журнала (с регулярным выражением...!) и загружает их в ElasticSearch.

Есть ли причина, по которой это делается, вместо того, чтобы просто настроить log4J (или logback) для записи вещей в нужном формате непосредственно в сборщик журналов, который затем может быть отправлен в ElasticSearch асинхронно? Мне кажется сумасшедшим, что мне приходится возиться с фильтрами grok, чтобы иметь дело с многострочными трассировками стека (и записывать циклы процессора при анализе журнала), когда само приложение может просто записать его в нужном формате в первую очередь?

Что касается касательной к заметке, для приложений, работающих в контейнере Docker, лучше всего регистрироваться непосредственно в ElasticSearch, учитывая необходимость запуска только одного процесса?

Ответ 1

Я думаю, что обычно не рекомендуется регистрироваться непосредственно в Elasticsearch из Log4j/Logback/любого приложения, но я согласен с тем, что писать фильтры Logstash для анализа "нормального" читаемого Java-журнала Java - тоже плохая идея. Я использую https://github.com/logstash/log4j-jsonevent-layout везде, где я могу иметь регулярные файловые приставки Log4j, создавать журналы JSON, которые не требуют дальнейшего анализа с помощью Logstash.

Ответ 2

Если вы действительно хотите пойти по этому пути, идея заключается в том, чтобы использовать что-то вроде приложения Elasticsearch (или этого или этого другого), которое бы отправляйте свои журналы прямо в кластер ES.

Тем не менее, я бы посоветовал против этого по тем же причинам, упомянутым @Vineeth Mohan. Вам также нужно задать себе пару вопросов, но, в основном, что произойдет, если ваш кластер ES выйдет из строя по какой-либо причине (OOM, сеть отключена, обновление ES и т.д.)?

Существует множество причин, по которым существует асинхронность, одна из которых - это надежность вашей архитектуры, и в большинстве случаев она гораздо важнее, чем сжигание еще нескольких циклов ЦП при разборе журнала.

Также обратите внимание, что продолжается постоянная дискуссия на эту тему на официальном дискуссионном форуме ES.

Ответ 3

Если вам нужно быстрое решение, я написал этот appender здесь Log4J2 Elastic REST Appender, если вы хотите его использовать. Он имеет возможность буферизовать события журнала на основе времени и/или количества событий, прежде чем отправлять его в Elastic (используя API-интерфейс _bulk, чтобы он отправлял все за один раз). Он был опубликован в Maven Central, поэтому он довольно прямолинейный.

Как уже говорили другие люди, лучший способ сделать это - сохранить его в файл, а затем отправить его в ES отдельно. Однако я думаю, что есть ценность, если вам нужно что-то быстро запускать, пока у вас не будет времени/ресурсов, оптимального пути.

Ответ 4

Существует также https://github.com/elastic/java-ecs-logging, который предоставляет макет для log4j, log4j2 и Logback. Это довольно эффективно, и конфигурация Filebeat очень минимальная.

Отказ от ответственности: я автор этой библиотеки.