+7 (495) 801-60-42

Prometheus и Grafana: мониторинг веб‑приложений с нуля

В этой статье разберём, как запустить мониторинг prometheus grafana для веб‑приложения с нуля: что ставить, как собирать метрики, какие экспортеры выбрать, как строить дашборды и алерты, а также как подключить Docker и мониторинг сервера Linux.

Зачем веб‑приложению наблюдаемость и почему Prometheus+Grafana

Наблюдаемость — это не “красивые графики”, а способ отвечать на вопросы “что сломалось”, “почему” и “когда это началось”. Пара Prometheus и Grafana решает три ключевые задачи:

  • Сбор метрик времени отклика, ошибок и ресурсов (CPU, RAM, диск, сеть).
  • Визуализация трендов и корелляций по запросу.
  • Алерты по условиям SLO/SLI — когда деградация ещё обратима.

Плюсы стека:

  • Простая архитектура pull‑модели (Prometheus сам опрашивает таргеты).
  • Богатая экосистема экспортеров (node_exporter, blackbox_exporter, nginx, postgres и др.).
  • Гибкий язык запросов PromQL и готовые dashboards Grafana.
  • Лёгкая интеграция с Docker, Kubernetes и сторонними системами оповещений.

Архитектура: компоненты и потоки данных

Базовая схема выглядит так:

  1. Экспортеры и само приложение публикуют HTTP‑эндпоинты с метриками (обычно /metrics).
  2. Prometheus по расписанию тянет метрики (scrape), хранит во встроенной TSDB и выполняет правила алертов.
  3. Grafana читает данные из Prometheus и визуализирует их на дашбордах.
  4. Alertmanager отправляет уведомления в Slack/Telegram/Email по условиям из Alerting Rules.

Опциональные элементы:

  • Pushgateway — если есть batch‑джобы без постоянного эндпоинта.
  • Экспорт в долгосрочное хранилище (Thanos/Cortex/Mimir) для ретенции на годы.
  • Прокси/сервис‑дискавери (Consul, Kubernetes SD) для динамики таргетов.

Мониторинг Prometheus Grafana: быстрый старт за час

Ниже минимальный план, который в реальности запускается за 30–60 минут на тестовом сервере.

1) Установка Prometheus

  • Скачайте бинарники с официального релиза или используйте контейнер prom/prometheus.
  • Определите конфиг prometheus.yml: scrape_configs с таргетами приложений и экспортеров.
  • Запустите сервис и убедитесь, что /targets показывает состояние.

2) Установка Grafana

  • Пакет из репозитория дистрибутива или контейнер grafana/grafana.
  • Добавьте дата‑сорс Prometheus (URL экземпляра, например http://prometheus:9090).
  • Импортируйте готовые dashboards Grafana из каталога (например, Node Exporter Full).

3) Базовые экспортёры

  • node_exporter для хоста (CPU, RAM, диск, сеть, файлы подкачки, файловые системы).
  • blackbox_exporter для внешних проверок HTTP/HTTPS, TCP, ICMP.
  • Экспортер для вашего сервера приложений/БД (nginx, postgres, redis и т. д.).

Полезно: если у вас контейнерная среда, начинайте с dockerized‑подхода. Это ускоряет развёртывание и легко переносимо между средами. О том, когда использовать Kubernetes, читайте в статье “Kubernetes: что это и когда он нужен проекту”.

Экспортеры и метрики приложения: что собирать на практике

Метрики делим на три слоя:

  • Инфраструктура: CPU, нагрузка на диск/IOPS, сеть, файловые дескрипторы, температура, аптайм (node_exporter).
  • Платформа и периметр: ответ сервиса, коды HTTP, TLS, доступность (blackbox_exporter), метрики балансировщика/веб‑сервера.
  • Метрики приложения: доменные SLI — время обработки запроса (p50/p90/p99), частота ошибок 5xx/4xx, таймауты, очередь задач, кэш‑хиты, внешние зависимости.

Рекомендации по дизайну метрик:

  • Используйте типы counter (накопительные), gauge (моментальные), histogram/summary (распределения латентности).
  • Метрики именуйте в едином стиле: <subsystem>_<metric>_<unit>, лейблы — короткие и устойчивые.
  • Для латентности предпочитайте histogram + _bucket, чтобы строить SLA/SLO по порогам.
  • Описывайте единицы измерения явно (seconds, bytes, requests_total).

Для популярных языков есть клиентские библиотеки Prometheus (Go, Java, Python, Node.js, PHP и др.). Встраивайте эндпоинт /metrics непосредственно в сервис.

Dashboards Grafana: принципы, панели и PromQL

Правила продуктивного дашборда:

  • Одна роль — один экран. Отдельно для бэкенда, базы, фронта, сети; не смешивайте всё на одном полотне.
  • Первый экран — обзор SLI/SLO: доступность, p95 latency, error rate, throughput RPS.
  • Второй — ресурсы: CPU throttling, нагрузка GC, дисковые задержки, сетевые очереди.
  • Третий — зависимые сервисы: база данных, очереди, внешние API.

Примеры PromQL‑запросов:

  • Error rate: sum(rate(http_requests_errors_total[5m])) / sum(rate(http_requests_total[5m]))
  • p95 latency (histogram): histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
  • Saturation CPU: sum(rate(container_cpu_usage_seconds_total[5m])) by (instance)

Используйте шаблонные переменные ($instance, $job) и аннотации деплоев, чтобы понимать влияние релизов на метрики. Для типовых систем импортируйте готовые dashboards Grafana из каталога ID.

Алерты Grafana и правила Prometheus: как не превратить оповещения в шум

Где хранить логику:

  • Первичный источник — правила в Prometheus (Alerting Rules) + Alertmanager для маршрутизации и дедупликации.
  • В Grafana можно настраивать alerting на панели, но для инфраструктурных SLI удобнее централизованно держать их в Prometheus.

Подход к порогам:

  • Стартуйте с симптомов клиента: рост p95/p99 > X секунд N минут, error rate > Y%.
  • Добавляйте алерты ресурса, если есть подтверждение деградации (CPU 90%+ 10 мин, fill‑up диска < 24 ч, рост 5xx).
  • Введите правило “отложенного срабатывания” (for: 5m), чтобы отсечь флюктуации.
  • Группируйте по сервисам и окружениям (env, service), используйте маршруты Alertmanager для рабочих часов/дежурств.

Форматы уведомлений: Slack/Telegram/Email/Webhook. Текст должен содержать метку сервиса, окружение, условие триггера, ссылку на Grafana панель и совет по первичной проверке (runbook).

Мониторинг сервера Linux: базовый профиль node_exporter

Для старта достаточно node_exporter + набор дашбордов:

  • CPU: usage, steal, iowait, throttling (в контейнерах). Признак проблемы — высокий iowait и частые context switches.
  • Память: RSS/Cache/Swap. Запрещайте агрессивный swap на проде; следите за oom_kill.
  • Диск: latency, await, util%, queued I/O. Для SSD важны пики в latency при бэкапах.
  • FS: inode usage, fill‑up прогностика: time_to_full = free_bytes / rate(write_bytes[1h]).
  • Сеть: retransmits, drops, saturation на интерфейсах, SYN backlog.

Если нужна аномалия‑детекция, добавьте простые правила отклонения от медианы за 30 дней, но начинайте всегда с явных SLI.

Мониторинг Docker и сервис‑дискавери

В контейнерных средах Prometheus использует:

  • Docker SD: автоматическое открытие контейнеров как таргетов с лейблами image, container, service.
  • Экспортер cAdvisor для метрик контейнеров (CPU, память, диск, сеть) или метрики от Docker Engine.
  • В Kubernetes — стандартный kubernetes_sd_configs, ServiceMonitor/PodMonitor (в мире kube‑prometheus‑stack).

Рекомендации:

  • Не скрейпьте всё подряд: ограничьте по namespace/label.
  • Добавьте blackbox_exporter для проверок снаружи кластера (SYN‑путь до публичной точки).
  • Визуализируйте уровнем выше: сервис → pod → контейнер, чтобы понимать, где узкое место.

Безопасность, хранение и стоимость владения

  • Доступ: закрывайте Prometheus и Grafana за приватной сетью/VPN/SSO. Не публикуйте /metrics наружу без аутентификации.
  • Ретенция: по умолчанию Prometheus хранит данные на локальном диске. Планируйте объём: примерно десятки байт на серию в секунду; оценка — количество time series × частота × срок. Для долгосрочного хранения — Thanos/Mimir.
  • Резервирование: сделайте snapshot конфигов и dashboards, храните в Git. Prometheus сам по себе — отказоустойчивый при актив‑пассивной или федеративной схеме.
  • Стоимость: ПО — открытое, расходы — на инфраструктуру (CPU/SSD/трафик) и поддержку (подписки, дежурства). Оптимизируйте частоту scrape и кардинальность лейблов.

Для компаний без собственного DevOps‑штата внедрение проще делегировать. Команда LightsOn помогает с проектированием и эксплуатацией стека наблюдаемости в пакете “DevOps и инфраструктура”. Если вы параллельно запускаете новый продукт, посмотрите услугу “Разработка веб-приложений”.

Чек‑лист внедрения: от нуля к первым алертам

  • Определите SLI/SLO: доступность, latency p95, error rate, RPS.
  • Подготовьте список таргетов: приложение, БД, кэш, очереди, балансировщик.
  • Разверните Prometheus и Grafana (docker‑compose или пакеты ОС).
  • Подключите node_exporter и blackbox_exporter; добавьте экспортеры БД.
  • Экспортируйте метрики приложения (эндпоинт /metrics).
  • Настройте 3–5 ключевых дашбордов: обзор SLI, ресурсы, зависимости.
  • Создайте первые алерты: p95 latency, error rate, disk fill‑up, доступность.
  • Включите Alertmanager: маршруты, дежурства, шаблоны сообщений.
  • Заведите аннотации релизов и runbook’и для типовых инцидентов.
  • Закройте доступы: VPN/SSO, роли в Grafana, бэкапы конфигов.

Частые ошибки и как их избежать

  • Завышенная кардинальность лейблов (user_id, session_id) — раздувает TSDB. Нормализуйте, агрегируйте.
  • Слишком частый scrape (1s) везде — начинайте с 15–30s, дробите по классам SLI.
  • Дубликаты алертов из Prometheus и Grafana — централизуйте правила и оповещения.
  • Перегруженные дашборды — разбейте по ролям, вынесите ключевые SLI на первый экран.
  • Отсутствие проверки внешней доступности — добавляйте blackbox_exporter для L7 с точки пользователя.

Что дальше читать и внедрять

  • Для сервисного контура и SLA инфраструктуры — обратите внимание на материал “Обслуживание серверов для веб‑приложений: что это и зачем бизнесу” (https://lightson.agency/blog/stati/obsluzhivanie-serverov-dlya-veb-prilozhenij-chto-eto-i-zachem-biznesu).
  • Если вы планируете масштабирование, заранее подумайте о федерации Prometheus и хранилищах длительной ретенции (Thanos/Mimir), а также об унификации алертов и дежурств.

Вывод

Стек Prometheus + Grafana закрывает 80% потребностей веб‑приложений: сбор метрик, наглядные dashboards Grafana и устойчивые алерты Grafana/Alertmanager. Начните с SLI, настройте минимальный набор экспортеров, введите дисциплину алертов — и вы поймёте, где теряется производительность и почему. Нужна помощь с проектированием, миграцией или 24/7‑дежурствами — обсудим в разделе услуг “DevOps и инфраструктура”.

Другие полезные статьи

Делимся экспертизой, разбираем кейсы и рассказываем, как превращать идеи в работающие digital-продукты