Коротко. Четыре золотых сигнала из практики SRE — это латентность (как быстро отвечает сервис), трафик (сколько запросов идёт), ошибки (доля неудачных ответов) и насыщение (насколько заполнены ресурсы). Если у вас мало времени на дашборды, начните именно с этих четырёх: вместе они ловят почти любой пользовательский сбой.
Откуда взялись золотые сигналы
Концепцию популяризировала команда Google SRE. Идея проста: вместо сотни метрик сосредоточьтесь на четырёх, которые напрямую отражают здоровье сервиса с точки зрения пользователя.
Если мониторить только четыре метрики пользовательского сервиса — мониторьте латентность, трафик, ошибки и насыщение.
1. Латентность (Latency)
Это время ответа. Важно разделять латентность успешных и неуспешных запросов: быстрая ошибка 500 может маскировать проблему. Смотрите на перцентили, а не на среднее.
- p50 — типичный пользователь.
- p95 / p99 — «хвост», который сильнее всего бьёт по опыту.
# PromQL: p99 латентности за 5 минут
histogram_quantile(0.99,
sum(rate(http_request_duration_seconds_bucket[5m])) by (le))2. Трафик (Traffic)
Сколько спроса на сервис — запросов в секунду, транзакций, сообщений в очереди. Трафик нужен как контекст: всплеск ошибок при росте трафика в 10 раз и при обычном трафике — разные истории.
# PromQL: запросов в секунду
sum(rate(http_requests_total[5m]))3. Ошибки (Errors)
Доля неудачных запросов. Учитывайте не только 5xx, но и «тихие» ошибки: ответ 200 с неверным телом тоже сбой.
# PromQL: доля ошибок 5xx
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))4. Насыщение (Saturation)
Насколько загружены ресурсы — CPU, память, диск, пул соединений. Насыщение предсказывает будущие проблемы: сервис ещё отвечает, но ресурс почти исчерпан.
# PromQL: загрузка CPU в процентах
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)Сводная таблица сигналов
| Сигнал | Что измеряет | Пример метрики |
|---|---|---|
| Латентность | Время ответа | p99 длительности запроса |
| Трафик | Объём спроса | Запросов в секунду |
| Ошибки | Доля неудач | % ответов 5xx |
| Насыщение | Загрузка ресурсов | % CPU, память |
Внешние и внутренние сигналы
Насыщение и часть латентности измеряются изнутри — на серверах. А вот латентность, трафик и ошибки с точки зрения пользователя точнее всего видны снаружи, через synthetic-мониторинг сайтов.
- Внутренние метрики (Prometheus) ловят насыщение и причины.
- Внешние проверки ловят реальный пользовательский опыт.
- Вместе они дают полную картину инцидента.
Что покрывает enterno.io
enterno.io как внешний (synthetic) мониторинг измеряет латентность ответа, ошибки (коды состояния HTTP/SSL) и доступность из точек по всему миру. Это дополняет внутренний Prometheus данными «со стороны пользователя». Проверки HTTP, SSL, Ping и DNS идут каждую минуту или раз в 30 секунд на платных планах, мультирегионально из России, Европы и США. Алерты приходят в Telegram, Slack, email, webhook, PagerDuty и Jira.
Поднимите мониторы для внешних сигналов, покажите доступность на статус-странице, а для контроля очередей и cron используйте heartbeat. Подробнее о реакции — в статье про план реагирования на инциденты.
Частые вопросы
Можно ли начать только с золотых сигналов?
Да. Это рекомендованная отправная точка: четыре сигнала покрывают большинство пользовательских сбоев, а детальные метрики добавляются позже по мере необходимости.
Почему среднее время ответа — плохая метрика?
Среднее скрывает «хвост»: если 1% пользователей ждёт 10 секунд, среднее может выглядеть нормально. Перцентили p95/p99 показывают реальную боль.
Чем golden signals отличаются от метода USE?
USE (Utilization, Saturation, Errors) фокусируется на ресурсах, а golden signals — на пользовательском сервисе. Их часто используют вместе: USE для инфраструктуры, golden signals для приложений.
Нужен ли Prometheus, чтобы применять golden signals?
Нет. Сигналы — это концепция, а не инструмент. Латентность, трафик и ошибки можно собирать и внешним synthetic-мониторингом без своего стека метрик.
Закройте внешние золотые сигналы. Создайте проверки на enterno.io/monitors и измеряйте латентность, ошибки и доступность глазами пользователя.