Логирование и Мониторинг микросервисов на группах серверов
У меня есть проект с двумя группами виртуальных серверов (серверы в каждой группе просто копии одного образа с одинаковыми наборами микросервисов, как поды в k8s), балансировщиком и парой VPS с БД. Сейчас Docker и K8S пока не используются в виду небольшого масштаба проекта (однако есть в планах). Вместо этого, используются возможности нашего облачного провайдера: управление дисковыми образами, виртуалками и их группами с автоматическим созданием/удалением в зависимости от нагрузки. На данный момент это работает хорошо, но есть недостаток централизованного логирования и мониторинга, я постарался выделить следующие потребности:
- Дашборд с параметрами серверов вроде использования CPU, RAM, дискового места, сети и т.д. для каждого сервера. Некоторые дашборды доступны от нашего провайдера, есть крутые консольные утилиты, но хотелось бы иметь независимое и централизованное решение.
- Дашборд с числом ответов по разным HTTP кодам, как для каждой группы серверов в целом, так и для каждого сервера отдельно. Мы используем NginX и он предоставляет страницу со статусом, но это работает только по отдельным серверам (и опять же, нужна централизация).
- Окно для анализа логов с поддержкой многострочных сообщений (вроде трейсбеков);
- Независимость от языка программирования и стека технологий.
- Возможность задать уведомления по почте (а ещё лучше с запускать консольного скрипта, чтобы послать уведомление в Тг) с кастомными триггерами на метрики.
- Возможно есть какие-то другие важные фичи?
Дополнительные пожелания:
- Решение должно быть бесплатным.
- Также желательна простота в настройке. Надеюсь, что какое-то одно решение может быть достаточно гибким, чтобы покрыть все описанные нужды логирования и мониторинга.
- Зреслость / популярность решения, доступность документации и примеров.
- Решение должно сохраниться с минимальными изменениями, когда придёт время миграции в контейнеры.
На мой взгляд, итоговое решение выглядит следующим образом: 1) сервер, который сохраняет логи и рассчитывает метрики, предоставляет дашборды и инструменты для анализа логов, и 2) скрипт, установленный на каждом сервере, который запускается по таймеру и периодически отправляет локальные логи на сервер. Однако: как скрипт узнает, какие логи надо искать и отправлять на конкретном сервере, используя конфиг? Но возможно я ошибаюсь насчёт этого алгоритма работы.
В сети есть тонны рекомендаций по LogStash, ElasticSearch, Grafana, Kibana, Zabbix, Loki, Prometheus и т.д, но они почти не описывают отличия разных решений и их фич, не дают понимания, в каких случаях и почему лучше использовать то или иное решение. Я хотел бы увидеть современное объяснение, какое ПО может быть использовано друг с другом, каким образом и когда, а также сравнение в призме описанных потребностей.
Также я надеюсь, что ответы будут полезны многим другим разработчикам, так как тема очень актуальна и полезна в наше время :)
Ответы (1 шт):
Итак, после часов изучения статей и документации, я во всём разобрался Сравнительная таблица:

Zabbix это полнофункциональная технология которая работает и с метриками, и с логами, при этом расширяема. Также поддерживает автоматическое обнаружение хостов и построение карты сети.
Полезные ссылки:
Prometheus Это система мониторинга метрик. Создан для микросервисов и Kubernetes, может автоматически обнаруживать хосты для выгрузки данных. Имеет массу поддерживаемых адаптеров: docs: Exporters and Integrations. Для визуализации данных используется Grafana. Касательно хранения данных, Прометей имеет собственную систему для локального хранения, но имеются интеграции со сторонними технологиями для шардирования, см. docs: Storage.
Полезные ссылки:
- Оф.сайт Prometheus
- Хабр: Мониторинг с Prometheus в Kubernetes
- Хабр: Полное руководство по Prometheus в 2019
- Хабр: Хранилище данных для Prometheus: Thanos vs VictoriaMetrics
- Хабр: Thanos — масштабируемый Prometheus
PLG это стэк для обработки логов вдохновлённый Прометеем. Логи собираются через PromTail, а Loki это центральный компонент обработки. Также используется Grafana в качестве интерфейса. Локи не имеет своей системы хранения, поэтому требуются сторонние решения. Локи хранит данные в виде чанков и индексов, которые обычно хранятся отдельно, подробнее в docs: Storage. Как я понял, стэк PLG не имеет системы триггеров/уведомлеений, но компонент извлечения логов также может парсить их в метрики и отправлять в Прометей, таим образом получаются алерты. Также я заметил, что PromTail не поддерживает многострочные логи, но вместо него можно использовать более гибкий FluentD.
Полезные ссылки:
- Оф.сайт Loki
- Хабр: EFK vs PLG
- Хабр: Собираем логи с Loki
- Хабр: Loki — сбор логов, используя подход Prometheus
ELK / EFK это традиционный стэк для парсинга, индексирования и поиска логов, может производить сложные запросы. Для извлечения данных изначально использовался LogStash, но FluentD становится более популярным.
Полезные ссылки: