Сообщить об ошибкеКороткий ответ
Минимальный набор: загрузка CPU и потребление памяти, частота запросов (throughput), доля ошибок (error rate) и latency (обычно p50/p95/p99) — этого достаточно, чтобы быстро понять, жив сервис, справляется ли он с нагрузкой и растёт ли доля проблем.
Как это работает подробнее
CPU/память показывают, не исчерпал ли процесс ресурсы контейнера (что в Kubernetes может привести к throttling или OOMKilled); throughput показывает, сколько запросов обрабатывается сейчас, в сравнении с обычным уровнем; error rate — долю неуспешных ответов; latency в процентилях (а не в среднем) показывает реальный пользовательский опыт, так как среднее легко скрывает отдельные медленные запросы.
Пример кода
query.promql
# Error rate (доля 5xx за 5 минут)
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))
# p95 latency
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))Что использовать на практике
- Практика. дашборд для дежурного должен открываться быстро и помещаться на одном экране без скролла — его задача дать ответ "где искать" за 10–20 секунд, а не заменить детальное расследование. Для сравнения "нормально это или нет" полезно показывать текущее значение рядом с таким же показателем неделю назад.
- Практика. Если первый запрос вдруг показывает рост с обычных 0.1% до 5%, а второй — рост p95 с 200 мс до 2 секунд, дежурный сразу видит деградацию на верхнем уровне дашборда и может переходить к логам/трейсам для деталей.
Подводные камни
- Частые ошибки. показывать только среднее значение latency вместо процентилей, из-за чего редкие, но критичные медленные запросы остаются незамеченными; перегружать дашборд десятками мелких панелей, из-за чего дежурный не может быстро найти главное; не указывать единицы измерения и пороги на панелях, заставляя дежурного каждый раз думать, что считается "нормой".