Ответ
В парадигме контейнеризации и оркестрации (Kubernetes, Docker Swarm) приоритет смещается с мониторинга отдельных контейнеров на мониторинг сервисов и приложений. Вот почему:
1. Эфемерность контейнеров: Контейнеры создаются и уничтожаются оркестратором для масштабирования, обновлений (rolling update) или при сбоях. Мониторинг временного объекта имеет ограниченную ценность.
2. Сервис-ориентированный подход: Пользователя интересует доступность и производительность сервиса (например, api-gateway), а не состояние каждого из 10 его реплик-контейнеров. Если один контейнер упал, но сервис здоров (другие реплики обрабатывают нагрузку), это не является инцидентом.
3. Роль оркестратора: Системы вроде Kubernetes сами отслеживают состояние контейнеров (liveness/readiness probes) и перезапускают их при необходимости. DevOps-инженер настраивает эти пробы и мониторит события кластера (Kubernetes Events).
4. Практический пример настройки Prometheus для Kubernetes:
# Prometheus мониторит сервис через Service Discovery, а не отдельные Pod'ы.
scrape_configs:
- job_name: 'kubernetes-services'
kubernetes_sd_configs:
- role: service
relabel_configs:
# Отбираем только сервисы с аннотацией для мониторинга
- source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: trueЧто мониторим вместо контейнеров?
- Метрики приложения (Business Logic): RPS, latency, error rate.
- Метрики сервиса в Kubernetes: готовность эндпоинтов, количество готовых Pod'ов.
- Метрики узлов (Nodes): CPU, memory, disk I/O на физических/виртуальных машинах, где работают контейнеры.
- Метрики кластера: состояние узлов, распределение ресурсов.
Базовый мониторинг ресурсов контейнеров (CPU, memory) через cAdvisor или метрики kubelet полезен для глубокой диагностики проблем производительности, но не является основным источником алертинга.