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

> Постоянный сбор метрик, логов и трасс о работе систем и автоматическое оповещение людей, когда что-то идёт не так; основа надёжной эксплуатации.

Источник: https://llmdocs.ru/wiki/monitoring-alerting/ · обновлено 2026-11-09 · лицензия CC BY-SA 4.0

- **Три столпа наблюдаемости**: метрики, логи, трассы
- **Методики**: четыре золотых сигнала (Google SRE), USE (Б. Грегг), RED (Т. Уилки)
- **Классические системы**: Nagios (1999), Zabbix (2001)
- **Современный стек**: Prometheus + Alertmanager + Grafana, OpenTelemetry
- **Каналы оповещений**: мессенджеры, почта, PagerDuty, Opsgenie, телефон
- **Связанные понятия**: SLI, SLO, дежурство (on-call), постмортем
**Мониторинг** — непрерывный сбор и анализ данных о работе систем: загрузки серверов, задержек и ошибок сервисов, бизнес-показателей. **Алертинг** — автоматическое оповещение людей, когда эти данные говорят о проблеме, требующей вмешательства. Вместе они отвечают на два вопроса: «работает ли система сейчас?» и «почему она перестала работать?».[1] Без мониторинга о сбое узнают от пользователей, без хорошего алертинга — либо слишком поздно, либо так часто, что перестают реагировать.

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

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

| Вид | Что это | Пример инструментов |
|---|---|---|
| Метрики | числовые ряды во времени: запросы в секунду, процент ошибок, память | [Prometheus](https://llmdocs.ru/wiki/prometheus.md), VictoriaMetrics, Zabbix |
| Логи | текстовые или структурированные записи о событиях | Loki, Elasticsearch/OpenSearch, ClickHouse, [journald](https://llmdocs.ru/wiki/journald-logs.md) |
| Трассы | путь одного запроса через все сервисы с длительностью каждого шага | Jaeger, Tempo, Zipkin |

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

Различают также **мониторинг «белого ящика»** — по внутренним метрикам приложения — и **«чёрного ящика»** — внешние проверки, как это видит пользователь: доступен ли сайт, валиден ли [TLS](https://llmdocs.ru/wiki/tls.md)-сертификат, отвечает ли 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](https://llmdocs.ru/wiki/sre-slo-sla.md).

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

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

```yaml
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](https://llmdocs.ru/wiki/kubernetes.md)-окружений, модель сбора метрик по HTTP (*pull*).
- **[Grafana](https://llmdocs.ru/wiki/grafana.md)** — дашборды поверх многих источников данных, а также собственный модуль алертинга.
- Облачные сервисы: Datadog, New Relic, Yandex Monitoring, а также встроенный мониторинг облачных провайдеров.
- Простые внешние проверки доступности: Uptime Kuma, Gatus, healthchecks.io (для cron-задач).

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

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

## См. также

- [Prometheus](https://llmdocs.ru/wiki/prometheus.md)
- [Grafana](https://llmdocs.ru/wiki/grafana.md)
- [SRE, SLO и SLA](https://llmdocs.ru/wiki/sre-slo-sla.md)
- [Логирование и трассировка (OpenTelemetry)](https://llmdocs.ru/wiki/opentelemetry.md)

## Источники

1. [Google SRE Book — Ch. 6 Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/)
2. [Brendan Gregg — The USE Method](https://www.brendangregg.com/usemethod.html)
3. [Grafana Labs — The RED Method: How to instrument your services](https://grafana.com/blog/2018/08/02/the-red-method-how-to-instrument-your-services/)
4. [Google SRE Workbook — Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/)
5. [Prometheus Docs — Alerting overview](https://prometheus.io/docs/alerting/latest/overview/)
6. [Rob Ewaschuk — My Philosophy on Alerting](https://docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview)
7. [OpenTelemetry Documentation](https://opentelemetry.io/docs/)