Prometheus опрашивает эндпоинты с метриками как медсестра на обходе — методично, каждые несколько секунд снимает показания и складывает их в свою базу. Grafana затем превращает эти цифры в наглядные дашборды. Связка стала стандартом наблюдения за инфраструктурой в мире контейнеров и Kubernetes. Разберем архитектуру, установку обоих компонентов, сбор метрик через node_exporter, основы языка запросов PromQL, алертинг через Alertmanager и развертывание мониторинга в Kubernetes одним Helm-чартом.
Почему Prometheus и Grafana — стандарт
Prometheus сам обращается к целям по pull-модели: периодически забирает метрики с HTTP-эндпоинта /metrics каждой системы и пишет их в собственную time-series базу (TSDB). Такой подход упрощает обнаружение проблем — если цель не ответила на scrape, это само по себе сигнал, что она недоступна. От Zabbix систему отличает устройство: тот монолитен, а Prometheus собирает экосистему из частей — сам движок метрик, отдельная Grafana для визуализации, отдельный Alertmanager для оповещений. Модульность позволяет менять компоненты по отдельности, но требует собрать стек самому.
Создавался Prometheus под динамичную инфраструктуру, где узлы появляются и исчезают. Через service discovery он сам находит новые цели в Kubernetes, Consul или по DNS, без правки конфигурации руками — именно поэтому в контейнерных средах эта система стала выбором по умолчанию.
Архитектура
Стек складывается из нескольких независимых компонентов. Под сервер с базой метрик мы подбираем серверы с быстрым диском: TSDB активно пишет, и накопитель определяет, сколько метрик потянет узел. Сердце системы — Prometheus Server, который опрашивает цели, хранит метрики в TSDB и отдает их по языку запросов; локальная база рассчитана на оперативные данные за дни и недели, а не на годы. Сам Prometheus метрики не генерирует — их отдают exporter-ы, небольшие сервисы с эндпоинтом /metrics: главный из них node_exporter снимает показатели сервера, blackbox_exporter проверяет доступность извне, отдельные экспортеры есть для PostgreSQL, MySQL и сетевого оборудования.
Правила тревог живут в самом Prometheus, но обработку оповещений ведет отдельный Alertmanager — его группировку, маршрутизацию и подавление шума разберем отдельным разделом ниже. Grafana подключается к Prometheus как источник данных и строит дашборды (dashboard) из панелей (panel) с графиками. Для коротких задач, которые завершаются раньше, чем их успеет опросить сервер, есть Pushgateway — промежуточный буфер, куда задача сама сбрасывает метрики перед завершением.
Установка Prometheus
Развертывание начинают с самого движка метрик, и шаги одинаковы для большинства дистрибутивов. Prometheus распространяется одним статичным бинарником без зависимостей — его кладут в систему и запускают, а в контейнерной среде берут официальный Docker-образ; текущая стабильная линия это версия 3.0, вышедшая в ноябре 2024 года с обновленным интерфейсом и поддержкой OpenTelemetry. Для постоянной работы заводят systemd-юнит, чтобы служба стартовала автоматически, а поведение задает файл prometheus.yml: в нем описывают, какие цели опрашивать и как часто, при базовом интервале опроса scrape_interval в 15 секунд.
Срок хранения метрик задают параметром retention; по умолчанию это 15 дней, и здесь же указывают каталог под базу. Локальный диск ограничивает глубину истории, поэтому под долгое хранение метрики выгружают наружу. После запуска Prometheus поднимает собственный веб-интерфейс, и на странице Targets видно, какие цели опрашиваются и какие отвечают — красный статус сразу показывает недоступный узел. Это первая проверка, что сбор работает.
Установка Grafana
Метрики собраны — теперь их визуализируют, и Grafana ставят отдельно из официального репозитория через apt или dnf. Актуальная ветка — Grafana 12, свежая линейка — 13; интерфейс не требует ручной правки конфигов для старта. Первым делом в ней добавляют data source — источник данных типа Prometheus с адресом сервера, после чего панели смогут обращаться к метрикам, а один экземпляр Grafana подключают сразу к нескольким источникам, объединяя данные на общих дашбордах.
Рисовать панели с нуля не обязательно: на grafana.com лежат тысячи готовых дашбордов под node_exporter, базы и Kubernetes — дашборд импортируют по идентификатору и сразу получают набор графиков, который остается донастроить под себя. Доступ Grafana разделяет через организации и роли RBAC: одним дают только просмотр, другим редактирование, что держит у каждого дашборда владельца и не дает случайно сломать общую панель.
Сбор метрик с серверов: node_exporter
Основной источник данных о состоянии сервера — node_exporter, эталонный сборщик системных метрик для Linux. Это такой же одиночный бинарник, который запускают как systemd-службу на каждом наблюдаемом сервере: он поднимает эндпоинт /metrics, откуда Prometheus и забирает данные, а установка занимает пару минут на хост. Из коробки node_exporter отдает свыше сотни метрик — загрузку CPU, занятость RAM, заполнение и латентность дисков, трафик сети, число файловых дескрипторов, и этого набора хватает для полного системного мониторинга без дополнительной настройки.
Чтобы Prometheus начал опрашивать экспортер, в prometheus.yml добавляют блок scrape_configs с адресами целей: для статичных серверов их перечисляют вручную, для динамичных подключают service discovery. В последнем случае Prometheus находит цели сам — через файл, DNS, Consul или Kubernetes API. В облачной среде это обязательный механизм, потому что узлы создаются и удаляются постоянно, и поддерживать список руками невозможно.
Дополнительные exporters
Помимо системных метрик собирают данные приложений и сетей. Внешнюю доступность сервисов проверяет blackbox_exporter — отвечает ли HTTP-эндпоинт, открыт ли TCP-порт, проходит ли ICMP-пинг; это взгляд глазами пользователя, а не только проверка, жив ли процесс на хосте. Для баз данных есть postgres_exporter и mysqld_exporter, снимающие число соединений и длительность запросов, а сетевое оборудование опрашивают через snmp_exporter — под такой сбор по SNMP подбирают совместимое сетевое оборудование. Контейнеры мониторят через cAdvisor, а Java-приложения раскрывают внутренние показатели через jmx_exporter, и каждый экспортер закрывает свой класс целей, дотягивая стек до прикладного уровня поверх системного.
PromQL: язык запросов
Гибкость Prometheus раскрывается через PromQL — язык, на котором считают и агрегируют метрики для графиков и алертов. Он оперирует двумя типами данных: instant vector это значение метрики в текущий момент, range vector — значения за интервал времени, и на диапазонных векторах строят расчеты скорости и трендов. Для счетчиков, которые только растут, применяют rate() и increase(): они считают скорость и прирост за период — например, rate по счетчику ошибок дает число ошибок в секунду, величину, по которой уже строят алерт.
Метрики сворачивают по меткам через sum by () и avg by (), а функция histogram_quantile() считает перцентили задержек, показывая не среднее, а время ответа для 95 или 99% запросов. Тяжелые запросы, которые считают часто, выносят в recording rule: Prometheus пересчитывает их по расписанию и сохраняет результат как отдельную метрику, а дашборды и алерты затем читают готовое значение вместо сложного выражения.
Alertmanager: алерты
Оповещения в стеке устроены в два шага: правила в движке метрик и обработка в Alertmanager. Правила тревог alerting rule описывают на PromQL прямо в Prometheus — условие, длительность и метки важности; когда выражение держится истинным заданное время, Prometheus передает алерт в Alertmanager. Разделение труда четкое: движок решает «есть проблема», Alertmanager — «кому сказать». Последний шлет уведомления в нужные каналы (email, Telegram, Slack, Mattermost или универсальный webhook), под каждый из которых настраивают receiver.
Дерево маршрутизации routing tree раскладывает алерты по получателям и группирует связанные сообщения в одно — вместо сотни писем о каждом узле команда получает одно сводное по сервису. На время плановых работ алерты глушат через silence по меткам, а inhibition подавляет дочерние оповещения: если отказал весь дата-центр, нет смысла слать алерты по каждому сервису внутри него. Оба механизма экономят нервы дежурных.
Prometheus в Kubernetes
В контейнерной среде стек разворачивают не вручную, а целиком одним пакетом — спроектировать кластер и проверить его готовность помогает аудит ИТ-инфраструктуры. Helm-чарт kube-prometheus-stack от сообщества разворачивает за минуты полный мониторинг кластера: Prometheus, Alertmanager, Grafana и набор готовых дашбордов — это самый популярный способ поднять наблюдение в Kubernetes, не собирая компоненты по отдельности. Что опрашивать, здесь описывают не правкой конфига, а объектами ServiceMonitor и PodMonitor через CRD: добавили в кластер сервис с такой меткой — Prometheus сам начинает его опрашивать.
За всем этим стоит Prometheus Operator — он следит за CRD и сам перенастраивает Prometheus при изменениях в кластере. Вместе с чартом приходят стандартные дашборды для Kubernetes: состояние узлов, подов и рабочих нагрузок из коробки.
Масштабирование и долгое хранение
Локальная база Prometheus держит оперативную историю, но не годится для долгого архива и не реплицируется между узлами, поэтому, когда нужны метрики за месяцы или отказоустойчивость самого мониторинга, одного Prometheus мало. Через механизм remote write он дублирует метрики во внешнее хранилище — Thanos, Cortex или VictoriaMetrics, которые дают долгое хранение, единый запрос по нескольким серверам и горизонтальное масштабирование. VictoriaMetrics привлекает высокой скоростью и сжатием данных и служит drop-in заменой Prometheus, а Thanos и Cortex выбирают под федерацию множества кластеров. Переходят на них, когда метрик становятся миллионы или требуется хранить историю долго.
Российский контекст
В РФ стек привлекателен в том числе из-за лицензионной чистоты — это часть импортозамещения серверов и инфраструктуры наблюдения. Prometheus и Grafana распространяются под свободными лицензиями и доступны независимо от санкций: их ставят из исходников или локальных зеркал, не завися от зарубежных коммерческих контрактов, а бинарники и образы держат на внутренних зеркалах, чтобы развертывание не зависело от внешних репозиториев. Стек штатно работает на Astra Linux, ALT и РЕД ОС — node_exporter и сам Prometheus собираются под эти системы без доработок, что позволяет строить наблюдение на полностью отечественной программной базе.
Типовые ошибки
Три просчета сводят на нет преимущества стека, и все три касаются эксплуатации. Систему ставят с настройками по умолчанию и теряют метрики старше 15 дней, а при отказе узла и оперативные — под историю и отказоустойчивость сразу планируют remote write во внешнее хранилище. Правила заводят на каждое отклонение, и команда тонет в оповещениях, на которые нечего ответить, поэтому алерты оставляют только на то, что требует действия человека. И дашборды плодят без папок и владельцев, из-за чего через полгода никто не знает, какие из них актуальны — панели раскладывают по папкам и закрепляют за владельцами, а устаревшие удаляют.
Сравнение компонентов хранения
Сводка по вариантам долгого хранения метрик поверх Prometheus.
Сравнение компонентов хранения
Решение
Назначение
Сильная сторона
Когда брать
Локальная TSDB
Оперативные метрики
Просто, из коробки
Один узел, история на недели
VictoriaMetrics
Хранение и замена
Скорость, сжатие
Много метрик, нужна экономия
Thanos
Федерация кластеров
Глобальный запрос, архив
Несколько кластеров Prometheus
Cortex
Мультитенантность
Горизонтальное масштабирование
Сервис мониторинга на много команд
Заключение: порядок развертывания
Стек Prometheus и Grafana собирают по шагам, и порядок экономит время:
поднять Prometheus и убедиться, что цели на странице Targets отвечают;
поставить node_exporter на серверы и завести их через scrape_configs или service discovery;
подключить Grafana как визуализацию и импортировать готовые дашборды;
добавить прикладные экспортеры под базы и сети;
настроить Alertmanager с группировкой и каналами, оставив алерты только на действия;
для истории и отказоустойчивости подключить remote write во внешнее хранилище.
В Kubernetes весь этот путь сворачивается в один Helm-чарт kube-prometheus-stack, а собранный по такому порядку стек дает наблюдаемость без слепых зон.
Часто задаваемые вопросы
Чем Prometheus отличается от Zabbix?
Prometheus — модульный движок метрик с pull-моделью, к которому отдельно подключают Grafana и Alertmanager. Zabbix — монолитная система «все в одном» с агентами. Prometheus сильнее в cloud-native и Kubernetes, Zabbix — в классическом парке серверов.
Зачем Grafana отдельно от Prometheus?
У Prometheus есть простой встроенный интерфейс, но он рассчитан на отладку запросов, а не на дашборды. Grafana дает гибкую визуализацию, готовые панели и подключение нескольких источников данных сразу. В связке каждый компонент делает свое.
Какой exporter ставить на сервер?
Базовый выбор — node_exporter: он снимает системные метрики Linux из коробки. Поверх него добавляют прикладные экспортеры под конкретные сервисы: базы данных, веб-серверы, контейнеры. Для проверки доступности извне ставят blackbox_exporter.
Что такое PromQL?
Это язык запросов Prometheus для выборки и расчета метрик. На нем строят графики, считают скорость через rate(), агрегируют по меткам и задают условия алертов. Базовый синтаксис осваивается быстро, но язык дает и сложные расчеты.
Как настроить алерты в Telegram через Alertmanager?
Правила тревог пишут на PromQL в Prometheus, а в Alertmanager заводят receiver с webhook на Telegram-бота. Маршрут связывает алерты с этим получателем. Часто между ними ставят промежуточный мост-сервис для форматирования сообщений.
Сколько метрик тянет один Prometheus?
Один узел справляется с миллионами активных серий метрик при достаточном объеме RAM и быстром диске. Точный предел зависит от железа и частоты опроса. Когда метрик становится больше, подключают внешнее хранилище через remote write.
Чем kube-prometheus-stack лучше ручной установки?
Helm-чарт разворачивает Prometheus, Alertmanager, Grafana и готовые дашборды за минуты, уже связанными между собой. Ручная сборка тех же компонентов заняла бы часы и оставила бы место ошибкам в конфигурации.
Когда нужен Thanos или VictoriaMetrics?
Когда требуется хранить метрики месяцами, объединять данные нескольких кластеров или масштабировать мониторинг горизонтально. VictoriaMetrics берут ради скорости и экономии места, Thanos — ради федерации множества серверов Prometheus.
Развернем стек под вашу инфраструктуру
Внедряете Prometheus и Grafana для серверов или Kubernetes? Инженеры Serverzilla подберут сервер под движок метрик и базу, развернут exporter-ы, спроектируют Alertmanager и дашборды, при необходимости настроят Thanos или VictoriaMetrics под долгое хранение. Рассчитаем сервер под задачу под объем ваших метрик. Оставьте заявку.