История о том, как я укрощал Prometheus

Эта статья основана на личном опыте, знаниях и практике 
системного инженера компании СТАРКОВ Групп Дмитрия Пальчикова.

В современном мире информационных технологий, где критически важные системы и приложения работают в круглосуточном режиме, мониторинг играет ключевую роль в обеспечении стабильности и производительности. Одним из мощных инструментов, завоевавших популярность среди специалистов по DevOps и системному администрированию, является Grafana. Эта платформа для визуализации и анализа данных позволяет эффективно отслеживать состояние систем, выявлять потенциальные проблемы на ранних стадиях и принимать своевременные меры для их устранения.

В списке решений от компании Directum, есть компонент — "Мониторинг системы Directum RX". Он позволяет своевременно реагировать на инциденты, которые происходят под "капотом", отслеживать ошибки, нагрузку на систему, быстродействие DirectumRX и многое другое. 

Оперативность реагирования достигается путем настройки уведомлений о серверных событиях из самого интерфейса Grafana на почту, telegram, slack и т.д.

В этой статье, поделимся решением, которое внедрили у одного крупного заказчика компании СТАРКОВ Групп.

Проблема

Однажды я столкнулся с проблемой эффективности работы Elasticsearch в решении "Мониторинг" на версии системы DirectumRX 4.6. Проблема таилась в самом Elasticsearch. Метрики Telegraf шли с 20-то и более серверов, а Filebeat собирал и отправлял логи с 7 плеч. В связи с этим, данные финализировались либо очень долго, либо Elasticsearch вообще отказывался их обрабатывать. Такой путь не особо меня устраивал, т.к. в конечном счете мы могли упустить какое-либо критическое событие и не успеть вовремя на него среагировать.

Я начал искать пути разрешения этих недоразумений с целью — оптимизировать работу Elasticsearch.

Спустя какое-то время система обработала все данные, но на это ушло порядка полутора месяца. Такой подход нам не подойдет, т.к. ситуация может повториться.

Мой путь

Первая моя идея заключалась в использовании двух серверов с Elasticsearch, один из которых обрабатывал бы метрики Telegraf, а второй — логи от Filebeat. Я думал о том, чтобы поднять второй контейнер, или даже целый сервер с Elasticsearch, который бы просто обрабатывал метрики Telegraf. Однако данное решение достаточно затратное, т.к. сам Elasticsearch потребляет большое количество оперативной памяти, да и в целом не эффективное, ведь пришлось бы создавать еще одну виртуальную машину, выделять на нее дополнительные ресурсы.

Вторая идея была еще более безумная — собрать кластер Elasticsearch. Но возвращаемся к проблеме выше - это очень дорого.

Немного подумав, я решил полностью отказаться от Telegraf. Осталось подобрать ему достойную замену. И решил остановиться на Prometheus. Для меня он уже был немного знаком, и я понимал всю силу и мощь данного инструмента. Prometheus — это система мониторинга и оповещения с открытым исходным кодом, разработанная для сбора и обработки метрик.

Основные особенности Prometheus включают

• Модель данных на основе временных рядов: Prometheus хранит все данные в виде временных рядов, где каждая метрика имеет метку времени и может быть дополнена различными метками (labels), которые помогают в идентификации и группировке данных.
• Язык запросов PromQL: Специальный язык запросов Prometheus Query Language (PromQL) позволяет гибко и мощно работать с временными рядами данных, выполняя сложные вычисления и агрегирования.
• Автономное функционирование: Prometheus работает независимо и не требует внешних хранилищ данных. Он самостоятельно собирает метрики с помощью pullмодели, что упрощает настройку и управление.
• Экспорт данных: Prometheus может собирать метрики из различных источников, используя экспортёры, которые адаптируют метрики из других систем и сервисов под формат, совместимый с Prometheus.
• Оповещения: Система оповещений в Prometheus позволяет настроить триггеры на основе определённых условий, что помогает своевременно информировать команду о возникновении проблем

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

Я подготовил следующую схему решения:

Следующим шагом я решил пересобрать все дашборды, которые использовали Telegraf. Для этого я создал новый "Data Source" для Grafana — Prometheus. И настроил подключение с ним.

Осталось дело за малым, нужно решить, какие экспортеры я хочу использовать.

Остановился на таком списке:

• node exporter
• cadvisor
• elasticsearch exporter
• blackbox exporter
• postgres exporter
• process exporter

Для мониторинга RabbitMQ и HAProxy использовал их встроенный функционал, для сбора метрик через Prometheus, и дополнительные экспортеры не устанавливал. Количество экспортеров для Prometheus достаточно велико, на любой вкус и цвет. С их помощью можно настроить дашборды в Grafana для Apache, Nginx, MongoDB, Kubernetes кластеров и т.д. Однако для меня это было немного избыточно.

Пару строк об экспортерах

Node Exporter

Экспортер, который собирает если не все, то большинство метрик с серверов.

Загрузку процессора, оперативной памяти, дисковое пространство, нагрузку на сеть и многое другое.

Cadvisor

Данный экспортер обрабатывает и агрегирует данные, которые поступают от Docker контейнеров.

Elasticsearch Exporter и Postgres Exporter

Я думаю, из названия понятно, что данные экспортеры собирают данные Elasticsearch и Postgres. Их статистику, настроенные параметры и другие показатели.

Blackbox Exporter

Собирает метрики, которые относятся больше к веб-серверу. С его помощью можно получать информацию о доступности веба, версии TLS и HTTP протоколов, время действия TLS сертификатов и т.д.

Process Exporter

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

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

После импорта дашбордов получилось примерно следующее (обращаю ваше внимание, что на скриншотах предоставлена лишь малая часть агрегируемой информации поступающей с экспортеров):

Дашборд, который отвечает за метрики Linux серверов.

Дашборд, который отвечает за метрики Elasticsearch.

Дашборд, который отвечает за метрики Haproxy.

Дашборд, который отвечает за метрики PostgreSQL.

Дашборд, который отвечает за метрики RabbitMQ.

Дашборд, который отвечает за метрики Веб-сервера

Дашборд, который отвечает за метрики Docker контейнеров.

Дашборд, который отвечает за метрики процессов системы.

Преимущества решения

• Снизилась нагрузка на Elasticsearch;
• Увеличилось количество информации, которую мы можем визуализировать в Grafana;
• Повысился уровень экспертизы в разборе инцидентов.

Заключение

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

P.S. Если кто-то еще не в курсе, в версии Directum RX 4.9 уже представлен новый дашборд, который работает в связке Victoria metrics + Postgres exporter.

Ждём ваших вопросов и идей!               
Дмитрий Старков и Дмитрий Пальчиков