С чего начинается мониторинг

С чего начинается мониторинг: стратегия, а не инструменты

Мониторинг начинается не с установки Prometheus или Grafana, а с определения целей и бизнес-контекста. Это фундаментальный принцип, который опытные инженеры усваивают на практике. Преждевременный выбор инструментов без чёткого понимания "что" и "зачем" мы наблюдаем, приводит к информационному шуму, усталости от алертов и, в конечном итоге, к потере доверия к системе мониторинга как таковой.

Процесс можно разбить на несколько ключевых этапов.

1. Определение бизнес-целей и SLO/SLA

Всё начинается с ответов на вопросы:

• Какие сервисы или функции являются критически важными для бизнеса и клиентов?
• Какие соглашения об уровне обслуживания (SLA) у нас есть с пользователями (внешними или внутренними)?
• Какие целевые показатели уровня обслуживания (SLO) мы для себя устанавливаем? Например, доступность 99.9% или скорость ответа API p95 < 200мс.
• Каковы целевые показатели ошибок (Error Budget) и как мы их тратим?

Без этих метрик мониторинг превращается в сбор данных ради данных. Пример: если бизнес зависит от онлайн-оплат, SLO может быть: "Корзина покупок должна успешно обрабатывать платежи в 99.95% случаев".

2. Выделение ключевых метрик на основе методологии "Четыре золотых сигнала"

Для каждого сервиса мы определяем четыре фундаментальных типа метрик, предложенных Google SRE:

• Задержка (Latency): Время, за которое обслуживается запрос. Особенно важна задержка для ошибок.
• Трафик (Traffic): Нагрузка на систему (запросы в секунду, активные сессии, объем данных).
• Ошибки (Errors): Частота ошибочных ответов (HTTP 5xx, исключения в коде, таймауты).
• Насыщенность (Saturation): Насколько "полна" система (использование CPU, памяти, дискового I/O, заполненность очередей).

Для веб-сервиса это может выглядеть так в виде прометеус-запросов:

# Задержка (p95 персентиль)
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{job="my-api"}[5m])) by (le, method, handler))

# Трафик (запросы в секунду)
sum(rate(http_requests_total{job="my-api"}[5m])) by (method, status_code)

# Ошибки (доля ошибок 5xx)
sum(rate(http_requests_total{job="my-api", status=~"5.."}[5m])) / sum(rate(http_requests_total{job="my-api"}[5m]))

# Насыщенность (использование памяти контейнером)
container_memory_working_set_bytes{container="my-app"} / container_spec_memory_limit_bytes{container="my-app"}

3. Инструментация приложений и инфраструктуры

Только после определения метрик мы переходим к инструментам.

• Белая коробка (White-box): Мониторинг изнутри системы. Это экспортеры метрик (Node Exporter, cAdvisor), логгирование структурированных логов (JSON) и инструментация кода (с помощью библиотек, например, для сбора гистограмм времени выполнения методов).
• Чёрная коробка (Black-box): Мониторинг с точки зрения внешнего пользователя. Это проверки доступности (uptime checks, synthetic monitoring) с географически распределённых точек.

4. Разработка дашбордов и алертинга

Дашборды — для людей (инженеров, менеджеров). Они должны отвечать на конкретные вопросы о состоянии системы и быть сосредоточены на SLO. Алерты — для автоматического оповещения. Ключевое правило: алерт должен требовать немедленного человеческого вмешательства. Алерты строятся на основе SLO и "золотых сигналов".

Плохой алерт: CPU usage > 80% (может быть нормальным кратковременным скачком). Лучший алерт: Error Budget burn rate is too high или p99 latency for checkout API > 2s for 5 minutes.

5. Непрерывное совершенствование (Feedback Loop)

Начало мониторинга — это лишь первый шаг. Процесс включает:

• Регулярные ревью алертов: Отсекать "шумные", добавлять недостающие.
• Анализ постмортемов (Postmortem): Каждый инцидент должен отвечать на вопрос "Какие метрики или алерты позволили бы выявить проблему быстрее?".
• Пересмотр SLO и метрик вместе с развитием продукта.

Итог: Настоящий мониторинг начинается с культуры, ориентированной на надежность (Reliability) и понимание того, как техническое состояние системы влияет на бизнес-результаты. Технический стек (Prometheus, Thanos, VictoriaMetrics, Grafana, ELK, OpenTelemetry) — это важный, но вторичный выбор, который следует за этой стратегией. Сначала спрашиваем "Почему?" и "Что?", а уже потом "Как?".