Мониторинг Docker и Kubernetes в 2026 году
Мониторинг Kubernetes — это не просто «поставить Prometheus и Grafana». Это понимание того, что именно нужно измерять, чтобы видеть реальное состояние кластера и приложений. В 2026 году стандартом стала связка Prometheus (или VictoriaMetrics) + Grafana, но без понимания ключевых метрик дашборды остаются бесполезными.
В этой статье — что мониторить в Kubernetes и Docker, какие метрики действительно важны, как настроить стек. Разберём практические примеры, включая новый инструмент PSI (Pressure Stall Information), который появился в ядре Linux и меняет подход к диагностике. Если нужен мониторинг Kubernetes под ключ — поможем.
Почему Kubernetes — не просто серверы
Традиционный мониторинг серверов отвечает на вопрос: «Работает ли сервер?» Мониторинг Kubernetes должен отвечать на более сложные вопросы:
- Работают ли приложения? — под может быть в статусе Running, но приложение внутри не отвечает;
- Хватает ли ресурсов? — нода может быть загружена на 40%, но поды стоят из-за memory pressure;
- Правильно ли работает автмасштабирование? — HPA может не справляться с нагрузкой;
- Нет ли «шумных соседей»? — один под может съедать ресурсы всего кластера;
- Как быстро восстанавливается сервис? — скорость перезапуска подов, время готовности.
Специфика K8s-мониторинга
- Эфемерность: поды создаются и удаляются, метрики нужно собирать динамически;
- Слоистость: контрольная плоскость, ноды, поды, контейнеры, приложения;
- Service Discovery: Prometheus должен автоматически находить новые цели;
- Много арендаторов: в одном кластере работают десятки команд и приложений.
Архитектура мониторинга
Типовая архитектура мониторинга Kubernetes в 2026 году выглядит так:
- Сбор метрик: Prometheus или VictoriaMetrics с ServiceMonitor/PodMonitor;
- Экспортёры: kube-state-metrics, node-exporter, cAdvisor;
- Хранение: локальное (Prometheus TSDB) или удалённое (VictoriaMetrics, Thanos);
- Алерты: Alertmanager или vmalert;
- Визуализация: Grafana с дашбордами для K8s;
- Логи: Loki, Elastic/OpenSearch, Grafana Alloy;
- Трейсы: Tempo, Jaeger, OpenTelemetry Collector.
Слои мониторинга
| Слой | Что мониторить | Инструмент |
|---|---|---|
| Контрольная плоскость | etcd, API Server, Scheduler, Controller Manager | Prometheus |
| Ноды | CPU, RAM, диск, сеть, kubelet | node-exporter |
| K8s-объекты | Поды, deployments, services, jobs | kube-state-metrics |
| Контейнеры | CPU, RAM, I/O, сеть контейнеров | cAdvisor |
| Приложения | Бизнес-метрики, latency, ошибки | Кастомные экспортёры |
Ключевые метрики
Не все метрики одинаково полезны. Вот что действительно важно для Kubernetes.
Поды
- kube_pod_status_phase — статус пода (Running, Pending, Failed);
- kube_pod_container_status_restarts_total — количество перезапусков (частые рестарты — признак проблемы);
- kube_pod_container_status_ready — готовность контейнера;
- kube_pod_container_resource_requests/limits — запрошенные и лимитные ресурсы.
Ресурсы контейнеров
- container_cpu_usage_seconds_total — использование CPU;
- container_memory_working_set_bytes — использование памяти (важнее, чем RSS);
- container_fs_usage_bytes — использование диска;
- container_network_receive/transmit_bytes_total — сетевой трафик.
Ноды
- node_cpu_seconds_total — загрузка CPU;
- node_memory_MemAvailable_bytes — доступная память;
- node_filesystem_avail_bytes — свободное место на диске;
- node_load1/5/15 — load average;
- kubelet_volume_stats_used_bytes — использование Persistent Volume.
Deployments и Services
- kube_deployment_status_replicas_available — доступные реплики;
- kube_deployment_spec_replicas — желаемое количество реплик;
- kube_service_spec_type — тип сервиса;
- kube_endpoint_address_available — доступные endpoints.
💡 Важно
Метрики утилизации (CPU, RAM) не всегда показывают реальную проблему. Под может быть загружен на 40%, но при этом стоять в ожидании ресурсов. Именно поэтому в современном мониторинге всё большее значение приобретает PSI (Pressure Stall Information).
PSI: новый подход к диагностике
С 2026 года в Kubernetes (начиная с версии 1.36) появилась встроенная поддержка PSI (Pressure Stall Information) — технологии ядра Linux, которая показывает, сколько времени процессы реально простаивали в ожидании ресурсов, а не просто были заняты.
Почему PSI важен
Классические метрики утилизации не показывают реальную картину. Нода может быть загружена на 40%, но процессы стоят из-за memory pressure. PSI фиксирует именно время простоя.
Как работает PSI
На cgroup v2 у каждой группы есть файлы давления:
- memory.pressure — давление по памяти;
- cpu.pressure — давление по CPU;
- io.pressure — давление по вводу-выводу.
Пример вывода:
- some avg10=12.43 — доля времени, когда хотя бы один процесс стоял;
- full avg10=4.02 — доля времени, когда все процессы стояли.
Метрики PSI в Prometheus
- container_pressure_memory_waiting_seconds_total — время ожидания памяти;
- node_pressure_memory_stalled_seconds_total — время полного простоя ноды.
Как использовать PSI
- На уровне ноды: смотреть полное давление по памяти и I/O;
- На уровне пода: смотреть давление по CPU;
- Не использовать агрегированное CPU-давление ноды для taint — один под может «вытянуть» показатель.
💡 Рекомендация
Заведите алерты на PSI (полное давление по памяти и I/O), а не только на утилизацию. Это коррелирует с жалобами пользователей гораздо лучше.
Стек технологий
Современный стек мониторинга Kubernetes в 2026 году:
| Компонент | Назначение | Популярные решения |
|---|---|---|
| Сбор метрик | Pull-модель, Service Discovery | Prometheus, vmagent |
| Хранение | Time-series DB | VictoriaMetrics, Thanos, Mimir |
| Алерты | Обработка правил и уведомлений | Alertmanager, vmalert |
| Визуализация | Дашборды | Grafana |
| Логи | Сбор и хранение | Loki, Grafana Alloy, Fluent Bit |
| Трейсы | Распределённая трассировка | Tempo, Jaeger, OTel Collector |
| Экспортёры | Сбор метрик | kube-state-metrics, node-exporter, cAdvisor |
Prometheus vs VictoriaMetrics
В 2026 году всё больше компаний выбирают VictoriaMetrics вместо классического Prometheus. Вот почему:
| Параметр | Prometheus | VictoriaMetrics |
|---|---|---|
| Потребление памяти | Высокое | В 5-7 раз ниже |
| Скорость запросов | Стандартная | До 10 раз быстрее |
| Хранение | Локальное, ограниченное | Кластерное, с репликацией |
| Резервное копирование | Сложнее | Проще, через S3 |
| Эксплуатация | Требует опыта | Проще в сопровождении |
| Совместимость | Эталон | PromQL, remote write |
Схема миграции
- Развернуть VictoriaMetrics Cluster — vmstorage, vmselect, vminsert;
- Настроить vmagent — для сбора метрик;
- Настроить vmalert — для алертов;
- Подключить Grafana — к VictoriaMetrics как источнику данных;
- Перенести правила и дашборды — совместимость с PromQL сохраняется.
💡 Важно
VictoriaMetrics полностью совместима с PromQL и remote write, поэтому миграция с Prometheus проходит плавно. Для крупных кластеров это часто более практичный выбор.
Алерты для Kubernetes
Правила алертов для K8s отличаются от мониторинга серверов. Вот что важно:
Группировка по AppID
Один из ключевых принципов — маркировка всех ресурсов меткой AppID. Это позволяет:
- Группировать алерты — все проблемы приложения в одном уведомлении;
- Автоматически маршрутизировать — алерт идёт в команду, которая отвечает за приложение;
- Отслеживать — какие приложения чаще падают.
Пример конфигурации Alertmanager:
- group_by: [appid, alertname]
- group_wait: 30s
- group_interval: 5m
- repeat_interval: 3h
Какие алерты важны
- Pod не готов — kube_pod_container_status_ready == 0 в течение 5 минут;
- Частые рестарты — restarts > 5 за час;
- OOMKilled — контейнер убит из-за памяти;
- PV заполнен — > 85% использования;
- Deployment недоступен — available replicas < spec replicas;
- PSI давление — полное давление по памяти > 10%.
Логи и трейсы
Метрики показывают «что» происходит, логи и трейсы — «почему». В 2026 году стандартом стала связка:
Централизованные логи
- Сбор: Grafana Alloy (Fluent Bit) как DaemonSet;
- Хранение: Loki, Elastic/OpenSearch;
- Формат: структурированные JSON-логи с trace_id, span_id, service, level;
- Сроки хранения: оперативное 7 дней, основное 30-90 дней, архив в объектном хранилище.
Трейсы
- OTel Collector — сбор и обработка;
- Tempo или Jaeger — хранение;
- Интеграция с Grafana — просмотр трейсов из дашбордов.
Безопасность логов
- Маскировать секреты на этапе сбора, а не после записи;
- Удалять персональные данные в соответствии с 152-ФЗ;
- Разделять доступ — каждая команда видит только свои логи.
Чек-лист мониторинга Kubernetes
Инфраструктура
- node-exporter на всех нодах
- kube-state-metrics
- cAdvisor для контейнеров
- Метрики контрольной плоскости
- Метрики etcd
Приложения
- ServiceMonitor для всех сервисов
- Метрики latency и error rate
- AppID на всех ресурсах
- Группировка алертов по AppID
- SLI/SLO для ключевых сервисов
PSI и давление
- Алерты на PSI memory
- Алерты на PSI I/O
- Давление CPU на уровне пода
- Мониторинг OOMKilled
- Мониторинг троттлинга CFS
Логи и трейсы
- Централизованный сбор логов
- Структурированные JSON-логи
- Маскирование секретов
- Трейсы через OTel
- Интеграция с Grafana
Наши рекомендации
Что вы получаете, заказывая мониторинг у нас
- Настройку сбора метрик — node-exporter, kube-state-metrics, cAdvisor;
- Prometheus или VictoriaMetrics — с Service Discovery;
- Grafana-дашборды — для K8s и приложений;
- Алерты с AppID — группировка и маршрутизация;
- Логи и трейсы — Loki, Tempo, OTel;
- Обучение команды — работа с системой;
- Поддержку — обновления, доработки.
📌 Итоговый вывод
Мониторинг Kubernetes в 2026 году — это больше, чем Prometheus и Grafana.
Что нужно знать:
- K8s — не серверы: нужно мониторить поды, ноды, контрольную плоскость и приложения;
- Ключевые метрики: статус подов, рестарты, ресурсы, готовность;
- PSI: новый инструмент, который показывает реальное давление ресурсов, а не просто утилизацию;
- Стек: Prometheus или VictoriaMetrics + Grafana + Loki + Tempo;
- VictoriaMetrics: всё чаще выбирают для крупных кластеров из-за низкого потребления памяти;
- Алерты: группировка по AppID, эскалация, приоритизация;
- Логи: структурированные, с маскированием секретов;
- Чек-лист: инфраструктура, приложения, PSI, логи и трейсы.
Также рекомендуем: мониторинг, Zabbix vs Prometheus, облачный мониторинг (MaaS), Uptime и SLA, Alert Fatigue, все статьи.