Метрики и алертинг

Updated Jul 2026

Роль метрик в наблюдаемости

Метрики — это агрегированные числовые измерения во времени. В отличие от логов (одна запись на событие) или трассировок (одна на запрос), метрики предварительно агрегированы, что делает их дешёвыми для хранения, быстрыми для запросов и идеальными для дашбордов и алертинга. Они отвечают на вопрос: «Здорова ли эта система прямо сейчас?»

Сравнение трёх столпов

Метрики — первая линия обороны: они сообщают, что что-то не так. Трассировки говорят, где. Логи говорят, почему.

Типы метрик Prometheus

Prometheus — это де-факто стандарт сбора метрик в облачных средах:

Выбор между Histogram и Summary

• Histogram: Используйте, когда нужна серверная агрегация (несколько подов, дашборды). Prometheus может вычислить перцентили по нескольким экземплярам.
• Summary: Используйте для перцентилей на стороне клиента, когда кросс-экземплярная агрегация не нужна.

В большинстве случаев выбирайте Histogram. Он более гибкий и работает с recording rules и алертами Prometheus.

Инструментирование метрик приложения

# metrics_setup.py -- Application metrics with Prometheus client
from prometheus_client import Counter, Histogram, Gauge, start_http_server

# Request metrics
request_count = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'path', 'status']
)

request_duration = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration in seconds',
    ['method', 'path'],
    buckets=[0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0]
)

# Business metrics
orders_created = Counter(
    'orders_created_total',
    'Total orders created',
    ['payment_method', 'status']
)

active_sessions = Gauge(
    'active_sessions',
    'Number of active user sessions'
)

# Start metrics endpoint
start_http_server(8000)  # /metrics endpoint on port 8000

Методы USE и RED

Два фреймворка для выбора того, что измерять:

Метод USE (для инфраструктуры):

• Utilization (Утилизация): Насколько заполнен ресурс? (% CPU, % памяти, % диска)
• Saturation (Насыщение): Сколько дополнительной работы в очереди? (глубина очереди, использование пула потоков)
• Errors (Ошибки): Как часто работа завершается неудачей? (ошибки I/O, сбои соединений)

Метод RED (для сервисов):

• Rate (Частота): Сколько запросов в секунду?
• Errors (Ошибки): Сколько из этих запросов завершаются ошибкой?
• Duration (Длительность): Сколько времени занимают эти запросы?

Алерты с множественной скоростью сгорания

Самое важное достижение в алертинге за последнее десятилетие — алерты с множественной скоростью сгорания (multi-burn-rate). Вместо единого порога («доля ошибок > 1%») они обнаруживают как быстрое сгорание (внезапный сбой), так и медленное сгорание (постепенная деградация).

Как работает скорость сгорания

Если ваш SLO допускает 0,1% ошибок за 30 дней, устойчивая доля ошибок составляет 0,1%. Скорость сгорания 1x означает, что вы расходуете бюджет ошибок ровно с устойчивой скоростью.

Правила алертов Prometheus

# prometheus-alerting-rules.yaml
groups:
  - name: slo-alerts
    rules:
      # Fast burn: consuming error budget at 14.4x the sustainable rate
      # Will exhaust 30-day budget in 2 days if unchecked
      - alert: HighErrorRateFastBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5..", service="checkout"}[5m]))
            /
            sum(rate(http_requests_total{service="checkout"}[5m]))
          ) > (14.4 * 0.001)
          and
          (
            sum(rate(http_requests_total{status=~"5..", service="checkout"}[1h]))
            /
            sum(rate(http_requests_total{service="checkout"}[1h]))
          ) > (14.4 * 0.001)
        for: 2m
        labels:
          severity: critical
          team: checkout
        annotations:
          summary: "Checkout error rate burning budget fast (14.4x)"
          runbook: "https://wiki.internal/runbooks/checkout-high-error-rate"
          dashboard: "https://grafana.internal/d/checkout-slo"

      # Slow burn: consuming at 3x the sustainable rate
      # Will exhaust 30-day budget in 10 days if unchecked
      - alert: HighErrorRateSlowBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5..", service="checkout"}[30m]))
            /
            sum(rate(http_requests_total{service="checkout"}[30m]))
          ) > (3 * 0.001)
          and
          (
            sum(rate(http_requests_total{status=~"5..", service="checkout"}[6h]))
            /
            sum(rate(http_requests_total{service="checkout"}[6h]))
          ) > (3 * 0.001)
        for: 15m
        labels:
          severity: warning
          team: checkout
        annotations:
          summary: "Checkout error rate burning budget slowly (3x)"
          runbook: "https://wiki.internal/runbooks/checkout-elevated-errors"

Техника двойного окна (короткое окно И длинное окно) снижает ложные срабатывания. Кратковременный всплеск, который быстро разрешается, сработает в коротком окне, но не в длинном, предотвращая ненужные вызовы дежурного.

Принципы проектирования алертов

1. Алертируйте по симптомам, а не по причинам. Алертируйте по «пользователи видят ошибки», а не по «CPU высокий». Высокий CPU, не вызывающий воздействия на пользователей, не является событием, достойным алерта.

2. Используйте алерты с множественным окном и множественной скоростью сгорания. Ловите как внезапные сбои, так и постепенную деградацию.

3. Каждый алерт должен иметь runbook. Если нет задокументированной процедуры реагирования, алерт не готов для продакшена.

4. Вызывайте дежурного только для ситуаций, требующих немедленного действия человека. Всё остальное должно быть тикетом, дашбордом или еженедельным отчётом.

Матрица классификации алертов

Усталость от алертов: враг наблюдаемости

Усталость от алертов возникает, когда дежурные инженеры получают так много алертов, что начинают их игнорировать. Это единственный крупнейший риск для программы тестирования на основе наблюдаемости.

Диагностика усталости от алертов

Лечение усталости от алертов

1. Аудит каждого алерта. Для каждого алерта спросите: «Требовало ли это немедленного действия человека?» Если ответ постоянно «нет», понизьте с вызова до тикета.
2. Группировка коррелированных алертов. Если один инцидент порождает 15 алертов, создайте мета-алерт, который их группирует.
3. Установка окон обслуживания. Во время деплоев подавляйте известные транзитные алерты.
4. Ежемесячный пересмотр. Отслеживайте соотношение алертов к действиям. Целевой показатель: >70% вызовов приводят к осмысленным действиям.

Метрики и алертинг — это нервная система реального времени вашей продакшен-среды. Хорошо спроектированные алерты обнаруживают проблемы до того, как их заметят пользователи; плохо спроектированные алерты создают шум, скрывающий реальные проблемы.