Prometheus мониторинг что это
Система мониторинга Prometheus
В этой статье мы расскажем, что такое мониторинг Prometheus, как установить и как пользоваться Prometheus.
Prometheus описание
Prometheus — система мониторинга серверов и программ с открытым исходным кодом. Она была выпущена в 2012 году для мониторинга музыкальной социальной сети SoundCloud. Из-за специфики архитектуры SoundCloud традиционные системы мониторинга не подходили, поэтому по новой технологии был создан Prometheus-мониторинг. Позже новый мониторинг сервисов стал интересен за пределами музыкальной сети. Создатели доработали систему и предложили её более широкому рынку. Релиз обновлённой программы прошёл в 2015 году.
Система мониторинга Prometheus может собирать информацию о состоянии серверов и систем (Linux-сервера, Apache-сервера, сервера баз данных), а также получать предупреждения о проблемах. Объекты мониторинга называются целевыми объектами.
Мониторинг выделенных серверов
Держите руку на пульсе и будьте в курсе всех изменений параметров вашего сервера.
Главное отличие Prometheus от остальных систем мониторинга — метод сбора данных. Обычно объекты мониторинга отправляют нужные параметры серверам мониторинговых программ. Прометеус же наоборот — сам берёт нужную ему информацию с серверов и устройств, обращаясь к целевым объектам при помощи языка PromQL. Сервер Prometheus считывает параметры целевых объектов с интервалами, которые задаёт пользователь. Данные от целевых объектов передаются на сервер в формате http и хранятся в базе данных временных рядов. В отличие от системы Zabbix, которая написана на языке С и PHP, Prometheus написан на Go и Ruby.
Prometheus функционирует благодаря таким компонентам, как:
Prometheus-server — главное звено всей системы. Он отвечает за сбор и хранение данных. Есть простой веб-интерфейс, но для полноценной работы с системой лучше устанавливать дополнительный.
Exporters — это часть ПО, которая собирает и передаёт Prometheus-метрики серверу. Существуют разные экспортёры, например HAProxy, StatsD, Graphite. Они устанавливаются на целевые объекты и собирают определённые метрики. Если ни один экспортёр вам не подходит, то можно написать свой.
Работа с Prometheus не обойдётся без дополнения Grafana — с его помощью можно визуализировать полученные данные в виде наглядных графиков, диаграмм и таблиц (dashboard). А также Alertmanager — программы для настройки уведомлений. Если на целевом объекте появятся проблемы, Alertmanager сможет отправить письмо на почту, Slack, Hipchat, Pagerduty или Telegram.
C помощью руководства ниже вы сможете установить Prometheus на CentOS, Debian, Ubuntu. Также мы расскажем, как установить exporter и Alertmanager, чтобы можно было получать сообщения о неисправностях.
Как установить Prometheus
На официальном сайте Prometheus скопируйте ссылку на установочный пакет для Linux:
Пример ссылки для Linux
Если у вас нет wget, то перед началом работы с Prometheus установите этот пакет.
Установка и настройка Prometheus
Отслеживать состояние сервера и запущенных на нём процессов очень важно чтобы иметь возможность вовремя оптимизировать настройки, исправить ошибки или реагировать на повышенную нагрузку. Существует множество систем мониторинга для Linux различной сложности. В этой статье речь пойдёт про Prometheus.
Установка и настройка Prometheus
1. Установка Prometheus
Вы можете установить Prometheus из официальных репозиториев в Ubuntu. Вы можете посмотреть какие пакеты prometheus доступны можно такой командой:
sudo apt search prometheus
Для установки выполните команду:
sudo apt install prometheus
Однако в репозиториях содержится уже старая версия программы. Если вы хотите самую свежую версию, то придется скачать её из официального сайта. Поскольку программа написана на Golang, то и распространяется она в виде одного исполняемого файла. Поэтому установить её не сложно, достаточно скачать архив, распаковать и скопировать исполняемый файл в папку /usr/local/bin, также надо будет скопировать несколько исполняемых файлов.
Сначала скачайте пакет Prometheus с официальной страницы GitHub. Для Linux нужен пакет с исполняемыми файлами linux-amd64:
Загруженный документ надо распаковать. Для этого можно воспользоваться утилитой tar:
Затем скопируйте исполняемые файлы prometheus и promtool в папку /usr/local/bin:
Для конфигурационных файлов необходимо создать папку /etc/prometheus:
sudo mkdir /etc/prometheus
Затем скопируйте туда такие папки с конфигурационными файлами:
В них содержатся файлы для работы веб-интерфейса программы. Кроме того, нужно создать конфигурационный файл /etc/prometheus/prometheus.yml со следующим содержимым:
sudo vi /etc/prometheus/prometheus.yml
Здесь сказано, что по умолчанию интервал сбора данных составляет 15 секунд, а также добавлена задача по сборку данных с самого Prometheus. Никаких данных о состоянии сервера там не будет, только параметры работы программы.
Для запуска программы понадобится пользователь prometheus:
Осталось только создать файл systemd службы для удобного запуска prometheus. Для этого выполните команду:
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target
[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
—config.file /etc/prometheus/prometheus.yml \
—storage.tsdb.path /var/lib/prometheus/ \
—web.console.templates=/etc/prometheus/consoles \
—web.console.libraries=/etc/prometheus/console_libraries
[Install]
WantedBy=multi-user.target
2. Запуск Prometheus
После этого можно запустить Prometheus и проверить его работу. Для этого выполните:
sudo systemctl start prometheus
Затем для того чтобы убедится что всё запустилось выполните:
sudo systemctl status prometheus
Обратите внимание на строчку Active. Её значение должно быть active (running). Если там что-то другое, значит программа не запустилась, и вы можете посмотреть лог ниже чтобы понять причину.
3. Доступ к веб-интерфейсу
Если программа запущена, вы можете получить доступ к веб-интерфейсу в браузере. Откройте порт 9090 на сервере, куда вы устанавливали Prometheus:
Спустя некоторое время можно попытаться построить график из собранных данных. Для этого вернитесь на главную страницу и в строке Expression наберите go_memstats_frees_total. Затем перейдите на вкладку Graph:
Будет отображен график этого показателя. С помощью поля Expression можно смотреть какие метрики уже собираются и просматривать их значения. Метрика go_memstats_frees_total стандартная для каждого экспортера данных и обычно для отображения на графиках не используется.
4. Установка Grafana
Смотреть графики Prometheus в его веб-интерфейсе не удобно и не практично. Там вы можете только убедится, что всё собирается верно. Для просмотра графиков же следует использовать Grafana. Для её установки надо сначала установить несколько компонентов:
Затем добавьте ключ репозитория в систему:
И добавьте сам репозиторий:
После этого обновите список пакетов в репозиториях и установите Grafana:
sudo apt update
sudo apt install grafana
5. Настройка Grafana для Prometheus
На шаге настройки подключения необходимо в поле URL ввести адрес сервера, на котором доступен Prometheus и его порт. Если Grafana находится на той же машине, что и Prometheus можно использовать localhost, а порт по умолчанию 9090:
После этого нажмите Save and Test и вы должны увидеть что тест прошёл успешно.
После этого можно переходить к созданию досок.
6. Импорт доски Prometheus в Grafana
Доску для метрик, собираемых по умолчанию сервером Prometheus можно взять здесь. На этой странице вам нужен только идентификатор 3362, который находится под надписью Get this dashboard:
Затем нажмите кнопку Load и на следующей странице введите имя доски и выберите ранее созданный источник данных (Data source). В этом примере он называется Prometheus:
После нажатия на кнопку Import перед вами откроется доска с метриками, её можно уже настроить так, как вам необходимо:
7. Установка Node Exporter
Данные в Prometheus поступают из так называемых экспортёров, программ, которые делают различные метрики доступными по HTTP адресу /metrics. Сервер Prometheus регулярно опрашивает такие экспортёры и собирает с них данные. Экспортеры существуют для различных служб и сервисов, например, для Nginx, MySQL, PHP-FPM, Apache ну и естественно экспортёр общих сведений о сервере. Такой экспортёр называется Node_exporter. Он тоже написан на Golang как и большинство экспортёров для Prometheus. Аналогично основному компоненту его можно установить из официальных репозиториев Ubuntu:
sudo apt install prometheus-node-exporter
Или можно получить последнюю версию из страницы на GitHub. После загрузки распакуйте её:
Затем скопируйте исполняемый файл программы в /usr/local/bin:
Далее создайте пользователя, от имени которого будете запускать программу:
И создайте юнит файл systemd для её запуска:
[Unit]
Description=Prometheus Node Exporter
Wants=network-online.target
After=network-online.target
[Service]
User=node_exporter
Group=node_exporter
Type=simple
ExecStart=/usr/local/bin/node_exporter
[Install]
WantedBy=multi-user.target
Шаг 8. Настройка node_exporter
Далее необходимо запустить node_exporter. Для этого выполните такую команду:
sudo systemctl start node_exporter
Затем проверьте состояние сервиса:
sudo systemctl status node_exporter
Как и в случае с Prometheus состояние должно быть active (running):
А в логах вы можете найти на каком порту ожидает подключений этот экспортёр. Именно в этих логах необходимо смотреть работает ли экспортёр хорошо или с ним что то не так.
Ещё один способ убедится что экспортёр возвращает все необходимые метрики открыть URL /metrics на порту, где экспортёр ожидает подключений. Для node_exporter по умолчанию используется порт 9100, о чём и сообщается в логе:
Как видите, кроме стандартных метрик с приставкой go* экспортируются и довольно много метрик начинающихся на node. Значит всё работает.
Шаг 9. Добавление node_exporter в prometheus
Дальше нужно сообщить prometheus что необходимо собирать данные с этого экспортёра. Под каждого экспортёра в конфигурационном файле необходимо создавать подраздел в scrape_configs со следующим содержимым:
В данном случае полный конфигурационный файл prometheus будет выглядеть вот так:
sudo vi /etc/prometheus/prometheus.yml
Для формата yaml отступы имеют очень важное значение, поэтому следите чтобы с ними было всё хорошо. В данном примере node_exporter находится на том же компьютере, что и prometheus поэтому можно указать localhost. Такой экспортёр надо установить на все машины, которые надо отслеживать с помощью программы. Для каждой надо создать свою job. После завершения настройки перезапустите Prometheus:
systemctl restart prometheus
Теперь можно проверить в Prometheus, что данные передаются:
Шаг 10. Импорт доски для Node Exporter
На следующей странице введите название доски и выберите источник данных снова Prometheus:
После нажатия кнопки Import перед вами появится доска, и здесь уже данные намного интереснее, чем на предыдущей:
Такие доски можно добавить для различных служб. Теперь вы можете осуществлять мониторинг Prometheus или продолжить настройку установив дополнительные экспортёры.
Выводы
В этой небольшой статье мы рассмотрели как выполняется установка Prometheus Grafana в Ubuntu 20.04. Как видите, программа довольно проста в настройке, намного проще по сравнению со связкой Collectd + IfluxDB и возможностей здесь намного больше. А какой системой мониторинга пользуетесь вы? Напишите в комментариях!
Мониторинг с помощью Prometheus: как это работает
IT-продукт без метрик — как корабль без руля и ветрил. Метрики нужно собирать, анализировать и только на основе их значений принимать решения. Поговорим о том, что такое Prometheus, как он собирает метрики и почему для этого не всегда подходят стандартные базы данных.
Как появился Prometheus
Управление бизнесом без знания цифр — невозможно. Для принятия взвешенных решений нужно знать ключевые бизнес-метрики: выручку, прибыль, количество заказов, количество активных пользователей, плюс как можно больше менее значимых параметров: распределение активности пользователей по регионам, самые популярные продукты на сайте, загрузка серверов. Только владея всей этой аналитической информацией можно понять, где вы находитесь в море бизнеса и куда нужно грести.
В 2012 году онлайн-платформа для распространения звуковых треков SoundCloud озадачилась поиском нового инструмента для аналитики. Взвесив все варианты и попробовав всё, что было на рынке в тот момент, в компании принялись за разработку своего решения.
В то время аналитические СУБД были либо слишком сложными, либо слишком ненадежными и медленными. В то же время начал набирать популярность язык Go. Система сбора метрик на Go могла стать на порядок круче аналогов, поэтому разработчики из SoundCloud решили написать собственный инструмент на нем.
Почему для сбора метрик нельзя использовать, скажем, MySQL?
Можно! Если у вас небольшой проект, малое количество значений в аналитике и данные редко обновляются — еще как можно. В остальных случаях стандартные СУБД не могут обеспечить нужной производительности и надежности. Все эти классные штуки типа индексов и транзакций, важные в других случаях, только замедляют работу базы данных, от которой требуется максимальная скорость и безотказность в записи метрик.
Поэтому для систем аналитики разработали концепцию time series database — систему хранения простых значений, привязанных к определенным моментам времени. У любой базы при таком подходе будет два измерения — момент времени и сами значения. Такой предельно простой подход к структуре хранимой информации позволяет заранее спланировать алгоритмы поиска и обработки значений, а также выжать максимальную скорость работы и надежность. Пространство состояний, в которых может находиться такая СУБД, предельно мало и хорошо описано.
Как мы строили мониторинг на Prometheus, Clickhouse и ELK
Меня зовут Антон Бадерин. Я работаю в компании «Центр Высоких Технологий» и занимаюсь системным администрированием. Неделю назад завершилась наша корпоративная конференция, где мы делились накопленным опытом с ИТ-сообществом Ижевска, нашего города. Я рассказывал про мониторинг веб-приложений.
Краеугольный камень, лежащий в основе любой системы мониторинга — решение задач бизнеса. Мониторинг ради мониторинга никому не интересен. А чего хочет бизнес? Чтобы все работало быстро и без ошибок. Бизнес хочет от нас проактивности, чтобы мы сами выявляли проблемы в работе сервиса и максимально быстро их устраняли. Это, по сути, и есть задачи, которые я решал весь прошлый год на проекте одного из наших заказчиков.
Проект — одна из крупнейших в стране программ лояльности. Мы помогаем розничным сетям увеличивать частоту продаж за счёт различных маркетинговых инструментов вроде бонусных карт. В общей сложности в проект входят 14 приложений, которые работают на десяти серверах.
В процессе ведения собеседований я неоднократно замечал, что админы далеко не всегда правильно подходят к мониторингу веб-приложений: до сих пор многие останавливаются на метриках операционной системы, изредка мониторят сервисы.
В моём случаем прежде в основе системы мониторинга заказчика лежала Icinga. Она никак не решала указанные выше задачи. Часто клиент сам сообщал нам о проблемах и не реже нам просто не хватало данных, чтобы докопаться до причины.
Кроме того, было чёткое понимание бесперспективности её дальнейшего развития. Я думаю, те кто знаком с Icinga меня поймут. Итак, мы решили полностью переработать систему мониторинга веб-приложений на проекте.
Мы выбрали Prometheus, исходя из трех основных показателей:
Ранее мы логи не собирали и не обрабатывали. Недостатки ясны всем. Мы выбрали ELK, поскольку опыт работы с этой системой у нас уже был. Храним там только логи приложений. Основными критериями выбора стали полнотекстовый поиск и его скорость.
Изначально выбор пал на InfluxDB. Мы осознавали необходимость сбора логов Nginx, статистики из pg_stat_statements, хранения исторических данных Prometheus. Influx нам не понравился, так как он периодически начинал потреблять большое количество памяти и падал. Кроме того, хотелось группировать запросы по remote_addr, а группировка в этой СУБД только по тэгам. Тэги дороги (память), их количество условно ограничено.
Мы начали поиски заново. Нужна была аналитическая база с минимальным потреблением ресурсов, желательно со сжатием данных на диске.
Clickhouse удовлетворяет всем этим критериям, и о выборе мы ни разу не пожалели. Мы не пишем в него каких-то выдающихся объёмов данных (количество вставок всего около пяти тысяч в минуту).
NewRelic исторически был с нами, так как это был выбор заказчика. У нас он используется в качестве APM.
Мы используем Zabbix исключительно для мониторинга Black Box различных API.
Нам хотелось декомпозировать задачу и тем самым систематизировать подход к мониторингу.
Для этого я разделил нашу систему на следующие уровни:
Чем удобен такой подход:
Так как наша задача выявлять нарушения в работе системы, мы должны на каждом уровне выделить некий набор метрик, на которые стоит обращать внимание при написании правил алертинга. Далее пройдемся по уровням «VMS», «Операционная система» и «Системные сервисы, стек ПО».
Хостинг выделяет нам процессор, диск, память и сеть. И с первыми двумя у нас были проблемы. Итак, метрики:
CPU stolen time — когда вы покупаете виртуалку на Amazon (t2.micro, к примеру), следует понимать, что вам выделяется не целое ядро процессора, а лишь квота его времени. И когда вы её исчерпаете, процессор у вас начнут забирать.
Эта метрика позволяет отслеживать такие моменты и принимать решения. Например, надо ли взять тариф пожирнее или разнести обработку фоновых задач и запросов в API на разные сервера.
IOPS + CPU iowait time — почему-то многие облачные хостинги грешат тем, что недодают IOPS. Более того, график с низкими IOPS для них не аргумент. Поэтому стоит собирать и CPU iowait. С этой парой графиков — с низкими IOPS и высоким ожиданием ввода-вывода — уже можно разговаривать с хостингом и решать проблему.
Метрики операционной системы:
Также на уровне операционной системы у нас появляется такая сущность, как процессы. Важно выделить в системе набор процессов, которые играют важную роль в её работе. Если, к примеру, у вас есть несколько pgpool, то необходимо собирать информацию по каждому из них.
Набор метрик следующий:
Весь мониторинг у нас развернут в Docker, для сбора данных метрик мы используем Сadvisor. На остальных машинах применяем process-exporter.
У каждого приложения есть своя специфика, и сложно выделить какой-то набор метрик.
Универсальным набором являются:
Наиболее яркие примеры мониторинга данного уровня у нас — Nginx и PostgreSQL.
Самый нагруженный сервис в нашей системе — база данных. Раньше у нас достаточно часто возникали проблемы с тем, чтобы выяснить, чем занимается база данных.
Мы видели высокую нагрузку на диски, но слоулоги ничего толком не показывали. Эту проблему мы решили с помощью pg_stat_statements, представления, в котором собирается статистика по запросам.
Это всё, что нужно админу.
Строим графики активности запросов на чтение и запись:
Всё просто и понятно, каждому запросу — свой цвет.
Не менее яркий пример — Nginx-логи. Не удивительно, что мало кто их парсит или упоминает в списке обязательных. Стандартный формат не очень информативен и его нужно расширять.
Лично я добавил request_time, upstream_response_time, body_bytes_sent, request_length, request_id.Строим графики времени ответа и количества ошибок:
Строим графики времени ответа и количества ошибок. Помните? я говорил про задачи бизнеса? Чтоб быстро и без ошибок? Мы уже двумя графиками эти вопросы закрыли. И по ним уже можно звонить дежурным админам.
Но осталась ещё одна проблема — обеспечить быстрое устранение причин инцидента.
Весь процесс от выявления до решения проблемы можно разбить на ряд шагов:
Важно, что мы должны это делать максимально быстро. И если на этапах выявления проблемы и отправки уведомления мы особо времени выиграть не можем — две минуты на них уйдут в любом случае, то последующие — просто непаханное поле для улучшений.
Давайте просто представим, что у дежурного зазвонил телефон. Что он будет делать? Искать ответы на вопросы — что сломалось, где сломалось, как реагировать? Вот каким образом мы отвечаем на эти вопросы:
Мы просто включаем всю эту информацию в текст уведомления, даем в нем ссылку на страницу в вики, где описано, как на эту проблему реагировать, как её решать и эскалировать.
Я до сих пор ничего не сказал про уровень приложения и бизнес логики. К сожалению, в наших приложениях пока не реализован сбор метрик. Единственный источник хоть какой то информации с этих уровней — логи.
Во-первых, пишите структурированные логи. Не надо включать контекст в текст сообщения. Это затрудняет их группировку и анализ. Logstash требует много времени, чтобы всё это нормализовать.
Во-вторых, правильно используйте severity-уровни. У каждого языка свой стандарт. Лично я выделяю четыре уровня:
Резюмирую. Нужно стараться выстраивать мониторинг именно от бизнес-логики. Стараться замониторить само приложение и оперировать уже такими метриками, как количество продаж, количество новых регистраций пользователей, количество активных в данный момент пользователей и так далее.
Если весь ваш бизнес — одна кнопка в браузере, необходимо мониторить, прожимается ли она, работает ли должным образом. Всё остальное не важно.
Если у вас этого нет, вы можете попытаться это наверстать в логах приложения, Nginx-логах и так далее, как это сделали мы. Вы должны быть как можно ближе к приложению.
Метрики операционной системы конечно же важны, но бизнесу они не интересны, нам платят не за них.