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

Мониторинг — система и набор практик для сбора, хранения, визуализации и анализа телеметрии: метрик, логов, трассировок и синтетических проверок. Его задача — дать полную картину состояния системы, показать тренды, зависимостя и аномалии, помочь в расследовании инцидентов и планировании capacity. Мониторинг отвечает на вопросы «что происходит?» и «почему так происходит?» — это источник данных и контекста.

Алертинг — механизм, который превращает наблюдаемые сигналы из мониторинга в активные уведомления и действия. Алертинг отвечает на вопрос «когда нужно вмешаться сейчас?» — это правило-движок, который срабатывает по заданным условиям и доставляет уведомление соответствующим людям или автоматам (пагер, чат, инцидент-система).

Основные различия (коротко)

• Функция: мониторинг — наблюдение и анализ, алертинг — требование действий.

• Результат: мониторинг даёт данные и дашборды; алертинг создаёт уведомление/инцидент.

• Частота: мониторинг собирает всё непрерывно; алертинг срабатывает только при триггере.

• Ориентация: мониторинг ориентирован на видимость и диагностику; алертинг — на реакцию и устранение.

Компоненты и workflow

1. Сбор телеметрии (агенты, экспортёры, RUM, синтетика).

2. Агрегация и хранение (TSDB, лог-сторы, tracing backend) — это мониторинг.

3. Дашборды и аналитика — визуализация SLI/SLO, трендов.

4. Правила алертов (thresholds, anomaly detection, burn-rate) — определяют, когда создать уведомление.

5. Доставка и эскалация (PagerDuty, Opsgenie, Slack, SMS).

6. Процедуры (runbooks, on-call rota) — как действовать после алерта.

Важные практики для алертинга на базе мониторинга

• Алертить на симптомы, а не на первопричины (например — рост error-rate, а не конкретный стек-трейс).

• Минимизировать шум: дебаунс (debounce), агрегирование, дедупликация, suppression и rate-limiting.

• Классифицировать по уровню (warning → critical) и прописывать runbooks.

• Использовать burn-rate алерты для SLO: не ждать факта нарушения, а реагировать на скорость расхода error budget.

• Тестировать алерты (chaos, fire-drills) и измерять эффективность (MTTA, MTTR, alert to ack time).

Примеры

• Мониторинг: график p95 latency, лог ошибок, trace для запроса.

• Алертинг: правило «если p95 > 500ms в течение 5 минут — сгенерировать критический алерт в PagerDuty и открыть инцидент».

Подводные камни

• Слишком много алертов приводит к «alert fatigue».

• Слишком мало алертов — риск пропустить серьёзную деградацию.

• Плохая формулировка алерта без контекста тормозит реагирование — всегда включайте ссылку на дашборд и runbook.

Мониторинг и алертинг — части единого цикла наблюдаемости: первый даёт данные и контекст, второй — превращает сигналы в действие и обеспечивает своевременное восстановление сервиса.