Symptom vs Cause Alerting

«CPU базы выше 80% — будим дежурного» — типичный алерт на причину. При отказе базы он выдаёт полсотни вызовов на один инцидент и парализует дежурство, а при медленном запросе на слабо связанном сервисе будит человека, пока продукт спокойно работает. Алерт на симптом ловит то, что реально чувствует пользователь: задержку, ошибки, доступность. И звонит один раз за инцидент, ровно когда надо. Rob Ewaschuk в 2014 году написал внутренний документ Google «My Philosophy on Alerting», который стал каноном; главы 4 и 6 SRE Book закрепили это в индустрии. Этот лист — про дисциплину различения и про то, как перебрать набор алертов после перехода на подход от SLO.

Граница: SLI-based Alerting — как алерт устроен (SLI как сигнал, скорость сжигания как порог); здесь — на что именно алертить. Alert Fatigue Management — что делать, когда система уже зашумлена; здесь — как не зашумлять её с самого начала.

Что должен уметь

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

Отличает алерт на симптом от алерта на причину на конкретном правиле; объясняет, почему «доля ошибок выше процента» — симптом, а «пул соединений занят на 80%» — причина.
Понимает эффект размножения: при отказе зависимости правила на причины по всем соседям дают многократный шум на один и тот же инцидент.

Проектирует золотые сигналы своего сервиса: задержка по перцентилям, ошибки (поток и доля), трафик, насыщение относительно мощности. Все четыре — со стороны симптомов; причины живут отдельным набором.
Использует метрики причин как вспомогательные в runbook, а не как основание для вызова. Причины — на дашборде, симптомы — в пейджере.

Применяет многооконный алертинг по скорости сжигания для симптомных SLI: быстрое сжигание (окно в час с проверкой за пять минут) и медленное (шесть часов с проверкой за полчаса) — одно правило, два окна.
Раз в квартал пересматривает набор: какие правила на причины выкинуть как шум, какие понизить до дашборда, какие оставить вспомогательными; какие симптомные добавить, если инцидент прошёл без алерта.

L6+

Внедряет дисциплину «алерт как код»: у каждого правила есть владелец, ссылка на runbook, обоснование порога, severity, ожидаемая частота срабатываний и срок пересмотра.
Связывает политику алертинга с программой SLO: дежурного будит только сжигание бюджета, внутренние индикаторы насыщения уходят тикетом, а причины и диагностические сигналы живут только на дашбордах.

Материалы

Книги

Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 6 «Monitoring Distributed Systems». Рекомендую: канонический разбор — четыре золотых сигнала, симптомы против причин, white-box против black-box. Если выбирать одну главу, то эту.
Betsy Beyer et al. (eds) — Site Reliability Engineering (O’Reilly, 2016), глава 10 «Practical Alerting from Time-Series Data». Как связка «временной ряд — правило — пейджер» устроена изнутри на примере Borgmon. Рекомендую следом за шестой главой, но не вместо неё.
Mike Julian — Practical Monitoring (O’Reilly, 2017). Глава про осмысленные алерты: разделение на то, что будит, то, что уходит тикетом, и то, что просто пишется в лог. Не читал — книга в списке ради этого разделения, а не как проверенная рекомендация.
Cindy Sridharan — Distributed Systems Observability (O’Reilly, 2018). Не читал; строка здесь ради контекста — почему наблюдаемость и мониторинг разные вещи и почему поиск причин уходит в трассировки и логи, а алертинг остаётся на симптомах.

Статьи и доклады

Rob Ewaschuk — My Philosophy on Alerting (Google, 2014). Первоисточник принципа «будим на симптомы, а не на причины». Рекомендую начинать с него: документ короткий и остаётся лучшим из того, что я по теме читал. Главный публичный кейс — см. ниже.
Betsy Beyer, Niall Murphy, Liz Fong-Jones, David Rensin — The Site Reliability Workbook (O’Reilly, 2018), глава 5 «Alerting on SLOs». Многооконные алерты по скорости сжигания — практика, выросшая из документа Ewaschuk: 2, 5 и 10 процентов бюджета на разных окнах.
Charity Majors — блог Honeycomb и её личный блог. Контекст высокой кардинальности и наблюдаемости как противопоставления классическому мониторингу. Рекомендую как фон, а не как канон по алертингу: про выбор порогов и симптомов там почти ничего.

Инструменты

Prometheus + Alertmanager — стандарт де-факто, и рекомендую его же. Многооконная схема собирается из for и правил агрегации. Sloth, Pyrra и OpenSLO генерируют такие правила из описания SLO.
Grafana / Datadog / New Relic — алертинг внутри готовых платформ наблюдаемости; подход тот же, синтаксис разный. Рекомендую любую из трёх, если платформа в компании уже стоит: заводить её отдельно ради алертинга смысла нет.
Sloth / Pyrra / OpenSLO — SLO как код: правила алертинга генерируются из описания автоматически. По моим наблюдениям, чаще берут Sloth — проверенный и хорошо ложится на Prometheus.
Анти-инструмент: правило алерта на каждую метрику дашборда. Антипаттерн, который доводит до усталости за месяц. Правило «алерт — это пейджер, всё остальное — дашборд» остаётся самым сильным фильтром.

Best practices

Главный публичный кейс — Rob Ewaschuk, «My Philosophy on Alerting» (Google, 2014). Документ короткий, десяток страниц, и каждая рекомендация в нём пережила десятилетие: будить на симптомы, а не на причины; по каждому вызову должно быть что делать; не знаешь, что делать, — это не повод для пейджера; качество алертов важнее их количества. Я регулярно вижу команды, которые читали SRE Book, но не читали сам документ, — и теряют главный нюанс: Ewaschuk пишет про работу человека ночью, а не про «правильный мониторинг». Это смещает рамку: проектирование алертов — задача про удобство дежурного в три часа ночи. Час чтения и пять лет дисциплины.

Правил, из которых всё вырастает, ровно три. Пейджер звонит только на симптомы: данные о причинах живут в дашборде и runbook, а будит человека только то, что означает «пользователю плохо прямо сейчас или станет плохо через десять минут». По каждому алерту есть что делать — если дежурный не знает, что с сигналом делать, это не алерт, а строчка в логе; инструкция на тридцать шагов в духе «может быть X, а может быть Y» означает, что условие срабатывания слишком широкое. И один инцидент — один вызов. Алерты на причины по всем зависимостям дают кратный шум на один и тот же отказ, симптомная сторона даёт один звонок. Лакмус простой: больше трёх вызовов на инцидент — набор сломан.

Алерты на причины не отменяются, они переезжают. Распространённый страх звучит так: уберём алерт на процессор — и кто-то пропустит его исчерпание. Метрики причин никуда не деваются, просто живут в дашборде и runbook, а не в пейджере. Поднялся симптомный алерт по задержке или ошибкам — дежурный открывает дашборд и сразу видит причинную сторону как контекст. Разделение проходит по роли сигнала: первичный говорит, что чувствует пользователь, диагностический — где копать.

Многооконная схема — шаг от аксиомы про симптомы к работающей формуле. Чистое «доля ошибок выше процента» реагирует только на очевидную аварию. Чистое «сгорело 2% бюджета» реагирует, когда всё уже случилось. Два окна решают обе беды сразу: быстрое (час на скорости 14.4×) ловит резкий инцидент, медленное (шесть часов на скорости 6×) — медленную деградацию. Формулы и параметры — в SRE Workbook, глава 5. По моим наблюдениям, чистый набор алертов от зашумлённого почти всегда отличает наличие этой схемы, остальное вторично.

Ежеквартальный пересмотр алертов — обязательная гигиена. Набор, который просто копится без ревизии, через год превращается в сотни правил: часть не срабатывала ни разу, часть срабатывала шумом, и только часть по делу. Раз в квартал каждое правило проходит три вопроса. Срабатывало ли за период? Было ли по нему что делать? Понизить, повысить или выкинуть? Без такой ревизии даже хорошо спроектированный набор сползает обратно к усталости от алертов.

Black-box не заменяет white-box. Мониторинг симптомов часто сводят к внешним проверкам: синтетика, доступность снаружи. Полезно, но в одиночку не годится. Снаружи видно «сервис недоступен» и не видно «сервис отвечает, но каждый пятый запрос с ошибкой». Метрики изнутри сервиса и проверки снаружи дополняют друг друга. Я регулярно вижу команды, у которых есть только одно из двух: с внешними проверками пропускают частичные деградации, с внутренними — проблемы сети, DNS и TLS между пользователем и сервисом.

Связанные листья

SLI-based Alerting — там про то, как устроен алерт (SLI, порог, скорость сжигания), здесь — на что алертить. Читать вместе.
Alert Fatigue Management — что делать, когда набор уже шумит; здесь — как не разводить шум изначально.
SLO Engineering — симптомные алерты привязаны к SLO; скорость сжигания бюджета — каноническая формула порога.
Runbooks — каждый алерт ссылается на runbook, где метрики причин — шаг диагностики, а не условие срабатывания.
Incident Response — алерт, по которому есть что делать, — первый шаг реакции; алерт без действия ломает её с самого начала.
Resilience Patterns — метрики circuit breaker, повторов и сброса нагрузки — вспомогательные индикаторы, они показывают, что механизмы сработали, и сами по себе никого не будят.

Открытые вопросы

Три темы ждут своих листьев. SLO для самого алертинга (TBD) — как измерять его качество: точность, полнота, время от начала инцидента до вызова дежурного. Синтетический мониторинг (TBD) — внешние проверки, телеметрия из браузеров, сквозные сценарии; соседняя ветка наблюдаемости. И поиск аномалий вместо пороговых правил (TBD) — Holt-Winters, Prophet, модели: где это работает, а где нет.

Чего я не знаю сам — как аккуратно ловить частичную деградацию на уровне feature flags, когда плохо только одной когорте пользователей. Если у вас такой опыт есть, расскажите через PR.