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

Мониторинг — непрерывный сбор и анализ данных о работе систем: загрузки серверов, задержек и ошибок сервисов, бизнес-показателей. Алертинг — автоматическое оповещение людей, когда эти данные говорят о проблеме, требующей вмешательства. Вместе они отвечают на два вопроса: «работает ли система сейчас?» и «почему она перестала работать?».^[1] Без мониторинга о сбое узнают от пользователей, без хорошего алертинга — либо слишком поздно, либо так часто, что перестают реагировать.

Метрики, логи, трассы

Современный подход называют наблюдаемостью (observability) и выделяют три вида телеметрии:

Метрики дешёвые и хорошо подходят для алертов и графиков; логи и трассы нужны, чтобы разобраться в причине. Единый открытый стандарт сбора всех трёх видов — OpenTelemetry (см. Логирование и трассировка (OpenTelemetry)).^[7]

Различают также мониторинг «белого ящика» — по внутренним метрикам приложения — и «чёрного ящика» — внешние проверки, как это видит пользователь: доступен ли сайт, валиден ли TLS-сертификат, отвечает ли API за разумное время.

Что измерять

Три популярные методики помогают не утонуть в тысячах метрик:

• Четыре золотых сигнала (Google SRE) для любого сервиса: задержка (latency), трафик (traffic), ошибки (errors), насыщение (saturation).^[1]
• USE (Брендан Грегг) для ресурсов — процессора, диска, сети: Utilization (загрузка), Saturation (очередь), Errors (ошибки).^[2]
• RED (Том Уилки) для запросных сервисов: Rate (частота), Errors (ошибки), Duration (длительность).^[3]

Задержку важно смотреть по перцентилям (p50, p95, p99), а не по среднему: среднее в 100 мс может скрывать, что каждый сотый пользователь ждёт 5 секунд.

Принципы хорошего алертинга

Алерт будит человека, поэтому каждый должен быть срочным, требующим действия и реальным.^[6]

• Алертить по симптомам, а не по причинам. «Доля ошибок API выше 2 % в течение 5 минут» — важно пользователю. «CPU 90 %» — может быть нормой; такие сигналы — для дашбордов и диагностики.
• Разделять срочность. Критичное — звонок дежурному в любое время; важное, но терпящее — задача или сообщение в рабочий чат.
• Каждый алерт — с инструкцией (runbook): что проверить и как исправить.
• Бороться с «усталостью от алертов». Если оповещение регулярно игнорируют, его нужно исправить или удалить: шум приучает пропускать и настоящие сбои.
• Группировать и подавлять. Падение одного узла не должно порождать сотню оповещений от всех сервисов на нём.

Зрелый подход — алертинг по SLO: команда фиксирует цель (например, 99,9 % успешных запросов за 30 дней) и получает оповещение, когда «бюджет ошибок» расходуется слишком быстро (burn rate), а не на каждый кратковременный всплеск.^[4] Подробнее — в статье SRE, SLO и SLA.

Пример правила

В экосистеме Prometheus правило алерта — это запрос PromQL с порогом и длительностью, а Alertmanager группирует сработавшие алерты, подавляет дубликаты и рассылает их по каналам.^[5]

groups:
  - name: api
    rules:
      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{job="api",code=~"5.."}[5m]))
            / sum(rate(http_requests_total{job="api"}[5m])) > 0.02
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "API: более 2% ответов с ошибкой 5xx"
          runbook: "https://wiki.example.com/runbooks/api-errors"

Условие for: 5m отсекает короткие всплески: алерт срабатывает, только если проблема держится пять минут подряд.

Инструменты

• Nagios (1999) и Zabbix (2001) — классические системы проверок «хост работает / не работает», с агентами и шаблонами; Zabbix широко распространён в российских компаниях.
• Prometheus с Alertmanager — стандарт для облачных и Kubernetes-окружений, модель сбора метрик по HTTP (pull).
• Grafana — дашборды поверх многих источников данных, а также собственный модуль алертинга.
• Облачные сервисы: Datadog, New Relic, Yandex Monitoring, а также встроенный мониторинг облачных провайдеров.
• Простые внешние проверки доступности: Uptime Kuma, Gatus, healthchecks.io (для cron-задач).

Дежурство и разбор инцидентов

Алерты бессмысленны без процесса: кто дежурит, как эскалировать, если дежурный не ответил, где фиксировать ход инцидента. После серьёзных сбоев пишут постмортем без поиска виноватых: что случилось, как обнаружили, почему мониторинг не предупредил раньше и что изменить.

См. также

• Prometheus
• Grafana
• SRE, SLO и SLA
• Логирование и трассировка (OpenTelemetry)

Источники

1. Google SRE Book — Ch. 6 Monitoring Distributed Systems
2. Brendan Gregg — The USE Method
3. Grafana Labs — The RED Method: How to instrument your services
4. Google SRE Workbook — Alerting on SLOs
5. Prometheus Docs — Alerting overview
6. Rob Ewaschuk — My Philosophy on Alerting
7. OpenTelemetry Documentation