Golden Signals SRE: налаштування моніторингу

Налаштування Golden Signals SRE: Latency, Traffic, Errors, Saturation

Зауважте: коли сервіс падає, а моніторинг показує все зеленим — це проблема. Стандартний моніторинг CPU та пам’яті не відображає користувацький досвід. Без golden signals ви не дізнаєтеся, що latency зросла до 10 секунд, доки не подивитесь логи. Чотири сигнали — Latency, Traffic, Errors, Saturation — дають відповідь на питання «де копати?». Google описав їх у SRE Book SRE Book, і цей фреймворк залишається одним із найпрактичніших підходів до моніторингу. Він орієнтований на метрики користувача, а не інфраструктури.

Ми налаштовуємо golden signals під ключ: від інвентаризації поточних метрик до дашбордів та алертів з документацією. Вартість базового дашборду – від €500, шаблону для fleet мікросервісів – від €1000. Економія часу на діагностику – до 40%. Наші інженери мають 5+ років досвіду SRE, реалізували 20+ проектів з моніторингу. Зв'яжіться з нами для попередньої оцінки вашого проєкту.

Чому p99 важливіше за середнє?

Latency — час виконання запиту. Головна помилка — моніторити середнє значення. Середнє приховує проблему: якщо 1% запитів займає 30 секунд, а решта 99% — 10ms, середнє виглядатиме нормально, але сотні користувачів щохвилини бачать зависання. p99 latency в 10 разів інформативніше за середнє для діагностики проблем продуктивності. Затримка p99 у 5 разів критичніша за p50 для SLO.

Правильний підхід: 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, масштабувати до деградації.

Дашборд чотирьох сигналів

Один дашборд, чотири row, кожен для одного сигналу. У кожному row — кілька панелей з різними аспектами.

Змінна $service вгорі — дашборд працює для будь-якого сервісу з discovery.

Як впровадити golden signals за 3 кроки

1. Інвентаризація поточних метрик та інструментування. Перевірте, чи є histogram latency та метрики помилок.
2. Налаштування recording rules для histogram, error rate, saturation.
3. Розробка дашборду з чотирма row та набором алертів з порогами yellow/red.

Отримайте консультацію з налаштування моніторингу — ми допоможемо на кожному етапі.

Порівняння: середнє vs перцентилі

Перцентилі дають у 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'ом для алертів.

Досвід наших інженерів — багаторічний у SRE, сертифікація Prometheus та Kubernetes. Гарантуємо відповідність SLA по MTTR.

Терміни та як замовити

Дашборд чотирьох сигналів для одного сервісу — 1-2 дні. Стандартизований шаблон для fleet мікросервісів — 2-3 дні. Вартість розраховується індивідуально.

Оцінимо ваш проєкт. Зв'яжіться з нами — розкажемо, як покращити моніторинг.