Мониторинг Docker-контейнеров: метрики, инструменты и лучшие практики

Почему мониторинг контейнеров отличается

Docker-контейнеры эфемерны. Они запускаются, останавливаются, масштабируются автоматически. Контейнер, работающий сейчас, может не существовать через пять минут. Традиционный серверный мониторинг сайтов — отслеживание долгоживущих хостов со статическими IP — не работает в контейнерной среде. Нужен мониторинг, адаптирующийся к динамической инфраструктуре.

Мониторинг контейнеров должен учитывать: короткоживущие экземпляры, высокую кардинальность (сотни и тысячи контейнеров), разделяемые ресурсы хоста, события оркестрации и многослойную архитектуру.

Ключевые метрики

CPU

• Использование CPU — процент от выделенного CPU. В Docker это относительно лимита контейнера, а не общего CPU хоста
• CPU throttling — при достижении лимита CPU ядро ограничивает контейнер. Частый throttling означает, что лимит слишком низкий

# Проверка CPU-использования контейнеров
docker stats --no-stream --format \
    "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

# Вывод:
# NAME          CPU %     MEM USAGE / LIMIT
# web-app       15.23%    256MiB / 512MiB
# redis         2.41%     64MiB / 128MiB
# postgres      8.76%     512MiB / 1GiB

Память

• Использование памяти — текущий RSS (Resident Set Size) процесса контейнера
• Лимит памяти — максимально выделенная память. Превышение вызывает OOM killer, который завершает контейнер
• Кэш-память — файловый кэш, используемый контейнером. Может быть освобождён под давлением, поэтому отличайте его от реального потребления памяти приложением

Сеть

• Сетевой I/O — отправленные и полученные байты на контейнер
• Количество соединений — число активных TCP-соединений
• Потери пакетов — указывают на сетевую перегрузку или ошибку конфигурации
• Время DNS-разрешения — DNS контейнера может быть узким местом, особенно со встроенным DNS-резолвером Docker

Жизненный цикл контейнера

• Количество перезапусков — частые перезапуски указывают на крэши или провалы health check
• Время работы (uptime) — как долго контейнер работает
• Коды выхода — 0 = норма, 1 = ошибка приложения, 137 = OOM kill, 143 = SIGTERM
• Статус health check — healthy, unhealthy, starting

Архитектура стека мониторинга

Контейнеры → cAdvisor (сбор метрик)
                ↓
           Prometheus (хранение временных рядов)
                ↓
           Grafana (визуализация + дашборды)
                ↓
           Alertmanager (уведомления)

cAdvisor

Container Advisor от Google запускается как контейнер и автоматически обнаруживает и собирает метрики со всех контейнеров на хосте:

# Запуск cAdvisor
docker run -d \
    --name cadvisor \
    --volume /:/rootfs:ro \
    --volume /var/run:/var/run:ro \
    --volume /sys:/sys:ro \
    --volume /var/lib/docker/:/var/lib/docker:ro \
    --publish 8080:8080 \
    gcr.io/cadvisor/cadvisor:latest

Конфигурация Prometheus

# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

Важные алерты

# Правила алертинга Prometheus
groups:
  - name: container_alerts
    rules:
      # Контейнер использует >90% лимита памяти
      - alert: ContainerMemoryHigh
        expr: |
          container_memory_usage_bytes /
          container_spec_memory_limit_bytes > 0.9
        for: 5m
        annotations:
          summary: "Контейнер {{ $labels.name }} память > 90%"

      # Контейнер часто перезапускается
      - alert: ContainerRestartLoop
        expr: |
          increase(container_restart_count[1h]) > 3
        labels:
          severity: critical
        annotations:
          summary: "Контейнер {{ $labels.name }} перезапущен 3+ раз за час"

      # Контейнер нездоров
      - alert: ContainerUnhealthy
        expr: container_health_status{status="unhealthy"} == 1
        for: 1m
        labels:
          severity: critical

Health Checks в Docker Compose

# docker-compose.yml
services:
  web:
    image: myapp:latest
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M

Мониторинг логов

Логи контейнеров не менее важны:

• stdout/stderr — приложения должны логировать в stdout. Docker захватывает их и делает доступными через docker logs
• Драйверы логов — Docker поддерживает несколько драйверов: json-file (по умолчанию), syslog, fluentd, awslogs
• Централизованное логирование — отправляйте логи в ELK (Elasticsearch, Logstash, Kibana), Loki или облачный сервис

Внешний мониторинг

Внутренние метрики (CPU, память, перезапуски) показывают здоровье контейнера, но внешний мониторинг показывает здоровье сервиса — что реально видят пользователи. Используйте внешний мониторинг доступности (например, Enterno.io) для проверки ваших контейнерных сервисов извне сети. Это ловит проблемы, невидимые изнутри: проблемы DNS, ошибки конфигурации балансировщика, проблемы TLS-сертификатов и сетевые отказы.

Лучшие практики

• Всегда устанавливайте лимиты ресурсов — контейнеры без лимита памяти могут потребить всю память хоста и «уронить» другие контейнеры
• Используйте метки для организации — помечайте контейнеры именем сервиса, командой, окружением. Это делает дашборды осмысленными
• Мониторьте хост, а не только контейнеры — место на диске, CPU хоста, память ядра и здоровье Docker daemon влияют на все контейнеры
• Реализуйте health checks — автоматический перезапуск нездоровых контейнеров и предотвращение маршрутизации трафика к сломанным экземплярам
• Настройте ротацию логов — без ротации логи контейнеров могут заполнить диск. Настройте max-size и max-file
• Отслеживайте уязвимости образов — мониторьте базовые образы на известные CVE. Инструменты: Trivy, Snyk, Docker Scout
• Алертинг на код выхода 137 — это OOM kill. Контейнеру нужно больше памяти или есть утечка
• Отделяйте мониторинг от мониторируемого — запускайте стек мониторинга на отдельной инфраструктуре, чтобы он пережил те отказы, которые должен обнаруживать

Заключение

Мониторинг Docker-контейнеров требует перехода от статического серверного мониторинга к динамической, многослойной наблюдаемости. Отслеживайте CPU, память, сеть и диск на уровне контейнера; события жизненного цикла; health checks приложения; и внешнюю доступность сервиса. Используйте cAdvisor, Prometheus и Grafana как основу мониторинга, дополняйте централизованным логированием и всегда комбинируйте внутренние метрики с внешним мониторингом доступности для полной видимости контейнерных сервисов.