Prometheus ubuntu что это
Мониторинг сервисов с Prometheus
В предыдущих публикациях мы уже затрагивали вопросы мониторинга и сбора метрик. В сегодняшней статье мы хотели бы вернуться к этой теме и рассказать об интересном инструменте под названием Prometheus. Он был создан в 2012 году в качестве внутренней системы мониторинга небезызвестного проекта SoundCloud, но впоследствии получил более широкое распространение.
Prometheus — инструмент совсем новый (первый публичный релиз состоялся в начале 2015 года), и на русском языке публикаций о нём пока почти что нет (несколько месяцев назад была опубликована статья в журнале «Хакер», но она доступна только подписчикам).
Разработчики SoundCloud отмечают (см. подробный доклад здесь), что новый инструмент мониторинга понадобился им в связи с переходом к микросервисной архитектуре. Рост интереса к микросервисам — одна из характерных тенденций последних нескольких лет.
С точки зрения микросервисного подхода приложение пониматеся не как монолит, а как набор сервисов. Каждый из этих сервисов работает в своём процессе и взаимодействует с окружением при помощи простого механизма (как правило, через протокол HTTP).
Мониторинг микросервисов — задача непростая: в режиме реального времени нужно отслеживать как состояние отдельных компонентов, так и состояние системы в целом. Задача усложняется, если помимо технических нужно проверять ещё и бизнес-значимые показатели. Как отмечают сами разработчики Prometheus в многочисленных статьях и докладах, с помощью имеющихся систем мониторинга её решить проблематично. Поэтому они создали собственный инструмент.
Prometheus представляет собой комплексное решение, в состав которого входят и фреймворк для мониторинга, и собственная темпоральная база данных. В некоторых обзорах его даже называют «системой мониторинга нового поколения».
Публикации о Prometheus нас заинтересовали, и мы решили познакомиться с этим инструментом поближе.
Архитектура Prometheus
В состав Prometheus входят следующие компоненты:
Большинство из них написаны на Go, а совсем небольшая часть — на Ruby и Java.
Все компоненты Prometheus взаимодействуют между собой по протоколу HTTP:
Главный компонент всей системы — сервер Prometheus. Он работает автономно и сохраняет все данные в локальной базе данных. Обнаружение сервисов происходит автоматически. Это упрощает процедуру развёртывания: для наблюдения за одним сервисом не нужно разворачивать распределённую систему мониторинга; достаточно установить только сервер и необходимые компоненты для сбора и экспорта метрик. Таких компонентов, «заточенных» под конкретные сервисы, уже создано довольно много: для Haproxy, MySQL, PostrgreSQL и другие (полный список см. здесь, а также на GitHub).
Сбор метрик в Prometheus осуществляется с помощью механизма pull. Имеется также возможность сбора метрик с помощью механизма push (для этого используется специальный компонент pushgateway, который устанавливается отдельно). Это может понадобиться в ситуациях, когда сбор метрики с помощью pull по тем или иным причинам невозможен: например, при наблюдении за сервисами, защищёнными фаерволлом. Также механизм push может оказаться полезным при наблюдении за сервисами, подключающихся к сети периодически и на непродолжительное время.
Prometheus хорошо подходит для сбора и анализа данных, представленных в виде временных рядов (time series). Все метрики он хранит в собственной темпоральной БД (её сравнение с OpenTSDB и InfluxDB см. здесь); для хранения индексов используется LevelDB.
Модель данных
Prometheus хранит данные в виде временных рядов — наборов значений, соотнесённых с временной меткой (timestamp).
Элемент временного ряда (измерение) состоит из имени метрики, временной метки и пары «ключ — значение». Временные метки имеют точность до миллисекунд, значения представлены с 64-битной точностью.
Имя метрики указывает на параметр системы, о котором собираются данные. Например, у метрики с информацией о количестве HTTP-запросов к некоему API имя может выглядеть так: api_http_requests_total. Временной ряд в такой метрике может хранить информацию о обо всех GET-запросах на адрес /api/tracks, на которые был отдан ответ с кодом 200. Этот временной ряд можно представить в виде следующей нотации:
Модель данных, используемая в Prometheus, напоминает ту, что используется в OpenTSDB. У всех метрик есть имя, но оно может быть одним и тем же у нескольких рядов.
При этом каждый временной ряд должен быть помечен хотя бы одним тэгом. Измерения для одного тэга хранятся последовательно, что обеспечивает быструю агрегацию данных.
Поддерживаются следующие типы метрик:
Установка
Рассмотрим теперь практические аспекты использования Prometheus. Начнём с описания процедуры установки.
Совсем недавно Prometheus был включён в официальные репозитории Debian 8 и Ubuntu 15.10.
В Ubuntu 14.04 его тоже можно установить при помощи стандартного менеджера пакетов. Естественно, для этого понадобится подключить соответствующий репозиторий:
С помощью приведённых команд мы установили сервер Prometheus, а также дополнительные компоненты — node_exporter и alertmanager. Node_exporter собирает данные о состоянии сервера, а alertmanager (о нём мы более подробно поговорим ниже) — рассылает уведомления в случае выполнения или невыполнения заданных условий.
Установка завершена, но остался ещё один маленький штрих: нужно сделать так, чтобы node_exporter постоянно собирал метрики в фоновом режиме. Для этого сначала создадим символическую ссылку в /usr/bin:
Затем создадим файл /etc/init/node_exporter.conf и добавим в него следующие строки:
Сохраним внесённые изменения и выполним команду:
В дистрибутивах, перешедших на systemd (например, в Ubuntu 15.10), для запуска node_exporter в фоновом режиме нужно создать файл /etc/systemd/system/node_exporter.service и добавить в него следующие строки:
Сохранив внесённые изменения, нужно выполнить команды:
Конфигурирование
Настроек Prometheus по умолчанию вполне достаточно, чтобы следить за всем происходящим на локальной машине. Дополнительные настройки в случае необходимости всегда можно прописать в конфигурационном файле /etc/prometheus/prometheus.yml. Рассмотрим его структуру более подробно. Начинается он с секции globals:
Она включает следующие параметры:
Далее следует секция scrape_configs с базовыми настройками сбора метрик на сервере:
В этой же секции можно прописать дополнительные настройки:
Выше мы уже упомянули о том, что в конфигурационном файле можно ссылать на файлы правил. Правила помогают предварительно вычислять наиболее часто используемые или требующие значительных затрат ресурсов параметры и сохранять их в виде новых временных рядов. Осуществлять поиск по предварительно рассчитанным параметрам значительно проще, чем при каждом запросе заново вычислять их значения. Это может оказаться полезным, например, при работе с дашбордами, которые запрашивают значения параметров при каждом обновлении.
В общем виде синтаксис правил можно представить так:
Приведём более конкретные и понятные примеры:
Prometheus сверяется с правилами с определённой периодичностью, указанной в конфигурационном файле в параметре evaluation_interval). После каждой сверки Prometheus пересчитывает значение параметра и сохраняет его под новым именем с текущей временной меткой.
Итак, структуру и синтаксис конфигурационного файла мы в общих чертах рассмотрели. Чтобы прописанные настройки вступили в силу, нужно выполнить следующую команду (вместо path/to/prometheus.yml указываем путь к конфигурационному файлу):
Веб-интерфейс
Веб-интерфейс Prometheus будет доступен в браузере по адресу: http://[IP-адрес сервера]:9090:
В поле Expression можно выбрать метрику, для которой будет отображаться график. Попробуем отследить, например, объём активной памяти на сервере. Выбираем метрику node_memory_active и нажимаем на кнопку Execute:
Над графиком расположены кнопки, с помощью которых можно выбирать период для отображения статистики.
Шаблоны консолей
Если вам не подходит ни одна из имеющихся консолей, вы можете создать собственную консоль, которая будет отображать нужную вам статистику. Для написания консолей в Prometheus используется HTML-шаблонизатор Go. Подробные инструкции по созданию кастомных консолей приведены в официальной документации.
А если вас по тем или иным причинам не устраивают имеющиеся консоли, вы можете интегрировать Prometheus с популярным инструментом Grafana.
Разработчики Prometheus создали и собственный инструмент для создания дашбордов под названием Promdash (см. также репозиторий на GitHub), по интерфейсу напоминающий Grafana. На наш взгляд, он ещё находится в несколько «сыром» состоянии, и рекомендовать его к использованию пока что рано.
Alertmanager: настройка уведомлений
Ни один инструмент мониторинга немыслим без компонента для рассылки уведомлений. В Prometheus для этой цели используется alertmanager. Настройки уведомлений хранятся в конфигурационном файле alertmanager.conf.
Рассмотрим следующий фрагмент:
Его синтаксис вполне понятен: мы указали, что уведомления при наступлении определённого условия нужно отправлять по электронной почте на адрес test@example.org.
В конфигурационный файл можно добавлять ссылки на файлы правил (по сути они ничем не отличаются от файлов правил для сбора метрик, описанных выше). В правилах прописываются условия, при которых нужно отправлять уведомления.
В общем виде синтаксис правила выглядит так:
Рассмотрим функции правил на более конкретных примерах.
Пример1:
Это правило указывает, что уведомление нужно отправлять в случае, если некоторый инстанс недоступен в течение 5 минут и более.
Согласно этому правилу, уведомления нужно посылать, как только среднее время ответа на запросы к API превысит 1 мс.
Чтобы прописанные в конфигурационном файле настройки вступили в силу, нужно сохранить его и выполнить команду:
Можно создать несколько конфигурационных файлов и прописать в них настройки уведомлений для различных случаев.
Уведомления Prometheus отправляет в формате JSON. Выглядят они примерно так:
Отправка уведомлений осуществляется по электронной почте, через веб-хук, а также с помощью специализированных сервисов: PagerDuty, HipChat и других.
Разработчики Prometheus отмечают, что пока что alertmanager находится в «сыром» состоянии и предупреждают о возможных ошибках. Впрочем, мы никаких аномалий в работе этого компонента не заметили.
Заключение
Prometheus — инструмент достаточно интересный и перспективный, и на него стоит обратить внимание. В числе его преимуществ нужно в первую очередь выделить:
Если у вас уже есть практический опыт использования Prometheus, поделитесь впечатлениями. Будем благодарны за любые полезные замечания и дополнения.
Для желающих узнать больше приводим несколько полезных ссылок:
Если вы по тем или иным причинам не можете оставлять комментарии здесь — приглашаем в наш блог.
Установка Prometheus + Alertmanager + node_exporter на Linux
В двух словах, Prometheus — система мониторинга, обладающая возможностями тонкой настройки метрик. Она будет полезна для отслеживания состояния работы сервисов на низком уровне.
Данная инструкция позволит установить prometheus как на системы RPM (Red Hat, CentOS), так и deb (Debian, Ubuntu). Помимо Prometheus мы установим Alertmanager для возможности отправлять тревоги и node_exporter для мониторинга сервера Linux.
Подготовка сервера
Настроим некоторые параметры сервера, необходимые для правильно работы системы.
Время
Для отображения событий в правильное время, необходимо настроить его синхронизацию. Для этого установим chrony:
а) если на системе CentOS / Red Hat:
yum install chrony
systemctl enable chronyd
systemctl start chronyd
б) если на системе Ubuntu / Debian:
apt-get install chrony
systemctl enable chrony
systemctl start chrony
Брандмауэр
На фаерволе, при его использовании, необходимо открыть порты:
а) с помощью firewalld:
б) с помощью iptables:
ufw allow 9090,9093,9094,9100/tcp
SELinux
По умолчанию, SELinux работает в операционный системах на базе Red Hat. Проверяем, работает ли она в нашей системе:
Если мы получаем в ответ:
. необходимо отключить его командами:
* если же мы получим ответ The program ‘getenforce’ is currently not installed, то SELinux не установлен в системе.
Prometheus
Prometheus не устанавливается из репозитория и имеет, относительно, сложный процесс установки. Необходимо скачать исходник, создать пользователя, вручную скопировать нужные файлы, назначить права и создать юнит для автозапуска.
Загрузка
Переходим на официальную страницу загрузки и копируем ссылку на пакет для Linux:
. и используем ее для загрузки пакета на Linux:
* если система вернет ошибку, необходимо установить пакет wget.
Установка (копирование файлов)
После того, как мы скачали архив prometheus, необходимо его распаковать и скопировать содержимое по разным каталогам.
Для начала создаем каталоги, в которые скопируем файлы для prometheus:
Распакуем наш архив:
tar zxvf prometheus-*.linux-amd64.tar.gz
. и перейдем в каталог с распакованными файлами:
Распределяем файлы по каталогам:
cp prometheus promtool /usr/local/bin/
Назначение прав
Создаем пользователя, от которого будем запускать систему мониторинга:
* мы создали пользователя prometheus без домашней директории и без возможности входа в консоль сервера.
Задаем владельца для каталогов, которые мы создали на предыдущем шаге:
Задаем владельца для скопированных файлов:
chown prometheus:prometheus /usr/local/bin/
Запуск и проверка
Запускаем prometheus командой:
. мы увидим лог запуска — в конце «Server is ready to receive web requests»:
level=info ts=2019-08-07T07:39:06.849Z caller=main.go:621 msg=» Server is ready to receive web requests. «
Открываем веб-браузер и переходим по адресу http:// :9090 — загрузится консоль Prometheus:
Автозапуск
Мы установили наш сервер мониторинга, но его необходимо запускать вручную, что совсем не подходит для серверных задач. Для настройки автоматического старта Prometheus мы создадим новый юнит в systemd.
Возвращаемся к консоли сервера и прерываем работу Prometheus с помощью комбинации Ctrl + C. Создаем файл prometheus.service:
[Unit]
Description=Prometheus Service
After=network.target
Перечитываем конфигурацию systemd:
systemctl enable prometheus
После ручного запуска мониторинга, который мы делали для проверки, могли сбиться права на папку библиотек — снова зададим ей владельца:
systemctl start prometheus
. и проверяем, что она запустилась корректно:
systemctl status prometheus
Alertmanager
Alertmanager нужен для сортировки и группировки событий. Он устанавливается по такому же принципу, что и prometheus.
Загрузка
На той же официальной странице загрузки копируем ссылку на Alertmanager для Linux:
После предыдущей установки мы должны были остаться в каталоге прометеуса — выходим на уровень выше:
Теперь используем ссылку для загрузки alertmanager:
Установка
Создаем каталоги для alertmanager:
mkdir /etc/alertmanager /var/lib/prometheus/alertmanager
Распакуем наш архив:
tar zxvf alertmanager-*.linux-amd64.tar.gz
. и перейдем в каталог с распакованными файлами:
Распределяем файлы по каталогам:
cp alertmanager amtool /usr/local/bin/
cp alertmanager.yml /etc/alertmanager
Назначение прав
Создаем пользователя, от которого будем запускать alertmanager:
* мы создали пользователя alertmanager без домашней директории и без возможности входа в консоль сервера.
Задаем владельца для каталогов, которые мы создали на предыдущем шаге:
Задаем владельца для скопированных файлов:
chown alertmanager:alertmanager /usr/local/bin/
Автозапуск
Создаем файл alertmanager.service в systemd:
[Unit]
Description=Alertmanager Service
After=network.target
Перечитываем конфигурацию systemd:
systemctl enable alertmanager
systemctl start alertmanager
Открываем веб-браузер и переходим по адресу http:// :9093 — загрузится консоль alertmanager:
node_exporter
Для получения метрик от операционной системы, установим и настроим node_exporter на тот же сервер прометеуса (и на все клиентские компьютеры). Процесс установки такой же, как у Prometheus и Alertmanager.
Если мы устанавливаем node_exporter на клиента, необходимо проверить наличие брандмауэра и, при необходимости, открыть tcp-порт 9100.
Загрузка
Заходим на страницу загрузки и копируем ссылку на node_exporter:
* обратите внимание, что для некоторых приложений есть свои готовые экспортеры.
После предыдущей установки мы должны были остаться в каталоге алерт менеджера — выходим на уровень выше:
Теперь используем ссылку для загрузки node_exporter:
Установка
Распакуем скачанный архив:
tar zxvf node_exporter-*.linux-amd64.tar.gz
. и перейдем в каталог с распакованными файлами:
Копируем исполняемый файл в bin:
cp node_exporter /usr/local/bin/
Назначение прав
Создаем пользователя nodeusr:
Задаем владельца для исполняемого файла:
Автозапуск
Создаем файл node_exporter.service в systemd:
[Unit]
Description=Node Exporter Service
After=network.target
Перечитываем конфигурацию systemd:
systemctl enable node_exporter
systemctl start node_exporter
Открываем веб-браузер и переходим по адресу http:// :9100/metrics — мы увидим метрики, собранные node_exporter:
Отображение метрик с node_exporter в консоли prometheus
Открываем конфигурационный файл prometheus:
В разделе scrape_configs добавим:
scrape_configs:
.
— job_name: ‘node_exporter_clients’
scrape_interval: 5s
static_configs:
— targets: [‘192.168.0.14:9100′,’192.168.0.15:9100’]
* в данном примере мы добавили клиента с IP-адресом 192.168.0.14, рабочее название для группы клиентов node_exporter_clients. Для примера, мы также добавили клиента 192.168.0.15 — чтобы продемонстрировать, что несколько клиентов добавляется через запятую.
Чтобы настройка вступила в действие, перезагружаем наш сервис prometheus:
systemctl restart prometheus
. в открывшемся окне мы должны увидеть нашу группу хостов и сам компьютер с установленной node_exporter:
* статус также должен быть UP.
Отображение тревог
Создадим простое правило, реагирующее на недоступность клиента.
Создаем файл с правилом:
Теперь подключим наше правило в конфигурационном файле prometheus:
* в данном примере мы добавили наш файл alert.rules.yml в секцию rule_files. Закомментированные файлы first_rules.yml и second_rules.yml уже были в файле в качестве примера.
systemctl restart prometheus
Открываем веб-консоль прометеуса и переходим в раздел Alerts. Если мы добавим клиента и попробуем его отключить для примера, мы увидим тревогу:
Отправка уведомлений
Теперь настроим связку с алерт менеджером для отправки уведомлений на почту.
В секцию global добавим:
global:
.
smtp_from: monitoring@dmosk.ru
* мы будем отправлять сообщения от email monitoring@dmosk.ru.
Приведем секцию route к виду:
route:
group_by: [‘alertname’, ‘instance’, ‘severity’]
group_wait: 10s
group_interval: 10s
repeat_interval: 1h
receiver: ‘web.hook’
routes:
— receiver: send_email
match:
alertname: InstanceDown
* в данном примере нами был добавлен маршрут, который отлавливает событие InstanceDown и запускает ресивер send_email.
. далее добавим еще один ресивер:
receivers:
.
— name: send_email
email_configs:
— to: alert@dmosk.ru
smarthost: localhost:25
require_tls: false
* в данном примере мы отправляем сообщение на почтовый ящик alert@dmosk.ru с локального сервера. Обратите внимание, что для отправки почты наружу у нас должен быть корректно настроенный почтовый сервер (в противном случае, почта может попадать в СПАМ).
Перезапустим сервис для алерт менеджера:
systemctl restart alertmanager
Теперь настроим связку prometheus с alertmanager — открываем конфигурационный файл сервера мониторинга:
Приведем секцию alerting к виду:
alerting:
alertmanagers:
— static_configs:
— targets:
— 192.168.0.14:9093
* где 192.168.0.14 — IP-адрес сервера, на котором у нас стоит alertmanager.
systemctl restart prometheus
Немного ждем и заходим на веб интерфейс алерт менеджера — мы должны увидеть тревогу:
. а на почтовый ящик должно прийти письмо с тревогой.
Мониторинг служб Linux
Для мониторинга сервисов с помощью Prometheus мы настроим сбор метрик и отображение тревог.
Сбор метрие с помощью node_exporter
Открываем сервис, созданный для node_exporter:
. и добавим к ExecStart:
* данная опция указывает экспортеру мониторить состояние каждой службы.
При необходимости, мы можем либо мониторить отдельные службы, добавив опцию collector.systemd.unit-whitelist:
* в данном примере будут мониториться только сервисы chronyd, mariadb и nginx.
. либо наоборот — мониторить все службы, кроме отдельно взятых:
* при такой настройке мы запретим мониторинг сервисов auditd, dbus и kdump.
Чтобы применить настройки, перечитываем конфиг systemd:
systemctl restart node_exporter
Отображение тревог
Настроим мониторинг для службы NGINX.
Создаем файл с правилом:
Подключим файл с описанием правил в конфигурационном файле prometheus:
* в данном примере мы добавили наш файл services.rules.yml к уже ранее добавленному alert.rules.yml в секцию rule_files.
systemctl restart prometheus
Для проверки, остановим наш сервис:
systemctl stop nginx
В консоли Prometheus в разделе Alerts мы должны увидеть тревогу:
LaurVas
Мониторинг — это сбор метрик и представление этих метрик в удобном виде (таблицы, графики, шкалы, уведомления, отчёты). Концептуально его можно изобразить в таком виде:
Метрики — это абстракция, с которой мы имеем дело, когда говорим о мониторинге. Это какие-то числа, описывающие состояние интересующей нас штуковины. Самый простой и понятный мониторинг следит за ресурсами компьютера: загрузкой процессора, памяти, диска, сети. Аналогично можно следить за чем-то более высокоуровневым, вроде количества посетителей на сайте или среднего времени ответа сервера. Для компьютера это один хрен безликие числа.
Мониторинг — это инструмент анализа того, что происходит/происходило в системе. Следовательно, без понимания смысла собранных данных мониторинг вам не особо поможет. И наоборот: в умелых руках это мощный инструмент.
Чем больше компонентов в вашей системе (микросервисов), чем больше нагрузка на неё, чем дороже время простоя, тем важнее иметь хорошую систему мониторинга.
То, что не метрики — то логи. Их тоже надо собирать и анализировать, но это отдельная история со своими инструментами.
Сейчас модно делать мониторинг на основе Prometheus. Так ли он хорош на самом деле? На мой взгляд это лучшее, что сейчас есть из мониторинга. Оговорюсь сразу для тех, кто хочет с этим поспорить: я понимаю, что разным задачам — разные инструменты и где-то больше подходит старый проверенный Nagios. Но в целом лидирует Prometheus.
Prometheus — это не готовое решение в духе “поставил и работает” (привет, Netdata). Это платформа, набор инструментов, позволяющий сделать себе такой мониторинг, какой надо. Фреймворк, если хотите.
Эта статья про знакомство с Prometheus’ом и установку. Потом будет интереснее — про настройку непосредственно мониторинга.
Архитектура Prometheus
Prometheus состоит из отдельных компонентов, которые общаются друг с другом по http. Всё модно-молодёжно, с веб-интерфейсами и настраивается в yaml-конфигах.
Установка
Все компоненты 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.
В продакшене я бы поднимал мониторинг в докере как минимум в целях безопасности. Свой личный мониторинг я устанавливал по-старинке вручную.
Установка вручную
Расскажу про ручную установку, потому что в основе других способов установки лежат те же действия, только завёрнутые в дополнительную обёртку. Этот способ подойдёт для любых дистрибутивов Linux под управлением systemd (Ubuntu, Debian, Centos, Arch и т.д.)
Установка Prometheus server
Идём на https://github.com/prometheus/prometheus/releases, находим билд под свою платформу (скорее всего это будет linux-amd64). Копипастим ссылку, качаем:
Раскидываем файлы по ФС, заводим пользователя:
Запускаем Prometheus server:
В статусе должно быть написано “active (running)” — значит работает. Теперь можно сходить на http://localhost:9090 и полюбоваться на интерфейс Prometheus’а. Пока что он бесполезен, но уже можно потыкать.
Установка node exporter
Node exporter надо раскатать на всех машинах, которые вы хотите мониторить. Устанавливается он аналогично серверу. Берём последний билд с https://github.com/prometheus/node_exporter/releases.
Запускаем node exporter:
Можно посмотреть как node exporter отдаёт метрики:
Пока не пытайтесь что-то понять в выводе. Отдаёт и ладно.
Установка alertmanager
Alertmanager — это про алерты. Первое время алертов у вас не будет, поэтому сейчас его можно не ставить. Но лучше всё-таки поставить, чтобы всё необходимое уже было подготовлено. Идём за дистрибутивом на https://github.com/prometheus/alertmanager/releases.
Веб-интерфейс alertmanager’а доступен на http://localhost:9093. Пока в нём нет ничего интересного.
Установка Grafana
Если у вас Debian/Ubuntu или Redhat/Centos, лучше установить Grafana из пакета. Ссылочки найдёте в описании под видео на https://grafana.com/grafana/download.
Prometheus, Node exporter, Alertmanager и Grafana по умолчанию слушают на всех сетевых интерфейсах. При необходимости прикрывайтесь фаерволлом от посторонних глаз.
Первичная настройка
Теперь, когда все компоненты установлены, надо подружить их друг с другом. Сперва минимально настроим Prometheus server:
Пока не буду вдаваться в подробности настройки, этим займёмся в следующих статьях. На текущем этапе надо получить пусть примитивный, но работающий мониторинг. Основное что сейчас стоит знать:
Теперь попросим prometheus перечитать конфигурационный файл:
В веб-интерфейсе на странице http://localhost:9090/targets появился первый таргет. Он должен быть в состоянии “UP”.
Поздравляю, мониторинг начал мониторить! Теперь можно пойти на вкладку Graph и запросить какую-нибудь метрику, например node_load1 — это одноминутный load average. Там же можно временной график посмотреть:
В повседневной жизни вы вряд ли будете смотреть графики в этом интерфейсе. Гораздо приятнее смотреть графики в Grafana.
Открываем интерфейс Grafana по адресу http://localhost:3000. Логинимся (admin:admin), при желании меняем пароль. Практически всё в Графане настраивается тут же, через веб-интерфейс. Нажимаем на боковой панели Configuration (шестерёнка) → Preferences:
Идём на вкладку Data Sources, добавляем наш Prometheus:
Теперь добавим готовый дашборд Node exporter full. Это лучший дашборд для старта из всех, что я пересмотрел. Идём Dashboards (квадрат) → Manage → Import.
Вписываем 1860 и убираем курсор из поля ввода, иначе не начнёт импортировать. Дальше указываем data source и жмём import.
Поздравляю, самая скучная часть работы проделана! Теперь вы можете наблюдать за жизнью своих серверов в Графане.
Если у вас серьёзные намерения и вы хотите, чтобы все компоненты автоматически запускались после перезагрузки машины, не забудьте сообщить об этом systemd:
И это всё?
У нас пока нет алертов, не заведены пользователи в Grafana, мы ничего не понимаем в настройке. Да, наш мониторинг пока очень сырой. Но надо же с чего-то начать! Позже я напишу про настройку, про алерты и многое другое. Всё будет, друзья. Всё будет.