Единый микросервис для сбора/хранения всех логов, правильно ли это?

Question

[Андрей Рудаков]

Добрый день.
У меня микросервисная архитектура.
Дошёл до момента логирования, какой вариант лучше по Вашему?
1 вариант: Все логи отправляются в один микросервис.
2 вариант: Каждый микросервис пишет собственные логи в своем хранилище.

Comments

[shurshur]

Вообще говоря, для микросервисов нынче модно писать строго в stdout и собирать в одном месте средствами оркестратора. Но ничто не мешает делать какие угодно варианты. Например, писать и в файлы, и в stdout, и в syslog, и вообще как душе угодно. Большинство библиотек логгирования позволяют весьма разнообразную настройку.

[Roman K]

У меня микросервисная архитектура.

Нет

[Андрей Рудаков]

Roman Kitaev,
А понял, что неправильно

Answer 1

[Saboteur]

1 вариант: Все логи отправляются в один микросервис.

Все логи отправляются в лог аггрегатор, а не микросервис. Писать для себя микросервис по работе с логами - лишняя работа, так как сейчас есть готовые инструменты.

А вот как это делать - уже разные варианты есть.

Ваше приложение может писать в stdout, и если вы пользуетесь чем-то вроде kubernetes/openshift, то это удобно ловить централизировано сразу на кластере, тегировать по имени приложения/пода и отправлять дальше.

Ваше приложение может напрямую писать логи в какой-нибудь logstash, который все собирает парсит и отправляет дальше

Ваше приложение может писать логи в брокер сообщений, из которого уже логи попадают в аггрегатор. Полезно если бывают очень большие пики логов и есть вероятность, что аггрегатор может в какой-то момент не справитьcя и часть потеряется - тогда какой-нить kafka/rabbitmq как раз будет промежуточным буффером, который гарантировано примет все логи, сколько бы их ни было и передаст их дальше со скоростью, которая комфортна для вашего лог аггрегатора (масштабировать брокер проще, чем аггрегатор)

Ваше приложение может писать логи прямо в базу данных. Даже в sql базу, или прямо в elastic.

Ваше приложение может писать просто в лог файлы, а потом эти лог файлы собираются, парсятся, отправляются в лог аггрегатор.

В общем на любой вкус и цвет. Определитесь с объемом логов, с пиковыми моментами, с тем что вы хотите делать и сделайте общий стандарт для всех ваших компонентов.

2 вариант: Каждый микросервис пишет собственные логи в своем хранилище.

Ну можно и так.

Comments

[Андрей Рудаков]

есть готовые инструменты

Можете посоветовать хорошие? Микросервисов более 20 шт.

[Saboteur]

Стандартные стеки
ELK (elastic,logstash,kibana)
greylog
можно EL+графана

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

P.S. Неважно сколько сервисов, надо считать объем логов в период времени, чтобы система успевала их парсить и сохранять, и объем логов который вы хотите хранить не удаляя. Все инструменты справятся, просто разные инструменты разный объем хранят. Кто-то больше на индексы тратит, кто-то любит в репликацию.

Answer 2

[Vitaly Karasik]

Как уже намекнули в комментах, лучше третий вариант - писать в stdout.
А дальше с помощью https://fluentbit.io/ (или другого) посылать логи куда хотим - Elastic (локальный или облачный), AWS Cloudwatch Logs, и т.п.

Answer 3

[Aryeh Leonid R.]

1 вариант.
log4js (type = logstash udp) и далее все логи улетают в одно хранилище.
Хорошая статья (для java, но я выше написал про js) вот тут

Учимся готовить Log4j + Logstash + ElasticSearch +...

Answer 4

[zebesh]

А ещё есть Loki от grafana, как хранилище логов и promtail от них же, как сборщик