Какие базовые сигналы (метрики) нужно собирать, чтобы заметить деградацию сервиса до того, как пользователи начнут жаловаться?

Короткий ответ

Базовый набор — это так называемые "четыре золотых сигнала": latency (задержка ответа), traffic (нагрузка/число запросов), errors (доля ошибок) и saturation (насыщение ресурсов — CPU, память, диск, очереди).

Как это работает подробнее

эти метрики вместе дают полную картину здоровья сервиса — рост latency при стабильном traffic может говорить о насыщении ресурсов, а рост errors при нормальном traffic — о проблеме в коде или зависимости. По отдельности каждая метрика может быть нормальной, но в совокупности выявлять начинающуюся проблему.

Пример / кейс

Ожидаемое поведение: при нормальной работе значение держится около нуля; рост до нескольких процентов должен вызвать алерт задолго до того, как доля ошибок станет заметна пользователям в виде массовых жалоб.

Пример кода

example.promqlКопировать

# Доля ошибок 5xx за последние 5 минут
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Что использовать на практике

• Практический подход. Метрики собирают с помощью систем мониторинга (например, Prometheus) и визуализируют на дашбордах с историческими трендами, чтобы отличать аномалию от обычных суточных/недельных колебаний нагрузки. Алерты настраивают на отклонение от baseline, а не только на абсолютные пороги.

Подводные камни

• Частые ошибки. Мониторить только доступность (up/down), не видя деградации при "живом" сервисе; не учитывать насыщение ресурсов (saturation), из-за чего инцидент замечают только когда ресурс уже полностью исчерпан; собирать метрики без алертов, то есть "мониторинг для отчётов", а не для раннего обнаружения.