Эксперты в подборе IT-оборудования
Представьте ситуацию: в понедельник утром пользователи жалуются на медленную работу корпоративного портала. Администратор заходит на сервер, видит нормальную загрузку процессора и памяти, но не может понять, что именно происходило в выходные. Журналы показывают только текущее состояние, а картина происходившего накануне остаётся неясной.
Такие ситуации и делают систему мониторинга обязательной частью инфраструктуры. Нужны инструменты, которые непрерывно собирают данные о работе серверов и показывают их в понятном виде. Связка Prometheus и Grafana стала для этого фактическим стандартом.
Prometheus собирает и хранит метрики, Grafana строит по ним графики и панели. Дальше разберём, как это устроено, и покажем рабочие конфигурации, запросы и правила оповещений - те, что можно скопировать и применить. Метрики отвечают на вопрос «что-то сломалось», а на вопрос «где именно в цепочке» отвечает трассировка запросов.
Prometheus - это система мониторинга и оповещений с открытым исходным кодом. Её разработали в SoundCloud, а затем передали в Cloud Native Computing Foundation.
Главное отличие от привычных систем - способ сбора данных. Вместо того чтобы ждать, пока агенты на серверах пришлют метрики, Prometheus сам ходит по адресам и забирает их. Такой подход называют pull-моделью: сервер мониторинга сам решает, кого и как часто опрашивать, и сразу видит, что цель недоступна.
Сервер Prometheus собирает и хранит метрики. Он периодически опрашивает настроенные адреса (их называют целями), получает данные в простом текстовом формате и складывает во встроенную базу временных рядов. Частота опроса настраивается для каждой цели отдельно: от нескольких секунд для критичных метрик до минут для второстепенных.
Экспортеры (exporters) - небольшие программы, которые переводят метрики конкретной системы в формат Prometheus. Node Exporter отдаёт системные метрики Linux: загрузку процессора, использование памяти, дисковое пространство, сетевой трафик. MySQL Exporter достаёт статистику из базы, Nginx Exporter - из веб-сервера. Экспортеры есть практически под любой популярный софт.
Pushgateway нужен для задач, которые живут слишком мало, чтобы их успели опросить: разовые скрипты, задания по расписанию. Они сами отправляют метрики в шлюз, а Prometheus забирает их уже оттуда.
Обнаружение целей (service discovery) избавляет от ручного ведения списка серверов. В средах, где машины создаются и удаляются автоматически, Prometheus сам подхватывает новые цели через Kubernetes, Consul, DNS и другие источники.
Prometheus хранит метрики в виде имени и набора меток. Например, http_requests_total{method="GET", endpoint="/api/users", status="200"} - это счётчик HTTP-запросов с конкретными характеристиками.
Метки дают гибкость: по ним можно группировать, фильтровать и сравнивать срезы данных. Язык запросов PromQL считает по этим рядам производные величины - скорость роста, средние, процентили.
Типы метрик:
С выходом Prometheus 3.0 к классической гистограмме добавились нативные гистограммы: границы корзин у них не задаются вручную, а строятся автоматически по экспоненциальной шкале. Это заметно экономит место и снимает главную боль классических гистограмм - необходимость угадывать границы заранее и переделывать их, когда данные изменились.
Третья версия вышла в ноябре 2024 года - первый мажорный релиз за семь лет после версии 2.0. Если вы разворачиваете мониторинг сейчас, стоит знать, что изменилось.
/api/v1/otlp/v1/metrics. Раньше для этого нужен был отдельный сборщик посередине.Обновление с версии 2.x в целом безболезненное, но перед переходом стоит прочитать список несовместимых изменений: часть флагов командной строки и устаревших возможностей убрали.
Данные Prometheus ценны, но в исходном виде это столбцы чисел. Grafana превращает временные ряды в графики и панели, на которые можно смотреть.
Grafana - веб-приложение для визуализации, работающее с десятками источников данных. Именно связка с Prometheus сделала её стандартом в инфраструктурных командах.
Хорошая панель показывает состояние системы с первого взгляда. Не стоит выводить на один экран всё, что собирается: это шум, в котором проблему не видно.
Работает многоуровневый подход. Верхний уровень показывает общую картину: доступность сервисов, суммарную нагрузку, количество ошибок. Панели следующего уровня раскрывают детали по конкретному компоненту - метрики отдельного сервера, производительность базы, статистику приложения.
Тип визуализации подбирают под данные. Временные ряды показывают тренды: загрузку процессора за сутки, рост объёма базы. Панель с одним числом (Single stat) выводит текущее значение: сколько свободного места осталось, сколько пользователей онлайн. Тепловая карта (heat map) хороша для распределений - например, времени отклика по часам суток.
Цвет помогает читать панель быстро: зелёный для нормы, жёлтый для предупреждения, красный для аварии. Пороги задаются для каждой панели отдельно.
Переменные позволяют сделать одну панель вместо десяти одинаковых. Вместо отдельного дашборда на каждый сервер создаётся шаблон с переменной $server, и данные переключаются выбором из списка.
Переменные типа Query заполняются прямо из Prometheus: например, список всех доступных серверов извлекается из меток метрик. Пользователь выбирает нужный из выпадающего списка, и все панели перестраиваются.
Переменные типа Interval меняют шаг агрегации. Для долгих трендов удобны часы и дни, для разбора инцидента - минуты и секунды.
Развёртывание связки требует понимания того, что и откуда собирается.
Всё поведение задаётся файлом prometheus.yml. Минимальная рабочая конфигурация, которая опрашивает сам Prometheus и два сервера с Node Exporter:
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
- "alerts.yml"
alerting:
alertmanagers:
- static_configs:
- targets: ["localhost:9093"]
scrape_configs:
- job_name: "prometheus"
static_configs:
- targets: ["localhost:9090"]
- job_name: "node"
static_configs:
- targets: ["10.0.0.11:9100", "10.0.0.12:9100"]
labels:
env: "prod"
Секция scrape_configs перечисляет цели. Блок static_configs подходит, когда список серверов меняется редко: адреса вписываются руками. Метки в labels добавляются ко всем метрикам этой группы - потом по ним удобно фильтровать в запросах.
Сам Node Exporter слушает порт 9100. Проверить, что он отдаёт метрики, можно так:
curl -s http://10.0.0.11:9100/metrics | head
Ставится он по-разному, и здесь есть ловушка с названием службы. В Debian и Ubuntu пакет из репозитория называется prometheus-node-exporter, и служба тоже:
apt install prometheus-node-exporter
systemctl status prometheus-node-exporter
Если же вы разворачиваете экспортер из архива с GitHub, файл службы пишете сами, и назвать его можно как угодно - обычно node_exporter. Команда systemctl status node_exporter на системе с пакетом из репозитория ничего не найдёт, и на этом теряют время чаще всего.
Перенастройка меток (relabeling) - механизм, который правит метки во время сбора: переименовывает, добавляет новые на основе существующих, отбрасывает лишние метрики. Пригождается, когда нужно привести к единому виду метки из разнородных источников.
Prometheus подключается в Grafana как источник данных. Что вписать:
http://prometheus:9090 или http://localhost:9090.prometheus.yml. Если оставить значение по умолчанию, Grafana будет неверно выбирать шаг агрегации.Дашборды удобно раскладывать по папкам - по командам, типам сервисов, площадкам. Права доступа настраиваются на уровне папки.
Раздел для тех, кто уже поднял сбор и не хочет искать формулы по форумам. Все запросы работают на метриках Node Exporter.
Загрузка процессора в процентах:
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
Prometheus не отдаёт загрузку напрямую - он считает время простоя. Поэтому берём скорость роста счётчика простоя за пять минут, усредняем по ядрам и вычитаем из ста.
Свободная память в процентах:
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
Именно MemAvailable, а не MemFree: второе не учитывает кэш, который система отдаст приложению по первому требованию, и потому регулярно пугает нулями на здоровой машине.
Свободное место на дисках в процентах:
node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} / node_filesystem_size_bytes * 100
Фильтр по fstype убирает временные файловые системы, иначе список забьётся контейнерными точками монтирования.
Когда закончится место - прогноз по тренду за последние шесть часов на четверо суток вперёд:
predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
Самый полезный запрос из всех: он ловит заполнение диска до того, как оно случилось.
Средняя нагрузка на ядро:
node_load5 / count by(instance) (node_cpu_seconds_total{mode="idle"})
Голая load average без деления на число ядер ничего не говорит: 8 на восьмиядерной машине и на двухъядерной - разные ситуации.
Сервер перезагружался за последний час:
changes(node_boot_time_seconds[1h]) > 0
Сбор и графики - половина системы мониторинга. Вторая половина - автоматические оповещения, потому что круглосуточно смотреть на панели никто не будет.
Правила оповещений описываются в конфигурации Prometheus запросами PromQL, а обработкой занимается отдельный компонент - Alertmanager. Он получает сработавшие правила, группирует их, подавляет дубли и рассылает по каналам.
Так выглядит правило целиком - файл alerts.yml, на который ссылается конфигурация выше:
groups:
- name: node
rules:
- alert: DiskWillFillIn4Days
expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
for: 30m
labels:
severity: warning
annotations:
summary: "Диск / на {{ $labels.instance }} заполнится за четверо суток"
Ключевой здесь параметр for: он требует, чтобы условие держалось полчаса подряд, и отсекает короткие всплески. Без него вы получите оповещение от каждой временной просадки.
Группировка спасает от лавины писем. Если одновременно отвалились десять серверов в одной стойке, разумнее получить одно сводное сообщение вместо десяти. Alertmanager группирует по меткам - по площадке, типу сервиса, ответственной команде.
Электронная почта остаётся рабочим вариантом для некритичных оповещений. Мессенджеры - Telegram, Slack, Teams - удобны для командной работы: инцидент обсуждается прямо рядом с оповещением.
Для критичных событий нужна гарантированная доставка с эскалацией: если дежурный не отреагировал, оповещение уходит следующему. Такие сервисы умеют звонить и слать SMS.
Webhooks связывают Alertmanager с корпоративными системами учёта инцидентов. Подробнее про построение системы оповещений - в отдельном разборе алертинга и уведомлений.
Здесь заканчивается типовая статья про Prometheus и начинается практика. Node Exporter показывает, что происходит в операционной системе. Но сервер выходит из строя обычно не из-за загрузки процессора, а из-за железа: деградировал массив, отвалился блок питания, забился пылью радиатор.
| Что снимать | Чем | Порог, при котором пора реагировать |
|---|---|---|
| Загрузка процессора, память, диски, сеть | node_exporter | Место на диске меньше 15%, память в свопе |
| Состояние дисков (SMART) | smartctl_exporter (порт 9633) | Растут переназначенные секторы, ошибки чтения |
| Температуры, вентиляторы, блоки питания | ipmi_exporter | Отклонение от нормы по паспорту платформы |
| Состояние RAID-массива | textfile-коллектор node_exporter + скрипт вендорской утилиты | Любой диск не в состоянии Online |
| Аппаратные журналы и события | ipmi_exporter, Redfish | Появление записей уровня Critical |
Про ipmi_exporter и smartctl_exporter: оба поддерживаются сообществом Prometheus. Первый умеет опрашивать сервер по сети через IPMI, то есть работает и тогда, когда операционная система уже не отвечает. Экспортеры для Redfish существуют, но это сторонние проекты - перед внедрением стоит посмотреть, живой ли репозиторий.
Отдельно про RAID: универсального экспортера нет, состояние массива снимают вендорской утилитой (storcli, perccli и аналоги) и складывают результат в файл, откуда его подбирает textfile-коллектор Node Exporter. Способ кустарный, но рабочий, и он закрывает самый неприятный сценарий - когда массив живёт на последнем исправном диске, а никто об этом не знает.
Если мониторинг железа для вас основная задача, посмотрите также в сторону SNMP-мониторинга серверного оборудования: многие контроллеры и источники бесперебойного питания отдают данные именно так.
С ростом парка объём метрик растёт быстро, и Prometheus, задуманный для отдельных сервисов, упирается в потолок.
Prometheus хранит ряды в собственном формате, рассчитанном на интенсивную запись и хорошее сжатие. Данные складываются в блоки по два часа, потом уплотняются.
Срок хранения (retention) определяет, как долго данные лежат локально. Для большинства задач достаточно 15-30 дней подробных данных; всё, что старше, либо агрегируют, либо выносят наружу. Долгосрочное хранение обычно строят на внешних системах вроде Thanos, VictoriaMetrics или Mimir, которые складывают блоки в объектное хранилище.
Интервал опроса - самый прямой способ уменьшить объём. Собирать второстепенные метрики раз в минуту вместо раза в пятнадцать секунд - это вчетверо меньше данных без реальной потери информации.
Сокращать нагрузку помогает и отбрасывание ненужных метрик на этапе сбора: многие экспортеры отдают сотни рядов, из которых используется десяток.
Федерация - когда один Prometheus забирает часть метрик у других. Так строят иерархию: локальные серверы собирают всё подробно, центральный тянет с них только сводные показатели.
Шардинг - разделение целей между несколькими экземплярами Prometheus, каждый из которых отвечает за свою часть парка.
Для отправки данных во внешнее хранилище используется протокол remote write. В версии 2.0, появившейся в Prometheus 3.0, он передаёт метаданные и нативные гистограммы и заметно экономит трафик - при построении долгосрочного хранилища это стоит учесть.
Честный раздел, которого обычно нет.
Prometheus силён там, где инфраструктура динамическая: контейнеры, автоматическое масштабирование, десятки и сотни целей, которые появляются и исчезают. Он требует времени на освоение PromQL и отдельной работы по настройке правил.
Если у вас пять статичных серверов и задача звучит как «узнать, что диск заполнился или сервер не отвечает», Zabbix или простой опрос по SNMP развернутся быстрее и потребуют меньше сопровождения. Что именно и как часто отслеживать в такой инфраструктуре, разбирали в материале про комплексный мониторинг серверов.
Обратная ситуация тоже бывает: связка Prometheus и Grafana начинается как «поставим на пару серверов», а через год превращается в отдельную систему со своим хранилищем, дежурствами и человеком, который её обслуживает. Это нормально, если вы к этому готовы.
Prometheus собирает и хранит, Grafana показывает, Alertmanager будит. Разворачивается связка за вечер, а дальше начинается настоящая работа: подобрать метрики, которые действительно что-то значат, и пороги, на которые стоит реагировать.
Три вещи, с которых имеет смысл начать: prometheus.yml с node_exporter на всех серверах, прогноз заполнения дисков через predict_linear и оповещение с параметром for, чтобы не получать письмо от каждого всплеска. Дальше добавляйте метрики железа - именно они предупреждают об отказах заранее.
Что происходит с метриками в виртуальной среде и чем отличается мониторинг контейнеров - в разборе мониторинга виртуальных машин и контейнеров. Безопасность в этой картине стоит отдельно: SIEM и IDS-системы решают другую задачу.
Подбираете сервер под мониторинг или под нагруженную инфраструктуру?
Инженеры ITTELO помогут рассчитать конфигурацию под ваш парк: сколько метрик вы будете хранить, сколько под это нужно дисков и памяти. Подберём платформу под задачу, соберём и протестируем её перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
Сервер под инфраструктуру мониторинга · +7 (800) 551-80-12 · info@ittelo.ru
