Nightbook

Недавно я делал ревью новой системы мониторинга Prometheus, оценивая эту систему как потенциальную замену текущему DataDog. Забегая на перед, скажу что от идеи использовать Prometheus пришлось отказаться. Но об этом немного позже.
Prometheus это, как по мне, очень интересный пример как необходимо системным инструментам подстраиваться под текущие требования серверного хозяйства. Если проще то необходимо создавать новые подходы для мониторинга в нашей быстрорастущей контейнерной среде. В этом плане Prometheus прекрасен. Но давайте расмотрим что же в нем такого необычного.
Prometheus проектировался как система сбора и обработки метрик, создание алертов. Метрики он получает по http запросам на страници демонов экспортеров (exporters). Сами экспортеры зачастую представляют из себя http демоны отображающие в формате прометея последние метрики. Серверу Prometheus только и остается их скачать и распарсить добавив временные метки (которые о чудо будут отображаться и храниться только в UTC). Экспортеры это не прокси сервера и у них нет кэша. Они держат последние полученые значения в памяти и конвертируют в понятный прометею формат. Даже интеграция MySQL это http сервер с набором метрик из базы данных. Словом о экспортерах. Присутсвуют библиотеки которые позволяют интегрировать такие страницы сразу в ваш код. И на отдельном порту ваше приложение будет транслировать нужные метрики понятные прометею. Можно и пушить данные. Для этого есть Pushgateway. Но его использование не рекомендуется так как он нормально не масштабируется. Можно так же писать метрики в файл который будет транслироваться на http страницу в нужном формате. Как по средствам node-exporter (базовый экспортер который отображает метрики ОС), так и транслировать такую страницу самостоятельно через веб сервер. Удобно? Не совсем. Как я уже говорил ранее, Prometheus нацелен на контейнерные среды. Вот представьте как выглядит мониторинг сервисов в контейнерах. Возьмем к примеру системы мониторинга Nagios (страшно его даже расматривать для динамиских контейнеров), Zabbix, DataDog. Эти системы мониторинга требуют установки агента. Его надо либо паковать в контейнер либо добавлять на материнский сервер предварительно конфигурируя. Это лишние ресурсы и ненужно обслуживание. А вот с Prometheus все проще. Рядом с контейнером сервиса поднимаем контейнер с нужным экспортером интеграции и вот все что нам надо. Даже лучше. Просто интегрируем страницу с метриками в само приложение. Но что то тут не так? Да. Такая схема неизбежно приведет к появлению пробелов в графиках. Причина тому в дизайне. Сервер опрашивает последнее состояние службы. И если он не сделает это в течении длительного промежутка времени то эти данные будут безвозвратно утеряны. А вот в ситуации отсуствия контейнеров, когда нужно мониторить сервис на сервере, или их связку нужно будет поднимать пачку таких экспортеров для проверки систем времени, аутентификации, резервного копирования и т.д.. Давайте двигаться далее. Сервер опрашивает экспортеров. Как он знает кого и где опрашивать? А у него есть список. Он может быть либо статически прописан либо может быть разведан из внешних систем (DNS, Kubernetes, Consule, AWS и т.д.). Алерты тоже настраиваются в текстовых конфигах. Но вот что бы алерт был доставлен нужно поднять отдельный демон Alertmanager. А если нужна отказаустойчивость то их лучше поднять три и объеденить в mesh кластер. К слову о отказаустойчивости. Alertmanager это единственный демон в проекте Prometheus который ее успешно обеспечивает. Сам сервер Prometheus в отказоустойчивой схеме, по задумке разработчиков, должен представлять набор шард с различными задачами на мониторинг либо два идентичных сервера. Самой большой проблемой такой схемы является хранилище данных. Оно локальное. И что бы кто не говорил на текущий момент удаленное хранилище нестабильно, а код примера такого демона удаленного хранилища лежит в секции документации и не входит в состав tar архива Prometheus. Само локально хранилище не преднозначено для хранения длительных периодов времени. Оно отлично подходит для хранения нескольких недель или пары месяцов. Для длительного хранения метрик и создавалась поддержка удаленного хранилища, но как я уже сказал эта поддержка только эксперементальна. И так у вас есть два идентичных сервера. Которые даже метрики дублируют. Что с дубликацией алертов? Дедубликацию выполняет Alertmanager. С ним проблем нет и к нему возвращаться я больше не буду. Но как быть с этими двумя серверами Prometheus когда настанет та ситуация для которой их и поднимали. Тут все печально. Если с одним из серверов пройдет сбой то в его локальном хранилище данных будут пропуски. И с ними надо будет жить. Либо запоминать с какого сервера надо строить графики без пропусков. Не будем о плохом. UI в Prometheus из коробки есть но он не фиксирует свое состояние и болше напоминает серию из одностраничных приложений. Дашборд из такого не составиш. Альтернатива Grafana, которая имеет адаптер к Prometheus и момет опрашивать его напрямую. Ну можно много еще чего расказать о языке построения запросов PromQL, об настройки агригации данных между серверами через механизм federation, об объединении вывода из нескольких серверов на одном графике Grafana но я уже и так написал больше чем хотел. Вердикт Prometheus очень интересный но не для enterprise использования. Если конечно вы не готовы его модернизировать под себя как это сделали ребята из DigitalOcean в проекте vulcan.