Golden signals, структура дашборда и auto-RED в service mesh

У команды пять сервисов. Каждый RED-дашборд выглядит по-разному — разные имена метрик, разная раскладка панелей, разная структура label. Когда инцидент затрагивает несколько сервисов, on-call тратит 30 минут на чтение документации до начала триажа. Единый консистентный паттерн дашборда для всех сервисов сократил бы это до секунд.

Четыре golden signals

SRE-книга Google (по духу предшествует RED и USE, опубликована позже) называет четыре сигнала: Latency, Traffic, Errors, Saturation. Пересечение с RED прямое: Latency = Duration, Traffic = Rate, Errors = Errors. Новый элемент — Saturation: насколько сервис «заполнен» относительно известного предела мощности.

В отличие от Saturation в USE (про физические ресурсы), Saturation в golden signals — на уровне сервиса: количество in-flight запросов, длина очереди, число активных сессий, занятость connection pool. Сервис может быть на 50% CPU, но иметь connection pool на 100% — сервис заполнен, пользователи стоят в очереди, а USE на хосте ничего не показывает.

Многие production-команды рассматривают RED + Saturation как практическую эволюцию сигналов из SRE-книги:

Senior-структура дашборда

Хорошо структурированный дашборд сервиса читается сверху вниз во время инцидента:

Ряд 1: RED  — панель Rate | панель Errors | панель Duration p50/p95/p99
Ряд 2: USE  — CPU util+PSI | Memory util+PSI | Disk %util+queue
Ряд 3: Downstreams — время ответа + errors DB | hit rate кэша | глубина очереди

Ритм чтения:

1. Какая RED-метрика изменилась?
2. Какой USE-ряд совпадает по времени?
3. Какая downstream-зависимость следовала тому же временному профилю?
4. Кликни exemplar для подтверждения в трейсе.

Ключевая дисциплина: RED и USE делят одну временну́ю ось на одном дашборде. Кросс-сервисная корреляция требует консистентных ключей label (service, route, region), чтобы панели можно было фильтровать одним набором label.

Разделение severity в алертинге

Зрелый паттерн — алертить на user-facing симптомы (RED) с page-severity и на сигналы внутренних причин (USE) с warning-severity:

Разделение намеренное. RED-алерты будят людей, потому что затронуты пользователи. USE-алерты уходят в более медленный канал, чтобы capacity-команды планировали заранее — а не on-call просыпался каждый раз при достижении CPU 70%. Одно это архитектурное решение — один из сильнейших инструментов против alert fatigue.

Auto-RED в service mesh

Service mesh (Envoy, Linkerd, Istio) эмитируют RED-метрики на уровне sidecar без изменений кода приложения. Метрики Envoy downstream_rq_total, downstream_rq_xx и downstream_rq_time дают Rate, Errors-по-статусу и гистограмму Duration на кластер, с консистентными label по всему fleet.

Преимущество: полиглотный fleet (Node, Go, Python, JVM, Rust) получает один паттерн RED-дашборда, даже если языки расходятся в конвенциях Prometheus-клиентов.

Ограничение: sidecar видит только то, что видит сеть. Запрос, успешный с точки зрения sidecar, но неправильно обслуженный из-за бага в коде приложения, отображается как 2xx в mesh-метриках.

Production-паттерн: работай на обоих уровнях — sidecar RED для широты и консистентности, RED на уровне приложения для business-logic точности (например, счётчик payment-success с label по gateway, который sidecar не видит). Держи ключи label согласованными между обоими уровнями, чтобы дашборды могли их объединять.

RED переносится на другие протоколы

Запросо-центричная форма RED переносится на любой протокол; изменяется только определение «запроса» и «ошибки»:

Для async- и queue-based сервисов глубина очереди (backlog) — это сигнал Saturation, который чистый RED упускает. Очередь с Duration p99 10 с на задание может иметь бэклог на 10 минут — пользователь ждёт 10 мин + 10 с. RED фиксирует время обработки задания; Saturation фиксирует ожидание в очереди до начала обработки.