Ответ
Для обеспечения надежности и производительности контейнеризованных приложений я собираю четыре ключевые группы метрик, обычно используя стэк Prometheus + Grafana.
1. Метрики использования ресурсов (Resource Utilization):
- CPU:
container_cpu_usage_seconds_total(Prometheus, источник — cAdvisor). Рассчитываю процент использования:rate(container_cpu_usage_seconds_total[5m]) * 100. Важно сравнивать с лимитами (container_spec_cpu_quota), чтобы видеть, не исчерпал ли контейнер свою долю CPU. - Память:
container_memory_working_set_bytes— фактически используемая резидентная память. Сравниваю с лимитом (container_spec_memory_limit_bytes) для отслеживания приближения к OOMKill. - Диск:
container_fs_usage_bytes— использование дискового пространства volume'ами.
2. Метрики сети (Network I/O):
container_network_receive_bytes_totalиcontainer_network_transmit_bytes_total. Смотрю на скорость приема/передачи:rate(container_network_receive_bytes_total[5m]).
3. Метрики состояния и здоровья (Health & State):
- Рестарты:
kube_pod_container_status_restarts_total(в Kubernetes) — главный индикатор проблем. Рост этого значения сигнализирует о падении контейнера. - Статус готовности и живости (Readiness/Liveness): Проверяю через соответствующие пробы в Kubernetes, статус отображается в метриках kube-state-metrics.
- Uptime:
time() - container_start_time_seconds.
4. Бизнес-метрики приложения (Application Metrics): Инструментирую само приложение для экспорта своих метрик (например, количество запросов, ошибок, latency) через Prometheus-клиент. Эти метрики также привязаны к контейнеру через лейблы.
Пример PromQL-запроса для дашборда:
# Средняя загрузка CPU по подам приложения за 5 минут
sum(rate(container_cpu_usage_seconds_total{container="my-app"}[5m])) by (pod) * 100
# Потребление памяти в % от лимита
(container_memory_working_set_bytes{container="my-app"} / container_spec_memory_limit_bytes{container="my-app"}) * 100На основе этих метрик настраиваю алерты в Alertmanager для превентивного реагирования.