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.
Заключение: порядок развертывания
Стек 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 под долгое хранение. Рассчитаем сервер под задачу под объем ваших метрик. Оставьте заявку.
