3

У меня есть проект с двумя группами виртуальных серверов (серверы в каждой группе просто копии одного образа с одинаковыми наборами микросервисов, как поды в k8s), балансировщиком и парой VPS с БД. Сейчас Docker и K8S пока не используются в виду небольшого масштаба проекта (однако есть в планах). Вместо этого, используются возможности нашего облачного провайдера: управление дисковыми образами, виртуалками и их группами с автоматическим созданием/удалением в зависимости от нагрузки. На данный момент это работает хорошо, но есть недостаток централизованного логирования и мониторинга, я постарался выделить следующие потребности:

  1. Дашборд с параметрами серверов вроде использования CPU, RAM, дискового места, сети и т.д. для каждого сервера. Некоторые дашборды доступны от нашего провайдера, есть крутые консольные утилиты, но хотелось бы иметь независимое и централизованное решение.
  2. Дашборд с числом ответов по разным HTTP кодам, как для каждой группы серверов в целом, так и для каждого сервера отдельно. Мы используем NginX и он предоставляет страницу со статусом, но это работает только по отдельным серверам (и опять же, нужна централизация).
  3. Окно для анализа логов с поддержкой многострочных сообщений (вроде трейсбеков);
  4. Независимость от языка программирования и стека технологий.
  5. Возможность задать уведомления по почте (а ещё лучше с запускать консольного скрипта, чтобы послать уведомление в Тг) с кастомными триггерами на метрики.
  6. Возможно есть какие-то другие важные фичи?

Дополнительные пожелания:

  1. Решение должно быть бесплатным.
  2. Также желательна простота в настройке. Надеюсь, что какое-то одно решение может быть достаточно гибким, чтобы покрыть все описанные нужды логирования и мониторинга.
  3. Зреслость / популярность решения, доступность документации и примеров.
  4. Решение должно сохраниться с минимальными изменениями, когда придёт время миграции в контейнеры.

На мой взгляд, итоговое решение выглядит следующим образом: 1) сервер, который сохраняет логи и рассчитывает метрики, предоставляет дашборды и инструменты для анализа логов, и 2) скрипт, установленный на каждом сервере, который запускается по таймеру и периодически отправляет локальные логи на сервер. Однако: как скрипт узнает, какие логи надо искать и отправлять на конкретном сервере, используя конфиг? Но возможно я ошибаюсь насчёт этого алгоритма работы.

В сети есть тонны рекомендаций по LogStash, ElasticSearch, Grafana, Kibana, Zabbix, Loki, Prometheus и т.д, но они почти не описывают отличия разных решений и их фич, не дают понимания, в каких случаях и почему лучше использовать то или иное решение. Я хотел бы увидеть современное объяснение, какое ПО может быть использовано друг с другом, каким образом и когда, а также сравнение в призме описанных потребностей. Также я надеюсь, что ответы будут полезны многим другим разработчикам, так как тема очень актуальна и полезна в наше время :)

1 ответ 1

2

Итак, после часов изучения статей и документации, я во всём разобрался Сравнительная таблица:

Логирование и Мониторинг сереро by AivanF


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

Полезные ссылки:


Prometheus Это система мониторинга метрик. Создан для микросервисов и Kubernetes, может автоматически обнаруживать хосты для выгрузки данных. Имеет массу поддерживаемых адаптеров: docs: Exporters and Integrations. Для визуализации данных используется Grafana. Касательно хранения данных, Прометей имеет собственную систему для локального хранения, но имеются интеграции со сторонними технологиями для шардирования, см. docs: Storage.

Полезные ссылки:


PLG это стэк для обработки логов вдохновлённый Прометеем. Логи собираются через PromTail, а Loki это центральный компонент обработки. Также используется Grafana в качестве интерфейса. Локи не имеет своей системы хранения, поэтому требуются сторонние решения. Локи хранит данные в виде чанков и индексов, которые обычно хранятся отдельно, подробнее в docs: Storage. Как я понял, стэк PLG не имеет системы триггеров/уведомлеений, но компонент извлечения логов также может парсить их в метрики и отправлять в Прометей, таим образом получаются алерты. Также я заметил, что PromTail не поддерживает многострочные логи, но вместо него можно использовать более гибкий FluentD.

Полезные ссылки:


ELK / EFK это традиционный стэк для парсинга, индексирования и поиска логов, может производить сложные запросы. Для извлечения данных изначально использовался LogStash, но FluentD становится более популярным.

Полезные ссылки:

3
  • В вашей таблице написано, что ElasticSearch не умеет Metrics. Вы неправы - для метрик у Эластика есть MetricBeat. Пользуюсь уже около года на не очень нагруженном проекте - полёт нормальный, хотя есть сомнения, что оно будет хорошо скэйлиться для больших проектов. Хотя может быть...
    – Slavik
    18 окт 2020 в 6:57
  • @Slavik спасибо за инфу! Это и логично в принципе, ничего не мешает создать такой инструмент. Надо будет обновить табличку.
    – AivanF.
    18 окт 2020 в 11:35
  • С точки зрения сбора логов могу порекомендовать Fluent Bit (преемник Fluentd, но более легковесный). Он подходит под все сценарии использования: как агент на сервере, как агент в поде и для удаленного логирования. Советую ознакомиться с подходами в cluster-level логировании поподробнее, перед тем, как разворачивать свое решение: influunt.ru/kubernetes-cluster-level-logging-intro
    – Alex
    8 фев 2021 в 5:58

Ваш ответ

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge you have read our privacy policy.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками или задайте свой вопрос.