Настройка alertmanager prometheus telegram

Обновлено: 06.01.2025

Пример установки и настройки минимального мониторинга, чисто ознакомительного.

Все получившиеся в результате конфиги можно посмотреть в репозитории.

На хосте мониторинга, prometheus-server, будут:

сам promeheus сервер
grafana
node-exporter
cadvisor
alertmanager

Хост, который будем мониторить, prometheus-client:

Далее выполним настройку первого стека для Prometheus:

Второй Compose для клиента будет включать в себя:

Вроде всё? Поехали.

Virtualbox

Делать всё будем в Virtualbox, запускаем две машины, сначала сервер:

VBoxManage createvm --name "prometheus-server" --register Virtual machine 'prometheus-server' is created and registered. Settings file: '/home/setevoy/VirtualBox VMs/prometheus-server/prometheus-server.vbox' VBoxManage modifyvm "prometheus-server" --nic1 bridged --bridgeadapter1 enp0s25 --nictype1 82540EM --cableconnected1 on

Указываем тип ОС:

VBoxManage modifyvm "prometheus-server" --ostype Debian_64 VBoxManage createhd --filename prometheus-server.vdi --size 10000

Добавляем IDE контроллер к машине:

VBoxManage storagectl "prometheus-server" --name "IDE Controller" --add ide VBoxManage storageattach "prometheus-server" --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium prometheus-server.vdi

Устанавливем 2 гига памяти:

Подключаем ISO с Debian:

VBoxManage storageattach "prometheus-server" --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /home/setevoy/OS/debian-9.2.1-amd64-netinst.iso

Подготовка

Обвновляем всё на обоих хостах, сервере и клиенте:

На сервере устанавливаем NGINX:

На сервере и клиенте устанавливаем Docker:

И Docker Compose:

curl -o /usr/local/bin/docker-compose -L "https://github.com/docker/compose/releases/download/1.17.1/docker-compose-$(uname -s)-$(uname -m)"

] $ sudo sh -c "echo '10.11.100.166 prometheus-server.local' >> /etc/hosts"

] $ sudo sh -c "echo '10.11.100.167 prometheus-client.local' >> /etc/hosts"

Prometheus стек

Prometheus сервер

Теперь можно приступать к запуску сервисов, начинаем с хоста prometheus-server.local, клиент настроим в самом конце.

Создаём каталоги для хранения данных:

Первым запустим сам Prometheus сервер, создаём Compose файл:

С хоста проверяем:

HELP go_gc_duration_seconds A summary of the GC invocation durations.

Grafana

В этот же compose файл добавляем Grafana:

Проверяем данные в каталогах:

Проверяем Grafana:

И проверяем в браузере:

Настройка NGINX

Перезапускаем NGINX:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

Перезапускаем сервисы, проверяем доступ к Prometheus:

конфиг prometheus.yml

Добавляем файл настроек для Prometheus.

Создаём файл на хосте, и мапим его в контейнер.

Создаём файл /etc/prometheus/prometheus.yml :

Пока мы тут собираем метрики только с самого Prometheus сервера, позже добавим сбор с node-exporter и cAdvisor.

Перезапускаем сервисы, и получаем ошибку 404 в Targets:

Собственно, если проверить:

То ошибка воспроизводится.

Почему? Потому что в NGINX путь проксируется через location /prometheus :

HELP go_gc_duration_seconds A summary of the GC invocation durations.

Обновляем /etc/prometheus/prometheus.yml и добавляем relabel_configs :

Тут мы меняем значение __metrics_path__ со значения по умолчанию ( /metrics ) на /prometheus/metrics . Хорошая схема того, как применяются лейблы есть тут>>>.

node-exporter

Возвращемся к compose-файлу, и добавляем експортёр:

Перезапускаем сервисы, проверяем:

HELP go_gc_duration_seconds A summary of the GC invocation durations. HELP go_goroutines Number of goroutines that currently exist.

Обновляем /etc/prometheus/prometheus.yml и добавляем ещё один таргет в job-name "prometheus" :

Настройка Grafana

Добавляем data source:

Добавляем дашборд, например Prometheus system:

cAdvisor

Возвращаемся к Prometheus.

Обновляем compose файл, добавляем контейнер с cAdvisor:

Перезапускаем стек, проверяем:

HELP cadvisor_version_info A metric with a constant '1' value labeled by kernel version, OS version, docker version, cadvisor version & cadvisor revision. HELP container_cpu_system_seconds_total Cumulative system cpu time consumed in seconds.

Alertmanager

Теперь добавляем Alertmanager.

Сздаём каталог для настроек:

Создаём файл настроек /etc/alertmanager/config.yml :

В файл настроек Prometheus добавляем alerting (до Prometheus 1.4 алертменеджер указывался через --alermanager.url ):

И проверяем логи:

Alert для Docker сервисов

Запускаем новый контейнер:

65d38787c356c846bb635f4bd66c6fa96e41e4a08a0b6d48116996cbf70f88e8

Системы мониторинга наподобие Prometheus устанавливаются не только для того чтобы иметь красивые графики состояния сервера в определённый момент, но чтобы вовремя узнавать о возможных проблемах. Для этого у таких систем существуют уведомления - алерты. Prometheus тоже умеет генерировать алерты на основе настраиваемых правил, однако если состояние сервера совпадает с правилом Prometheus будет генерировать алерт при каждом обновлении.

Настройка Alertmanager для Prometheus

1. Настройка правил Prometheus

Первым делом необходимо настроить правила Prometheus чтобы программа генерировала алерты при возникновении тех или иных событий. Для правил надо создать отдельный файл в папке с конфигурацией prometheus, например, rules.yml:

sudo vi /etc/prometheus/rules.yml

Файл должен содержать данные в формате yaml. Все правила разбиты на группы. У каждой группы есть имя (name) и список правил (rules). Сначала посмотрим на общий синтаксис правила:

Давайте рассмотрим простое правило, отправлять алерт, если хост недоступен:

> - содержит значение переменной, участвующей в выражении;
> - IP адрес и порт экспортёра, с которым возникла проблема;
> - имя задачи из конфигурационного файла prometheus;

В конфигурационном файле это правило будет выглядеть вот так:

Этого правила хватит для тестирования alertmanager в этой статье. Больше полезных правил вы можете найти здесь. Теперь осталось добавить созданный файл с правилами в основной файл конфигурации prometheus. Для этого добавьте в него такие строчки:

sudo vi /etc/prometheus/prometheus.yml

Затем нужно проверить созданные правила, для этого выполните команду:

promtool check rules /etc/prometheus/rules.yml

Если всё прошло успешно, команда выведет слово SUCCESS и количество найденных правил. Если возникла ошибка, убедитесь что у вас верно расставлены отступы, формат YAML очень к нем чувствителен. Все элементы одной группы должны быть на одном уроне.

После внесения всех изменений перезапустите Prometheus:

sudo systemctl restart prometheus

2. Установка Alertmanager

Установить Alertmanager можно из официальных репозториев, но так вы получите программу более старой версии и без веб-интерфейса. Для установки выполните команду:

sudo apt install prometheus-alertmanager

После завершения установки веб-интерфейс можно развернуть командой:

Или же можно установить программу из официального сайта. Как и другие программы из этой экосистемы, alertmanager написан на Golang, поэтому состоит из одного исполняемого файла и нескольких конфигурационных файлов. Он не зависит от установленных в системе библиотек.

Сначала скачайте архив с исполняемыми файлами alertmanager из официальной страницы github, например:

Дальше распакуйте полученный архив:

tar -xvf alertmanager-0.21.0.linux-amd64.tar.gz

И скопируйте файлы alertmanager и amtool в папку /usr/local/bin:

sudo cp alertmanager-0.21.0.linux-amd64/alertmanager /usr/local/bin/
sudo cp alertmanager-0.21.0.linux-amd64/amtool /usr/local/bin/

Далее надо скопировать конфигурационный файл alertmanager.yml в /etc/prometheus:

sudo cp alertmanager-0.21.0.linux-amd64/alertmanager.yml /etc/prometheus

Дайте пользователю prometheus права на конфигурационный файл:

sudo chown -R prometheus:prometheus /etc/prometheus/alertmanager.yml

Осталось создать systemd сервис, с помощью которого вы сможете запускать программу.

sudo systemctl edit --full --force prometheus-alertmanager

[Unit]
Description=Alertmanager Service
After=network.target
[Service]
EnvironmentFile=-/etc/default/alertmanager
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/alertmanager $ARGS
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
[Install]
WantedBy=multi-user.target

Теперь можете запустить сервис:

sudo systemctl start prometheus-alertmanager

Веб-интерфейс будет доступен на порту 9093:

3. Настройка Prometheus

Дальше необходимо убедится, что в конфигурационном файле prometheus прописана отправка алертов в alertmanager. Найдите в нём или добавьте такую секцию:

sudo vi /etc/prometheus/alertmanager.yml

Если были внесены изменения, то prometheus надо перезапустить:

sudo systemctl restart prometheus

4. Настройка Alertmanager

Почти всё готово, теперь надо настроить сам Alertmanager. Надо указать как группировать алерты, когда и куда отправлять уведомления. Вот основное содержание конфигурационного файла:

Вот рабочий пример конфигурации с отправкой уведомлений на email:

sudo vi /etc/prometheus/alertmanager.yml

Дальше нужно только перезапустить Alertmanager:

sudo systemctl restart prometheus-alertmanager

5. Тестирование

Для тестирования на одном из серверов, с которых собирает данные Prometheus можно отключить node_exporter. Для этого выполните:

sudo systemctl stop prometheus-node-exporter

Подождите пока Prometheus снова опросит цели и в AlertManager появится этот алерт:

Сразу же он придет вам на почту:

Выводы

Нет похожих записей

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.

Мониторинг — это сбор метрик и представление этих метрик в удобном виде (таблицы, графики, шкалы, уведомления, отчёты). Концептуально его можно изобразить в таком виде:

Метрики — это абстракция, с которой мы имеем дело, когда говорим о мониторинге. Это какие-то числа, описывающие состояние интересующей нас штуковины. Самый простой и понятный мониторинг следит за ресурсами компьютера: загрузкой процессора, памяти, диска, сети. Аналогично можно следить за чем-то более высокоуровневым, вроде количества посетителей на сайте или среднего времени ответа сервера. Для компьютера это один хрен безликие числа.

Мониторинг — это инструмент анализа того, что происходит/происходило в системе. Следовательно, без понимания смысла собранных данных мониторинг вам не особо поможет. И наоборот: в умелых руках это мощный инструмент.

Чем больше компонентов в вашей системе (микросервисов), чем больше нагрузка на неё, чем дороже время простоя, тем важнее иметь хорошую систему мониторинга.

То, что не метрики — то логи. Их тоже надо собирать и анализировать, но это отдельная история со своими инструментами.

Сейчас модно делать мониторинг на основе Prometheus. Так ли он хорош на самом деле? На мой взгляд это лучшее, что сейчас есть из мониторинга. Оговорюсь сразу для тех, кто хочет с этим поспорить: я понимаю, что разным задачам — разные инструменты и где-то больше подходит старый проверенный Nagios. Но в целом лидирует Prometheus.

Prometheus — это не готовое решение в духе “поставил и работает” (привет, Netdata). Это платформа, набор инструментов, позволяющий сделать себе такой мониторинг, какой надо. Фреймворк, если хотите.

Эта статья про знакомство с Prometheus’ом и установку. Потом будет интереснее — про настройку непосредственно мониторинга.

Архитектура Prometheus

Prometheus server — центральное звено. Здесь хранятся собранные метрики, плюс имеется простенький веб-интерфейс, чтобы на них смотреть (Prometheus web UI).
Агенты, собирающие метрики и предоставляющие их в понятном для Prometheus’а виде. В зависимости от контекста называются экспортерами (exporter) или таргетами (target). Устанавливаются на целевые машины. Типичный представитель — node_exporter — собирает данные о вычислительных ресурсах: загрузку процессора, памяти, диска и т.п. Есть куча других экспортеров. Например, cadvisor собирает данные о контейнерах. Есть экспортеры для Postgres’а, для Nginx’а и т.д. С точки зрения самого Prometheus’а они ничем принципиально не отличаются друг от друга, просто каждый собирает какие-то свои метрики. Можно писать свои экспортеры, если ничего из готового вам не подходит.
Alertmanager — уведомлятор. Это он отправит письмо вам на почту, если что-то сломается. Из коробки умеет в почту, Slack, Hipchat, Pagerduty. Сторонними средствами можно прикрутить Telegram и наверное что-то ещё.
Grafana строго говоря не является частью Prometheus’а, но все её ставят и официальная документация рекомендует поступать именно так. Показывает красивые графики. Кучка графиков, собранных на одном экране, называется дашбордом (dashboard). Типа такого:

Установка

Все компоненты Prometheus’а написаны на Go и представляют собой статически скомпиленные бинари, не требующие никаких зависимостей кроме libc и готовые запускаться на любой платформе, будь то Debian, Arch или Centos. Установить их можно аж тремя способами:

по-старинке через пакетный менеджер,
взять готовые бинари с оф. сайта и засунуть их в систему в обход пакетного менеджера,
развернуть всё в докер-контейнерах.

Разумеется, у каждого способа есть свои преимущества и недостатки.

Если ставить через пакетный менеджер, то через него же вы будете получать обновления и сможете всё удалить. Однако есть нюанс. У Prometheus’а нет своих собственных репозиториев для популярных дистрибутивов, а официальные репозитории Debian/Ubuntu как всегда отстают от апстрима. Например, сейчас в Debian доступна версия 2.7.1, когда Prometheus уже 2.11.1. Arch Linux — молодец, идёт в ногу со временем.

При установке вручную Prometheus не будет числиться в списках установленного софта и с точки зрения пакетного менеджера его в системе нет. Зато вы сможете обновлять Prometheus отдельно от пакетов. При ручной установке придётся немного побывать в роли установочного скрипта (который есть в пакете), поэтому, если у вас серьёзные намерения — автоматизируйте установку/обновление через какой-нибудь Ansible. Рекомендую взять за основу готовые роли для Prometheus, Alertmanager, Node exporter, Grafana.

Если ставить Prometheus в докере, то всё про мониторинг будет лежать в одном месте. Можно это хозяйство положить под Git и иметь возможность поднять мониторинг в две команды: git clone , docker-compose up . Но надо писать правильный docker-compose.yml , париться при возникновении сетевых проблем… Короче, вы от одних проблем избавляетесь, а взамен получаете другие. В зависимости от того, с какими вам больше нравится возиться, выбирайте тот или иной вариант установки. Вам понадобятся контейнеры prom/prometheus , prom/node_exporter , prom/alertmanager . За основу рекомендую взять docker-compose.yml из репозитория docprom.

В продакшене я бы поднимал мониторинг в докере как минимум в целях безопасности. Свой личный мониторинг я устанавливал по-старинке вручную.

Установка вручную

Расскажу про ручную установку, потому что в основе других способов установки лежат те же действия, только завёрнутые в дополнительную обёртку. Этот способ подойдёт для любых дистрибутивов Linux под управлением systemd (Ubuntu, Debian, Centos, Arch и т.д.)

Установка Prometheus server

Раскидываем файлы по ФС, заводим пользователя:

В архиве будут два ненужных каталога: console_libraries/ и consoles/ . Их не трогаем.

Запускаем Prometheus server:

Установка node exporter

Важно! Если у вас /home вынесен на отдельный раздел, директиву ProtectHome=yes надо убрать, иначе node exporter будет неправильно показывать оставшееся место на разделе /home .

Запускаем node exporter:

Можно посмотреть как node exporter отдаёт метрики:

Пока не пытайтесь что-то понять в выводе. Отдаёт и ладно.

Установка alertmanager

Установка Grafana

Prometheus, Node exporter, Alertmanager и Grafana по умолчанию слушают на всех сетевых интерфейсах. При необходимости прикрывайтесь фаерволлом от посторонних глаз.

Первичная настройка

Теперь, когда все компоненты установлены, надо подружить их друг с другом. Сперва минимально настроим Prometheus server:

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

Отступы в yml — два пробела. Всегда и везде.
scrape_interval — с какой периодичностью Prometheus server будет забирать (scrape) метрики с экспортеров.
localhost:9093 и localhost:9100 — адреса alertmanager’а и node exporter’а соответственно. Если у вас другие, замените на правильные. Если у вас node exporter установлен на несколько машин, впишите их все.

Теперь попросим prometheus перечитать конфигурационный файл:

Поздравляю, мониторинг начал мониторить! Теперь можно пойти на вкладку Graph и запросить какую-нибудь метрику, например node_load1 — это одноминутный load average. Там же можно временной график посмотреть:

В повседневной жизни вы вряд ли будете смотреть графики в этом интерфейсе. Гораздо приятнее смотреть графики в Grafana.

Идём на вкладку Data Sources, добавляем наш Prometheus:

Теперь добавим готовый дашборд Node exporter full. Это лучший дашборд для старта из всех, что я пересмотрел. Идём Dashboards (квадрат) → Manage → Import.

Вписываем 1860 и убираем курсор из поля ввода, иначе не начнёт импортировать. Дальше указываем data source и жмём import.

Поздравляю, самая скучная часть работы проделана! Теперь вы можете наблюдать за жизнью своих серверов в Графане.

Если у вас серьёзные намерения и вы хотите, чтобы все компоненты автоматически запускались после перезагрузки машины, не забудьте сообщить об этом systemd:

И это всё?

У нас пока нет алертов, не заведены пользователи в Grafana, мы ничего не понимаем в настройке. Да, наш мониторинг пока очень сырой. Но надо же с чего-то начать! Позже я напишу про настройку, про алерты и многое другое. Всё будет, друзья. Всё будет.

prometheus-telegram - бот для расширения возможностей системы Prometheus по оповещению пользователей о наступлении аварийных событий.

Функциональные возможности программы.

Бот выполняет две задачи:

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

Решение состоит из двух основных компонентов:

Точки входа программы - скрипа main.py запускающего сервер.
Скрипта bot.py в котором описан класс Bot, отвечающий главным образом за взаимодействие с Telegram.

Помимо этого в проекте присутствуют:

конфигурационный файл - exhample_config
файл в котором храняться подписки пользователей на алармы - users
набор юнит-тестов test_prometheus_telegram.py
список зависимостей requirements.txt
файл для сборки докер-контейнера - Dockerfile

Описание основного скрипта main.py.

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

В основном скрипте в main на входе принимаются 4 аргумента:

порт '-p' или '--port'. По умолчанию значение 8080
хост '-H' или '--host'. По умолчанию равен '127.0.0.1'
путь до конфигурационного файла '-c' или '--config'. Изначально равен переменной DEFAULT_CONFIG
путь до лог-файла '-l' или '--log', по умолчанию отсутствует.

После этого функция связывает адрес и порт и начинает слушать буфер. Методом os.fork порождается дочерний процесс, в котором запускается общение бота с Telegram посредством bot.polling. Этот метод состоит в периодической отправке запросов get_updates на сервера Telegram. В случае наличия обновления, Telegram возвращает ответ с json, который будет обрабатываться ботом.

alertname - имя аларма
status - статус аларма (например firing или resolved)
startsAt - время возникновения аварийного события
node - узел на котором возникло событие

Описание класса взаимодействия с Telegram.

Конструктор класса Bot, как указывалось выше, описан в файле bot.py. Класс Bot отвечает за взаимодействие с Telegram. Так же в нем прописаны функции взаимодействия с Grafana. Взаимодействие с Grafana не является обязательным, достаточно указать "None" в любой из настроек графаны и функции взаимодействия с ней не будут включены. Класс Bot использует модуль pyTelegramBotAPI. Он наследуется от обьекта telebot.TeleBot, для которого необходимо указать токен бота. Так же в методе init конструктор принимает конфиг в виде списка. Так как бот работает только с помощью опроса сервера, то проски является обязательным. Так же в данном методе определяется обьект dashboards - это список дашбордов графаны. Если графана не подключена то обьект будет равен None.

После того, как мы уточнили эот момент рассмотрим функцию prepare_keyboard. Она будет генерировать клавиатуру, отдаваемую ботом пользователю в процессе интерактивного общения. Клавиатура будет формироваться из двух аргументов. Первый это список lst. Второй аргумент add_slash если не указан, то пользователю будет выдан список обычных кнопок из lst, если же он будет равен True то к каждой кнопке итоговой клавиатуры будет добавлен слеш / . Таким образом пользователю будет выдан список команд из lst.

Функция handle_help(message) обрабатывавет команду '/help'. Выводит расширенную подсказку и краткие примеры использования бота.

Функция handle_regexp(message) обрабатывает команду '/regexp'. Все что пользователь ввел после пробела от команды regexp заносится в подписку пользователю.

Функция handle_list(message) обрабатывает команду '/list'. Выводит пользователю его подписку.

Для получения информации о дашбордах и графиках Grafana используются функции get_grafana_dashboards и get_grafana_panels соответственно. Функции вызывают соответствующие методы API Grafana с помощью модуля requests.

Архитектурные особенности и дальнейшие планы.

В первую очередь узкое место решения, это использование метода bot.pooling и необходимости использовать прокси в условиях блокировки телеграм. Вариан, когда телеграм будет сам присылать обновления от пользователей исключил бы риски неработоспособности прокси.

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

Хранение списка пользователей в текстовом файле так же архитектурное допущение для небольшой планируемой нагрузки. Для более производительного решения лучше использовать базу данных или key-value хранилище, например redis.

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

Читайте также: