Современные бизнес-приложения работают в распределенных средах, где количество компонентов и зависимостей постоянно растет. Без централизованного сбора метрик команды разработки и эксплуатации теряют контроль над производительностью сервисов, временем отклика и частотой ошибок. Мониторинг позволяет отслеживать ключевые показатели системы в реальном времени, выявлять отклонения на ранних стадиях и сокращать время восстановления после сбоев.
Prometheus и Grafana — это стандартная связка для организации наблюдаемости в облачной инфраструктуре. Prometheus отвечает за сбор и хранение метрик в формате временных рядов, а Grafana предоставляет интерфейс для их визуализации и настройки алертов. В этой статье мы разберем архитектуру Prometheus, работу с четырьмя сигналами мониторинга, а также настройку инструментов и создание дашбордов для контроля состояния бизнес-приложений.
В этом тексте:
Зачем нужен мониторинг
Мониторинг занимает центральное место в практиках DevOps и SRE. Он переводит эксплуатацию информационных систем с реактивного подхода на проактивный.
При реактивном подходе команда узнает о проблеме от пользователей, которые столкнулись с ошибкой или недоступностью сервиса. Проактивный подход опирается на непрерывный сбор показателей, что позволяет обнаружить деградацию сервиса до того, как она затронет конечных потребителей. В результате сокращается время простоя, повышается стабильность релизов и формируется культура осведомленности о состоянии продукта.
Эффективный подход к мониторингу строится на отслеживании четырех ключевых метрик. Они покрывают основные аспекты работы любого сервиса, ориентированного на обработку запросов.
Задержка (Latency)
Задержка показывает время, необходимое системе для обработки запроса и возврата ответа. Для оценки задержки используют не среднее арифметическое значение, а перцентили — например, P95 или P99. Перцентиль P99 означает, что 99 процентов запросов обрабатываются быстрее указанного порога. Мониторинг перцентилей помогает выявить «длинный хвост» медленных ответов, которые могут оставаться незаметными при усреднении.
Трафик (Traffic)
Трафик измеряет уровень нагрузки на систему. Для веб-приложения это количество HTTP-запросов в секунду, для базы данных — число транзакций, для брокера сообщений — объем обрабатываемых событий. Отслеживание трафика необходимо для планирования мощностей и обнаружения аномальных всплесков, вызванных рекламными кампаниями или атаками.
Ошибки (Errors)
Показатель ошибок фиксирует долю неуспешных запросов от общего числа. К ошибкам относят явные сбои, такие как HTTP-статусы 500, и логические ошибки бизнес-логики — например, ответ с кодом 200, но с сообщением о невозможности создать заказ. Мониторинг этого сигнала позволяет оперативно замечать проблемы после развертывания новой версии приложения.
Насыщенность (Saturation)
Насыщенность описывает степень использования ресурсов системы. Сюда входят утилизация процессора, потребление оперативной памяти, заполнение дискового пространства и длина очередей задач. Рост насыщенности указывает на приближение к предельному уровню нагрузки, после которого производительность системы начнет нелинейно снижаться.
Метрики — это только одна из трех составляющих наблюдаемости. К другим относятся логи, которые фиксируют отдельные события, и распределенные трассировки, которые показывают путь запроса через разные сервисы. Prometheus работает именно с метриками: он собирает числовые показатели с компонентов системы и предоставляет язык запросов PromQL. С его помощью можно вычислять производные показатели на основе сигналов — например, процент ошибок или задержку на 99-м перцентиле.
Сбор метрик с Prometheus
Prometheus — это система мониторинга с открытым исходным кодом, созданная специально для сбора и обработки метрик в формате временных рядов. Проект входит в фонд Cloud Native Computing Foundation и стал стандартом для мониторинга облачных и контейнеризированных сред.
В основе Prometheus лежит pull-модель: сервер сам обращается к целевым системам и забирает метрики по протоколу HTTP. Такой подход отличается от push-модели, где агенты отправляют данные на сервер мониторинга. Pull-модель упрощает обнаружение неработающих компонентов — если Prometheus не может дотянуться до цели, это сразу сигнализирует о проблеме. Для сервисов, которые живут недостаточно долго для опроса, предусмотрен компонент Pushgateway, принимающий метрики по push-принципу.
Архитектура и ключевые компоненты
Сервер Prometheus состоит из нескольких подсистем, каждая из которых решает свою задачу.
База данных временных рядов. Prometheus хранит метрики локально на диске в собственной time-series database. Каждая метрика идентифицируется именем и набором пар «ключ-значение» — лейблов. Такой подход позволяет гибко фильтровать и агрегировать данные при запросах.
PromQL. Встроенный язык запросов PromQL дает возможность извлекать и обрабатывать метрики. С его помощью вычисляют темпы роста (rate), строят гистограммы (histogram_quantile), агрегируют данные по лейблам (sum by). Один грамотно составленный запрос заменяет несколько строк кода в самописных решениях.
Alertmanager. Когда значение метрики выходит за допустимый порог, Prometheus генерирует алерт и передает его Alertmanager. Этот компонент отвечает за группировку однотипных уведомлений, подавление вторичных срабатываний и маршрутизацию в нужные каналы — почту, мессенджеры, системы тикетов.
Exporters. Для сбора метрик с систем, которые не умеют отдавать их в формате Prometheus, используются экспортеры. Node Exporter предоставляет данные о процессоре, памяти, дисках и сети. Blackbox Exporter проверяет доступность HTTP-эндпоинтов и время ответа. Для баз данных, веб-серверов и другого программного обеспечения существуют отдельные экспортеры.
Формат метрик и лейблы
Prometheus использует простой текстовый формат для описания метрик. Каждая запись состоит из имени метрики, лейблов и числового значения. Лейблы добавляют контекст к измерению. Например, метрика http_requests_total с лейблами method="POST» и status="500» позволяет отфильтровать только неуспешные POST-запросы среди всего потока данных. Такая детализация критически важна при анализе инцидентов — команда быстро сужает область поиска до конкретного обработчика или эндпоинта.
Prometheus закрывает метрическую составляющую наблюдаемости. Он собирает числовые показатели с компонентов системы, хранит их и предоставляет язык PromQL для вычисления производных параметров. Четыре сигнала, рассмотренные нами выше, выражаются именно через PromQL-запросы: задержка через histogram_quantile, трафик через rate, ошибки через отношение неуспешных ответов к общему числу, насыщенность через утилизацию ресурсов из Node Exporter. Дальше мы рассмотрим, как Grafana превращает эти запросы в наглядные дашборды.
Хранилище S3
По умолчанию Prometheus хранит метрики на локальном диске ограниченное время, но для анализа трендов за месяцы и годы нужно внешнее хранилище. Объектное хранилище ИТ-ГРАД совместимо с S3 API и обеспечивает сохранность метрик даже при выходе из строя виртуальной машины с Prometheus.
Визуализация данных с Grafana
Grafana — это платформа для визуализации данных с открытым исходным кодом. Она не занимается сбором или хранением метрик, а подключается к готовым источникам данных и отображает их в виде графиков, таблиц, шкал и других элементов. После того как Prometheus собрал метрики и сохранил их в своей базе временных рядов, Grafana берет на себя задачу превратить эти числа в понятную картину состояния системы.
Возможности Grafana
Поддержка множества источников данных. Grafana работает не только с Prometheus, но и с десятками других систем: InfluxDB, Elasticsearch, PostgreSQL, MySQL, облачные сервисы мониторинга. Это позволяет собрать в одном дашборде метрики из разнородных источников. Например, данные о производительности приложения из Prometheus, логи ошибок из Elasticsearch и информацию о стоимости ресурсов из API облачного провайдера.
Гибкая система дашбордов. Дашборд в Grafana состоит из панелей, каждая из которых отвечает за отображение конкретного набора данных. Панели можно перемещать, менять их размер и настраивать внешний вид. Grafana предлагает несколько типов визуализации: временные ряды для отслеживания динамики, шкалы и индикаторы для отображения текущих значений, таблицы для детализированных выборок, тепловые карты для анализа распределения нагрузки.
Переменные и шаблоны. Переменные делают дашборды интерактивными и переиспользуемыми. Вместо создания отдельных дашбордов для каждого сервера или окружения можно определить переменную с выбором хоста, сервиса или среды. Пользователь переключает значение в выпадающем списке в верхней части экрана, и все панели автоматически обновляются, подставляя выбранное значение в PromQL-запросы. Такой подход снижает дублирование и упрощает навигацию.
Встроенная система алертов. Grafana включает собственный алерт-менеджер, который позволяет задавать пороговые значения прямо на панелях дашборда. При срабатывании условия Grafana отправляет уведомления в различные каналы: электронную почту, Slack, Telegram, PagerDuty и другие. Алерты можно настраивать визуально, наблюдая за графиком и выбирая подходящий уровень срабатывания, что снижает порог входа по сравнению с написанием правил в конфигурационных файлах.
Разграничение доступа и командная работа. Grafana поддерживает организационную структуру с командами, пользователями и ролями. Можно предоставить разработчикам доступ только к дашбордам их сервисов, а администраторам — полный обзор инфраструктуры. Готовые дашборды легко распространять через экспорт в JSON-формате или через общий репозиторий Grafana.com, где сообщество публикует тысячи шаблонов для типовых сценариев.
Prometheus и Grafana дополняют друг друга, закрывая два смежных этапа работы с метриками. Prometheus отвечает за сбор, хранение и обработку данных через PromQL. Grafana берет на себя представление: она отправляет PromQL-запросы к источнику данных Prometheus, получает результаты и отображает их в выбранном визуальном формате. При настройке дашборда источник Prometheus подключается за один шаг — достаточно указать URL сервера Prometheus в разделе Data Sources. После этого все панели дашборда могут ссылаться на этот источник и использовать любые PromQL-выражения для получения данных.
Настройка Prometheus и Grafana в облаке
После того как мы разобрали принципы работы Prometheus и Grafana, перейдем к практической настройке. В этой части мы развернем оба инструмента на виртуальной машине в облаке, настроим базовую конфигурацию и подключим Grafana к Prometheus в качестве источника данных.
Подготовка инфраструктуры
Для работы потребуется виртуальная машина с операционной системой Linux. Минимальные требования зависят от масштаба мониторинга, но для старта достаточно 2 виртуальных процессоров, 4 гигабайта оперативной памяти и 20 гигабайт дискового пространства. При росте числа метрик и увеличении срока хранения параметры масштабируются в соответствии с нагрузкой.
Перед установкой убедитесь, что на виртуальной машине открыты следующие порты:
- 9090 — веб-интерфейс Prometheus;
- 3000 — веб-интерфейс Grafana;
- 9100 — Node Exporter для сбора системных метрик.
Установка Prometheus
Установка выполняется через загрузку официального бинарного файла с сайта проекта или через менеджер пакетов. Рассмотрим вариант с использованием пакетного менеджера apt на Ubuntu.
Обновите список пакетов и установите Prometheus:
sudo apt update
sudo apt install prometheus -y
После установки сервис Prometheus запускается автоматически. Проверить его статус можно командой:
sudo systemctl status prometheus
Основной конфигурационный файл находится по пути /etc/prometheus/prometheus.yml. Он определяет, с какой периодичностью Prometheus опрашивает цели и на каких адресах они находятся. Базовая конфигурация включает один целевой объект — сам сервер Prometheus, доступный по адресу localhost:9090. Этот минимальный таргет позволяет сразу убедиться, что система работает, и начать сбор внутренних метрик Prometheus.
На этом этапе веб-интерфейс Prometheus доступен в браузере по адресу http://<адрес_вашей_ВМ>:9090. В разделе Status — Targets отображается список целей мониторинга и их состояние. Если индикатор зеленый, цель опрашивается успешно.
Установка Node Exporter
Node Exporter собирает метрики операционной системы: загрузку процессора, использование памяти, занятость дисков, сетевой трафик. Установите его через пакетный менеджер:
sudo apt install prometheus-node-exporter -y
После установки Node Exporter запускается на порту 9100 и сразу начинает отдавать метрики. Чтобы Prometheus начал их собирать, добавьте новый таргет в конфигурационный файл. Откройте /etc/prometheus/prometheus.yml и добавьте в секцию scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
После изменения конфигурации перезапустите Prometheus:
sudo systemctl restart prometheus
Теперь в списке целей появится новый объект node, и Prometheus начнет собирать системные метрики.
Установка Grafana
Grafana устанавливается из официального репозитория. Добавьте репозиторий Grafana, обновите список пакетов и установите:
sudo apt-get install -y software-properties-common wget
sudo wget -q -O /usr/share/keyrings/grafana.key https://apt.grafana.com/gpg.key
echo "deb [signed-by=/usr/share/keyrings/grafana.key] https://apt.grafana.com stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update
sudo apt install grafana -y
Запустите сервис и добавьте его в автозагрузку:
sudo systemctl start grafana-server
sudo systemctl enable grafana-server
Веб-интерфейс Grafana становится доступен по адресу http://<адрес_вашей_ВМ>:3000. Учетные данные для первого входа: логин admin, пароль admin. Система предложит сменить пароль при первом входе.
Подключение Prometheus к Grafana
После входа в Grafana необходимо добавить Prometheus в качестве источника данных. Перейдите в раздел Configuration — Data Sources — Add data source. В списке выберите Prometheus. В поле URL укажите http://localhost:9090 и нажмите Save & Test. Если подключение настроено верно, появится зеленое сообщение об успешной проверке.
Теперь Grafana готова принимать PromQL-запросы и отображать метрики Prometheus на дашбордах. На этом этапе связка двух инструментов настроена и работает. В следующих частях статьи мы добавим мониторинг реального приложения и создадим информативные дашборды.
IT-мониторинг и его уровни
Настройка Prometheus и Grafana — это практический шаг к построению системы мониторинга. Но перед внедрением важно понимать общую структуру наблюдаемости. В другой статье мы разбираем, как соотносятся мониторинг инфраструктуры, приложений и бизнес-метрик, и на каком уровне применяются инструменты вроде Prometheus.
Заключение
Мы рассмотрели четыре сигнала, которые формируют фундамент для оценки состояния любого приложения, разобрали архитектуру Prometheus и возможности Grafana по визуализации собранных показателей. Кроме этого, на практике настроили Prometheus, Node Exporter и Grafana на виртуальной машине, подключили источник данных и получили готовую платформу для мониторинга.
Но все эти шаги — лишь отправная точка для развертывания полноценной системы наблюдаемости под задачи вашего бизнеса. Если вам требуется масштабируемая виртуальная инфраструктура для размещения серверов мониторинга, продакшен-среды или контейнерных кластеров, обращайтесь к ИТ-ГРАД. Мы предоставляем виртуальные машины с гибкой конфигурацией ресурсов, управляемые базы данных, объектное хранилище для долгосрочного хранения метрик и другие сервисы, необходимые для построения отказоустойчивой архитектуры.
Частые вопросы
1. Как долго Prometheus может хранить метрики и что делать, если нужно увеличить глубину хранения?
По умолчанию Prometheus хранит данные на локальном диске в течение 15 дней. Этот параметр регулируется флагом —storage.tsdb.retention.time при запуске сервера. Для долгосрочного хранения метрик локального диска недостаточно. В таких случаях Prometheus интегрируют с системами удаленного хранения: Thanos, VictoriaMetrics, Cortex. Они позволяют выгружать метрики в объектное хранилище, совместимое с S3 API, и выполнять запросы по историческим данным без нагрузки на основной сервер Prometheus.
2. Чем отличается алерт в Prometheus от алерта в Grafana и что лучше использовать?
Prometheus обрабатывает правила алертинга на стороне сервера сбора метрик и передает срабатывания в Alertmanager, который отвечает за группировку, подавление дубликатов и маршрутизацию уведомлений. Grafana предоставляет собственный алерт-менеджер, который позволяет задавать условия на основе данных из любого подключенного источника. Правила в Grafana настраиваются визуально прямо на графике, что удобно для быстрого создания простых проверок. Prometheus с Alertmanager лучше подходит для сложных сценариев с разветвленной маршрутизацией, а Grafana — для оперативного добавления алертов без правки конфигурационных файлов Prometheus. На практике оба подхода часто используют одновременно.
3. Сколько ресурсов потребляет связка Prometheus и Grafana и как масштабировать ее при росте инфраструктуры?
Потребление ресурсов зависит от количества собираемых метрик, частоты опроса и глубины хранения. Для мониторинга 10–20 серверов с базовым набором экспортеров достаточно 2 виртуальных процессоров и 4 гигабайт оперативной памяти. При мониторинге сотен узлов или Kubernetes-кластера нагрузка возрастает. Масштабирование выполняют несколькими способами: увеличивают ресурсы виртуальной машины по вертикали, разворачивают несколько серверов Prometheus, где каждый отвечает за свой сегмент, либо внедряют Thanos или VictoriaMetrics для горизонтального масштабирования и распределенного хранения.
4. Нужно ли переписывать код приложения для сбора метрик Prometheus?
Для сбора системных метрик и метрик инфраструктуры изменение кода не требуется — достаточно установить соответствующие экспортеры, такие как Node Exporter для серверов или cAdvisor для контейнеров. Для сбора бизнес-метрик — количества заказов, регистраций, времени выполнения конкретных операций — в код приложения добавляют клиентскую библиотеку Prometheus для используемого языка программирования. Такие библиотеки существуют для всех популярных языков: Go, Java, Python, Node.js, .NET. Интеграция обычно сводится к добавлению нескольких строк кода для инициализации клиента и описания пользовательских метрик.
