Четыре золотых сигнала в мониторинге: latency, traffic, errors, saturation

Четыре золотых сигнала — это методика из книги Google SRE, которая отвечает на вопрос «что вообще мониторить, если сервис большой и метрик можно собрать тысячи». Предлагается отслеживать всего четыре ключевые величины: latency, traffic, errors и saturation.

Идея в том, что почти любая проблема пользовательского сервиса проявляется через один из этих четырех сигналов. Если они в норме, скорее всего, в норме и сервис.

Зачем нужны золотые сигналы

Когда метрик собирается слишком много, команда тратит время не на инциденты, а на анализ дашбордов. Золотые сигналы дают понятный минимум:

их легко объяснить новым людям в команде;
они одинаково применимы к API, веб-приложению, очереди или базе;
по ним удобно строить алерты и отчеты;
они заставляют смотреть на сервис глазами пользователя, а не сисадмина.

Это не означает, что других метрик не должно быть. Но именно эти четыре — ядро.

Latency. Время ответа

Latency — это время, которое сервис тратит на обработку запроса. Главный сигнал «приложение тормозит».

Что важно учитывать:

Latency успешных и неуспешных запросов нужно разделять. Быстрая 5xx-ошибка не должна улучшать общую картину.
Среднее (avg) почти всегда обманчиво. Лучше смотреть перцентили: p50, p95, p99.
Хвостовая часть распределения (p99, p99.9) показывает поведение для самых нетерпеливых сценариев и тяжелых запросов.

Хороший практический набор алертов:

p95 выше порога в течение нескольких минут;
резкий рост p99 при сравнимом трафике;
расхождение latency между регионами или зонами.

Traffic. Трафик

Traffic — мера спроса на сервис. То, что измеряет «насколько активно его используют».

Это может быть:

запросов в секунду для API;
открытий страниц для сайта;
сообщений в секунду для очереди;
транзакций в минуту для базы данных.

Зачем мониторить трафик:

внезапное падение трафика часто означает, что что-то сломалось выше по стеку (DNS, CDN, балансировщик);
внезапный всплеск может быть атакой, маркетинговой кампанией или ошибкой ретраев у клиента;
без знания трафика остальные сигналы интерпретировать сложнее. Высокий CPU при низкой нагрузке — это повод для тревоги; высокий CPU на пике — норма.

Алерты по трафику обычно строят не как абсолютный порог, а как отклонение от ожидаемого профиля.

Errors. Ошибки

Errors — доля или количество запросов, которые завершились неуспешно.

Что считать ошибкой, нужно решать осознанно:

HTTP 5xx — почти всегда ошибка сервера;
HTTP 4xx — обычно ошибка клиента, но 429, 499, 404 для своих ресурсов могут указывать на проблемы;
успешные по коду, но неправильные по смыслу ответы (например, 200 OK с пустым телом, когда ожидался JSON) тоже стоит ловить.

Часто полезно отделять:

ошибки, влияющие на пользователя;
ошибки, которые приложение само ретраит и закрывает;
ошибки на здоровье инфраструктуры (например, тайм-ауты к базе).

Алерт стоит строить на доле ошибок, а не только на абсолютных цифрах. Если у вас выросла нагрузка в 10 раз, абсолютное число ошибок тоже вырастет, и это нормально.

Saturation. Насыщение

Saturation — самый недооцененный из четырех. Он показывает, насколько сервис близок к своему пределу.

Это не «сколько CPU занято прямо сейчас», а «как близко мы подошли к точке, после которой начнутся проблемы». Например:

CPU не 50%, но очередь runqueue растет;
свободной памяти много, но swap начинает использоваться;
диск не заполнен, но iowait высок и растет;
пул соединений к базе занят на 80%;
лаг в очереди задач растет, хотя сами воркеры работают.

Saturation отвечает на главный вопрос на пике нагрузки: «у нас еще есть запас?». Когда запас заканчивается, сервис переходит из «работает медленнее» в «не работает».

Полезные индикаторы по слоям:

CPU: load average относительно числа ядер;
память: давление, swap, OOM-события;
диск: длина очереди, iowait;
сеть: drop-ы пакетов, заполненные очереди интерфейса;
приложение: занятые потоки, размер пула, длина очереди задач.

Как связать золотые сигналы с пользовательским влиянием

Каждый из четырех сигналов хорошо отображается на пользовательский опыт:

latency растет → пользователю «медленно»;
ошибки растут → пользователь видит сбой;
трафик резко упал → возможно, пользователи не доходят до сервиса;
saturation на пределе → скоро начнется деградация.

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

Как строить алерты по золотым сигналам

Базовая схема для типового веб-сервиса:

Сигнал	Что мониторить	Когда алертить
Latency	`p95`, `p99` успешных запросов	устойчивое превышение порога
Traffic	RPS / просмотры	резкое падение или нетипичный всплеск
Errors	доля `5xx` и доля бизнес-ошибок	устойчивое превышение SLO
Saturation	загрузка пулов, очереди, давление по ресурсам	приближение к лимиту с трендом роста

Главное правило: алерт должен срабатывать на симптом, который видит пользователь, а не на каждое отклонение метрики.

Чем золотые сигналы отличаются от USE и RED

Подходов несколько, и они дополняют друг друга:

Four Golden Signals — взгляд со стороны сервиса. Подходит для пользовательских сервисов и API.
RED (Rate, Errors, Duration) — фактически упрощенная версия золотых сигналов для request-driven сервисов: трафик, ошибки и длительность.
USE (Utilization, Saturation, Errors) — взгляд со стороны ресурсов (CPU, память, диск, сеть). Хорошо ложится на инфраструктурный мониторинг.

Удобная стратегия: на уровне сервисов смотреть golden signals или RED, на уровне инфраструктуры — USE. Тогда у вас есть и пользовательская, и техническая картина.

Типичные ошибки

мониторить только инфраструктуру и забывать про latency и ошибки;
смотреть среднее latency вместо перцентилей;
алертить на абсолютное число ошибок без учета трафика;
считать saturation только как «CPU занят»;
собрать дашборд из 50 графиков и не выделить ключевые сигналы.

Если на дашборде нет четырех явных блоков под latency, traffic, errors и saturation, это уже повод его пересобрать.

Как применить это на практике

Полезный мысленный эксперимент: возьмите любой свой сервис и попробуйте ответить на четыре вопроса.

Сколько он обрабатывает запросов в секунду?
Какое у него p95 и p99?
Какая доля запросов сейчас завершается ошибкой?
Насколько он близок к насыщению по самому узкому ресурсу?

Если на какой-то вопрос ответа нет, это и есть пробел в мониторинге, который стоит закрыть в первую очередь.

В Statuser базовый набор сигналов проще всего начинать с внешних проверок: latency и доступность, ошибки и регионы. По мере роста сервиса к ним удобно добавлять метрики приложения и инфраструктуры.

Что почитать дальше

Вывод

Четыре золотых сигнала — это компактный фреймворк, с которого имеет смысл начинать мониторинг любого нового сервиса. Latency, traffic, errors и saturation отвечают почти на все вопросы о здоровье сервиса и одновременно остаются понятными бизнесу.

Не пытайтесь сразу накрыть все десятками дашбордов. Сначала закройте четыре сигнала по каждому критичному компоненту — а уже потом добавляйте детали, когда они действительно нужны.