Отметим: когда сервис падает, а мониторинг показывает всё зелёным — это проблема. Стандартный мониторинг CPU и памяти не отражает пользовательский опыт. Без golden signals вы не узнаете, что latency выросла до 10 секунд, пока не посмотрите логи. Четыре сигнала — Latency, Traffic, Errors, Saturation — дают ответ на вопрос «где копать?». Google описал их в SRE Book SRE Book, и этот фреймворк остаётся одним из самых практичных подходов к мониторингу. Он ориентирован на метрики пользователя, а не инфраструктуры.
Мы настраиваем golden signals под ключ: от инвентаризации текущих метрик до дашбордов и алертов с документацией. Свяжитесь с нами для предварительной оценки вашего проекта.
Latency: почему p99 важнее среднего
Latency — время выполнения запроса. Главная ошибка — мониторить среднее значение. Среднее скрывает проблему: если 1% запросов занимает 30 секунд, а остальные 99% — 10ms, среднее будет выглядеть нормально, но сотни пользователей каждую минуту видят завис. p99 latency в 10 раз информативнее среднего для диагностики проблем производительности.
Правильный подход: p50, p95, p99 через histogram. Отдельно — latency для успешных и ошибочных запросов. Медленная ошибка хуже быстрой — пользователь ждал и всё равно получил сбой.
# P99 latency для успешных запросов
histogram_quantile(0.99, sum by (le, service) (
rate(http_request_duration_seconds_bucket{service="$service", status_code!~"5.."}[5m])
))На дашборде — три линии: p50 (медиана), p95 (большинство пользователей), p99 (самые невезучие). Расхождение p99 от p50 — сигнал о нестабильном хвосте распределения.
Traffic: baseline и аномалии
Traffic — нагрузка на сервис. Для HTTP-сервисов — запросы в секунду. Для очередей — сообщения в секунду. Для баз данных — транзакции в секунду.
sum by (service) ( rate(http_requests_total{service="$service"}[1m]) ) Traffic — контекст для других сигналов. Высокий latency при низком трафике — внутренняя проблема (утечка памяти, дедлок). Высокий latency при аномально высоком трафике — перегрузка или DDoS.
Полезная панель: traffic с аннотациями деплоев. Резкое падение трафика — возможно, сервис перестал принимать запросы. Резкий рост — нештатная нагрузка.
Errors: классификация и алерты
Errors — доля запросов, завершившихся ошибкой. Важно разделять: HTTP 5xx (ошибки сервера), HTTP 4xx по кодам (400 = bad request, 404 = not found — разные вещи), таймауты (могут возвращать 200, но быть broken).
# Error rate 5xx
sum(rate(http_requests_total{service="$service", status_code=~"5.."}[5m])) / sum(rate(http_requests_total{service="$service"}[5m])) * 100Алерт по errors должен учитывать baseline. 0.1% ошибок для checkout — критично. 2% для поиска — может быть нормой, если поиск возвращает «not found».
Saturation: измерение для разных компонентов
Saturation — насколько сервис близок к ресурсному потолку. Это предиктивный сигнал: сервис ещё работает нормально, но ресурсов мало, и при следующем spike деградация неизбежна.
Для разных компонентов saturation измеряется по-разному:
# CPU saturation для пода
rate(container_cpu_usage_seconds_total{pod=~"$service.*"}[5m]) / on(pod) kube_pod_container_resource_limits{resource="cpu"}
# Saturation connection pool (для приложений с пулом соединений к БД)
db_pool_active_connections{service="$service"} / db_pool_max_connections{service="$service"}
# Queue saturation
rabbitmq_queue_messages{queue="$queue"} / rabbitmq_queue_consumer_capacity{queue="$queue"}Saturation > 80% — yellow alert. > 95% — red, масштабировать до деградации.
Пример расчёта saturation для CPU
Если лимит CPU контейнера — 1 ядро, а потребление 0.8 ядра — saturation 80%. При записи на диск это может вызвать latency.Дашборд четырёх сигналов
Один дашборд, четыре row, каждый для одного сигнала. В каждом row — несколько панелей с разными аспектами.
| Сигнал | Панели |
|---|---|
| Latency | P50/P95/P99 time series, Heatmap распределения задержек |
| Traffic | RPS по статус-кодам, RPS breakdown по endpoint |
| Errors | Error rate %, Error count by type, Top error messages |
| Saturation | CPU/Memory usage, Connection pool fill, Queue depth |
Переменная $service вверху — дашборд работает для любого сервиса из discovery.
Как внедрить golden signals за 3 шага
- Инвентаризация текущих метрик и инструментирования. Проверьте, есть ли histogram latency и метрики ошибок.
- Настройка recording rules для histogram, error rate, saturation.
- Разработка дашборда с четырьмя row и набором алертов с порогами yellow/red.
Получите консультацию по настройке мониторинга — мы поможем на каждом этапе.
Сравнение: среднее vs percentiles
| Метрика | Преимущество | Пример проблемы |
|---|---|---|
| Среднее | Простота вычисления | Скрывает 1% медленных запросов |
| p99 | Чувствительность к выбросам | Выявляет завис даже на 0.1% запросов |
Percentiles дают в 100 раз более точную картину для диагностики latency.
Что входит в работу
- Инвентаризация текущих метрик и инструментирования
- Настройка recording rules для histogram, error rate, saturation
- Разработка дашборда с четырьмя row и переменной
$service - Настройка алертов с порогами yellow/red
- Документация для команды: что каждый сигнал означает, как реагировать
- Передача прав и обучение (опционально)
Как строится работа
Начинаем с инвентаризации: что из четырёх сигналов уже измеряется. Latency через histogram — есть? Или только gauge со средним? Если gauge — исправляем инструментирование приложения, без histogram percentiles не посчитать.
Errors — логируются ли 5xx метриками? Traffic — есть ли Prometheus-метрики запросов, или только из nginx/loadbalancer logs.
После инвентаризации: разработка recording rules, дашборд, набор алертов по каждому сигналу с разумными порогами. Итог — документация с описанием сигналов и runbook'ом для алертов.
Опыт наших инженеров — 5+ лет в SRE, сертификация Prometheus и Kubernetes. Гарантируем соответствие SLA по MTTR.
Сроки и как заказать
Дашборд четырёх сигналов для одного сервиса — 1-2 дня. Стандартизированный шаблон для fleet микросервисов — 2-3 дня. Стоимость рассчитывается индивидуально.
Оценим ваш проект. Свяжитесь с нами — расскажем, как улучшить мониторинг.
