Перейти к содержанию

10. Production-кейсы (middle+)

Завершающий уровень — не знание кнопок, а сценарии: локализовать деградацию сервиса, объяснить скачок latency, настроить алерт без ложных срабатываний, пройти root cause analysis через связку панелей и SLO-дашборд для бизнеса. Ниже — пошаговые опоры и короткие примеры PromQL / логики.

Материалы по слоям: PromQL, алертинг, логи и трассы.

Кейс: найти причину деградации сервиса

Угол зрения: «зелёный» uptime не отменяет рост ошибок или latency для части пользователей.

Шаг Действие
1 Открыть золотые сигналы: RPS, ошибки, latency, насыщение (CPU/память/очереди)
2 Сравнить с нормальным окном (вчера это же время недели) через time picker shift
3 Сузить переменные deployment / region — не расползаться по всему кластеру
4 При аномалии — Explore в Loki по pod/trace_id, Tempo на конкретный запрос 
# Доля HTTP 5xx (быстрый health-компромисс)
sum(rate(http_requests_total{job="checkout", status=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="checkout"}[5m]))

Production: дашборды сервиса и инфраструктуры должны быть связаны data links; иначе вы теряете минуты на переключение контекста.

Кейс: объяснить spike в latency

Типичные причины: всплеск RPS, saturation подов/ноды, медленный downstream, GC, lock в БД.

Проверка Идея запроса / панели
Нагрузка sum(rate(http_requests_total{job="api"}[5m]))
p95/p99 histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
Ресурс пода CPU throttling, memory, restarts (kube_pod_container_status_restarts_total)
Зависимость Длительность исходящих вызовов, если экспортируются 
# Рост задержки «относительно себя» можно фиксировать recording rule-ом, здесь — сырой p99
histogram_quantile(
  0.99,
  sum by (le, pod) (rate(http_request_duration_seconds_bucket{job="api"}[5m]))
)

Best practice: один инцидент = одна временная метка на графике (annotation) или снимок диапазона для постмортема.

Кейс: алерт без false positive

Принципы из алертинга: For, multi-condition, пороги от SLA, не от «кто-то когда-то сказал 80%».

Пример: высокий error rate только при значимом трафике:

  • A: sum(rate(http_requests_total{job="api"}[5m])) > 20
  • B: доля 5xx > 0.02 с For: 5m
# Идея Alertmanager/Grafana — задержка перед firing
# for: 5m снижает шум от кратковременных сетевых глитчей

Production: прогон сценария в staging с искусственной нагрузкой; метрика «доля ложных» по журналу алертов за квартал.

Кейс: root cause analysis через Grafana

RCA — не один график, а корреляция:

  1. Время инцидента выровнять во всех панелях (utc, один TZ для команды).
  2. Prometheus: что изменилось первым — ошибки, задержка или ресурс?
  3. Loki: |= "Exception" или json | level="error" в окне ±5 мин.
  4. Tempo: trace с максимальной длительностью в том же окне.
  5. Зафиксировать гипотезу и ссылку на runbook в тикете.
{namespace="prod", app="checkout"} |~ "ERROR|Exception"

Best practice: запрет на RCA «в вакууме» без изменений в инфраструктуре за тот же период (деплой, релиз, флаг) — смотреть deployment annotations / CI.

Кейс: SLO dashboard «для бизнеса»

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

Панель Содержание
SLI: успешность 1 - (5xx / all) за скользящее окно или сутки
SLO цель Горизонтальная линия 99.9% / договорённый порог
Error budget Оставшаяся доля допустимых ошибок за период (часто считают вне Grafana в скрипте, сюда — число) 
# SLI «доля не-5xx» за окно 1h (для месячного SLO обычно — recording rules / долговременное хранилище)
sum(rate(http_requests_total{status!~"5.."}[1h]))
/ sum(rate(http_requests_total[1h]))

Комментарий: окна 30d в «чистом» Prometheus на каждом refresh дашборда часто неприемлемы по нагрузке; для error budget за месяц используют Mimir/Thanos, предрасчёт или выгрузку в отчёт.

Best practice: договорённость SLO записана (документ); Grafana только визуализирует, а не задаёт цели за бизнес постфактум.

Мини-чеклист middle+

# Умею
1 За 10 минут отличить нагрузочный от инфраструктурного узкого места
2 Построить минимальный набор панелей для одного критичного сервиса
3 Настроить алерт с For и условием по трафику
4 Пройти путь метрика → лог → trace в Explore
5 Объяснить SLO нетехническому стейкхолдеру по одному экрану

Дополнительные материалы