Ответ
В моей практике состояние микросервисной архитектуры оценивается по четырем ключевым золотым сигналам мониторинга, которые мы отслеживаем в реальном времени через Prometheus и Grafana.
1. Задержка (Latency) Время ответа сервиса должно оставаться в пределах SLA. Я отслеживаю перцентили (p50, p95, p99). Например, для HTTP-сервиса:
# p95 latency за 5 минут
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))2. Трафик (Traffic) Объем запросов, который обрабатывает сервис. Резкие изменения могут указывать на проблемы:
rate(http_requests_total[5m])3. Ошибки (Errors) Доля ошибочных ответов должна быть минимальной. Мы настраиваем алерты при превышении порога в 1%:
# Alert при >1% ошибок 5xx
rate(http_requests_total{status=~"5.."}[5m])
/
rate(http_requests_total[5m]) > 0.014. Насыщенность (Saturation) Насколько "наполнены" ресурсы сервиса (CPU, память, дисковое IO, сеть). Для контейнеров в Kubernetes:
# Использование памяти контейнером
container_memory_working_set_bytes{pod=~"my-service-.*"}
# Лимит памяти
container_spec_memory_limit_bytes{pod=~"my-service-.*"}Дополнительные проверки:
- Health checks должны возвращать 200 OK (
kubectl get endpoints). - Логи без критических исключений (отслеживаем через ELK/Loki).
- Зависимости (базы данных, очереди) доступны и отвечают.
- Балансировка трафика равномерна между репликами.
- Автоскейлинг HPA корректно реагирует на нагрузку.
На дашборде в Grafana у меня сводка по всем этим метрикам, что позволяет за 30 секунд оценить общее состояние системы.
