Что важно понимать при сборе и анализе метрик в DevOps?

Эффективный мониторинг строится не просто на сборе данных, а на понимании того, что, зачем и как мы измеряем. Вот ключевые аспекты:

1. Цель метрик — отвечать на вопросы о системе. Метрики должны помогать в:

   • Отладке (Debugging): Почему упал сервис? Что вызвало высокую задержку?
   • Анализе производительности (Performance Analysis): Где узкое место? Как оптимизировать ресурсы?
   • Планировании емкости (Capacity Planning): Когда нужно добавить ресурсы?
   • Информировании о состоянии (Status Reporting): Здорова ли система сейчас? (SLA/SLO).

2. Классификация метрик по методологии "Четыре золотых сигнала" (Google SRE):

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

3. Технические нюансы сбора:

   • Кардинальность метрик: Высокая кардинальность (уникальные значения лейблов, например, user_id) "раздувает" базу метрик (как в Prometheus). Используйте лейблы для агрегации, а не для уникальных идентификаторов.
   • Частота сбора (Scraping Interval): Слишком частая выборка создает нагрузку, слишком редкая — теряет детализацию. Стандарт для Prometheus — 15-60 секунд.
   • Ретеншн и агрегация: Определите, как долго хранить детализированные данные, а когда агрегировать (например, усреднять за час/день) для долгосрочных трендов.

4. От метрик к действиям — алертинг:

   • Алерты должны быть actionable: Получив алерт, инженер должен понимать, что делать. Алерт "CPU usage > 90%" хуже, чем "CPU usage > 90% for 5 minutes on frontend pool, check queue length".
   • Используйте многоуровневые пороги: Предупреждение (warning) при 80% и критическое (critical) при 95%.

Пример практического подхода для веб-сервиса:

# SLO: 99% запросов должны выполняться быстрее 200мс
# Метрика задержки (гистограмма в Prometheus)
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# Алерт, если SLO нарушается более 5 минут
- alert: HighRequestLatency
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.2
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "99-й перцентиль задержки превышает 200мс"
    description: "Сервис {{ $labels.service }} нарушает SLO по задержке."

Главное — начинать с ключевых бизнес- и инфраструктурных метрик, которые напрямую влияют на пользовательский опыт и стабильность, и постепенно расширять наблюдаемость.