Приложение Filebeat vs Java logging

Question

Мы начнем развертывание наших приложений Java с помощью докеры на AWS elasticbeanstalk, мы хотим централизованного ведения журнала и будем использовать стек ELK.

Я хотел бы сохранить один процесс в контейнере, поэтому избегайте использования filebeat, но для этого нам придется использовать другой appender, такой как syslog или даже tcp appender.

Мы не можем позволить себе проигрывать журналы.

Filebeat предоставляет логику повторного использования из коробки, но введение его в микс увеличит сложность развертывания, необходимо будет удостовериться, что filebeat получает SIGTERM, когда контейнеры завершены, убедитесь, что он предварительно обработан в виде контейнера или в файле Docker , и так далее.

Если мы спустимся по пути с помощью tcp или syslog appender, мы продолжим переучивать, и мы также хотим избежать сложности с нашим кодом.

Каковы преимущества и недостатки каждого подхода, в дополнение к тому, что я указал?

Наша библиотека регистрации - это журнал.

Answer 1

У меня такие же проблемы, как и вы. Самый безопасный способ регистрации - это локальный файл (при условии, что у вас достаточно места). Потому что гораздо труднее гарантировать доступность других процессов или сети.

Посмотрите на обсуждение в почтовом списке Logback: orig/MarkLogic mirror /Nabble mirror и особенно переигрывать:

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

Проект

https://github.com/internetitem/logback-elasticsearch-appender Проект предоставляет приложение для высокодоступного кластера ElastichSearch непосредственно с буферизацией событий журнала в память, если все узлы опущены.

Альтернативный способ - написать высокодоступное промежуточное программное обеспечение для обеспечения кеширования и доставки. Как Кафка, Редис и т. Д.