Ответ
В мониторинге микросервисов мы строго ориентируемся на четыре золотых сигнала, так как они дают полную картину здоровья системы с точки зрения пользователя.
1. Задержка (Latency)
Время, которое система тратит на обработку запроса. Критично измерять латентность успешных и неудачных запросов отдельно. Медленный ошибка 500 может маскироваться под успешный, но долгий ответ.
- Метрика в Prometheus:
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) - Практика: Настроили алерт на рост 99-го перцентиля выше SLA (например, >1с).
2. Трафик (Traffic) Мера нагрузки на систему. Для HTTP-сервисов — это запросы в секунду (RPS).
- Метрика:
rate(http_requests_total[5m]) - Практика: Используем для автоматического масштабирования (HPA) и планирования емкости.
3. Ошибки (Errors)
Частота неудачных запросов. Ошибки могут быть явными (HTTP 5xx, 4xx) или скрытыми (ответы с некорректным содержимым).
- Метрика:
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) - Практика: Алерт срабатывает, если уровень ошибок превышает 1% в течение 2 минут.
4. Насыщенность (Saturation) Показывает, насколько «полна» система. Это не только утилизация CPU/RAM, но и более тонкие метрики: длина очереди сообщений в Kafka, задержка дискового ввода-вывода, исчерпание соединений в пуле БД.
- Метрики:
node_memory_MemAvailable_bytes(доступная память).rate(node_disk_io_time_weighted_seconds_total[5m])(загрузка диска).kafka_consumer_lag(отставание потребителя).
- Практика: Алерты на насыщенность срабатывают раньше, чем система полностью исчерпает ресурсы, давая время на реакцию.
Реализация: Все эти сигналы собираются в Prometheus через exporters (node_exporter, kube-state-metrics, кастомные метрики приложений) и визуализируются на дашбордах Grafana. Алерты управляются через Alertmanager с маршрутизацией в Slack и PagerDuty.