Пошаговая настройка мониторинга и алертинга в Kubernetes с Prometheus, Grafana и Alertmanager | AdminWiki
Logo

Пошаговая настройка мониторинга и алертинга в Kubernetes с Prometheus, Grafana и Alertmanager

24 июля 2026 12 мин. чтения
Содержание статьи

Кластер Kubernetes без мониторинга - это полет по приборам с заклеенной приборной панелью. Вы узнаете о проблеме только тогда, когда приложение уже упало, а пользователи пишут в поддержку. Prometheus, Grafana и Alertmanager решают эту задачу: собирают метрики со всех узлов и подов, визуализируют их на дашбордах и отправляют уведомления до того, как мелкий сбой перерастет в инцидент.

Этот стек - стандарт де-факто для Kubernetes. Он входит в CNCF, поддерживается сообществом и работает в тысячах production-кластеров. В этом руководстве вы развернете полный стек мониторинга через Helm, настроите сбор метрик с узлов и приложений, создадите дашборды в Grafana и сконфигурируете Alertmanager для отправки алертов в Telegram и Slack. Все команды и конфигурации проверены на Kubernetes 1.30 и актуальны на июль 2026 года.

Если вам нужен более широкий взгляд на мониторинг за пределами Kubernetes, изучите полное руководство по развертыванию стека Prometheus и Grafana для серверов и виртуальных машин.

Почему Prometheus, Grafana и Alertmanager - стандарт мониторинга Kubernetes

Kubernetes генерирует огромный поток данных: состояние подов, потребление ресурсов, сетевой трафик, события. Без централизованного сбора эти данные исчезают. Prometheus решает эту проблему через pull-модель: он периодически опрашивает цели и сохраняет временные ряды в своей базе. Это принципиально отличается от push-модели, где агенты сами отправляют метрики на сервер. Pull-модель проще в отладке: вы всегда видите, какие цели опрашиваются и с каким результатом.

Архитектура стека выглядит так:

  • Prometheus собирает метрики с экспортеров (node-exporter, kube-state-metrics, cAdvisor) и приложений. Он же выполняет правила алертинга и передает сработавшие алерты в Alertmanager.
  • Grafana подключается к Prometheus как к источнику данных и строит дашборды. Она не хранит метрики, а только визуализирует их через PromQL-запросы.
  • Alertmanager принимает алерты от Prometheus, группирует их, маршрутизирует по каналам и подавляет дубликаты.

Связка этих трех компонентов покрывает полный цикл: сбор, визуализация, оповещение. В экосистеме Kubernetes для этого используется kube-prometheus-stack - Helm-чарт, который разворачивает все компоненты с преднастроенными правилами и дашбордами. Для глубокого понимания алертинга рекомендую руководство по контролю SLA распределенных систем с готовыми конфигурациями.

Подготовка кластера и выбор метода установки

Для развертывания стека мониторинга нужен работающий кластер Kubernetes версии 1.25 или выше и установленный Helm 3. Минимальные требования по ресурсам: 2 vCPU и 4 ГБ RAM для стека мониторинга сверх того, что потребляет сам кластер. В production-среде планируйте минимум 4 vCPU и 8 ГБ RAM - Prometheus активно потребляет память при большом количестве метрик.

Есть три основных метода установки:

  1. kube-prometheus-stack (рекомендованный). Helm-чарт, который включает Prometheus, Alertmanager, Grafana, node-exporter, kube-state-metrics и набор правил алертинга. Это самый быстрый способ получить рабочий стек с преднастроенными дашбордами.
  2. Prometheus Operator. Отдельный оператор, который управляет экземплярами Prometheus через CRD. Дает больше гибкости, но требует ручной настройки многих компонентов.
  3. Ручная установка через манифесты. Трудоемкий метод, который редко оправдан в production.

В этом руководстве используем kube-prometheus-stack. Если вы работаете с высоконагруженными системами, посмотрите практическое руководство по наблюдаемости для высоконагруженных систем - там разобраны продвинутые сценарии с GitOps и SRE-практиками.

Установка Prometheus, Grafana и Alertmanager через Helm

Добавьте репозиторий и установите чарт:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set prometheus.prometheusSpec.retention=15d \
  --set grafana.adminPassword=admin123

Разберем параметры: retention=15d задает срок хранения метрик в днях (по умолчанию 10 дней, увеличьте для production), grafana.adminPassword устанавливает пароль администратора Grafana. В production передавайте пароль через Kubernetes Secret, а не в командной строке.

Проверьте, что все поды запустились:

kubectl get pods -n monitoring

Вы должны увидеть поды с именами monitoring-prometheus, monitoring-alertmanager, monitoring-grafana, monitoring-kube-state-metrics и monitoring-prometheus-node-exporter (по одному на каждый узел).

Настройка доступа к Grafana и Prometheus

Самый простой способ получить доступ к веб-интерфейсам - проброс портов:

# Grafana
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80

# Prometheus
kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-prometheus 9090:9090

# Alertmanager
kubectl port-forward -n monitoring svc/monitoring-kube-prometheus-alertmanager 9093:9093

Grafana будет доступна на http://localhost:3000. Логин: admin, пароль: тот, что вы указали в grafana.adminPassword. Если вы не задали пароль при установке, получите его командой:

kubectl get secret -n monitoring monitoring-grafana -o jsonpath="{.data.admin-password}" | base64 -d

Для постоянного доступа настройте Ingress. Пример для Nginx Ingress Controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: monitoring-ingress
  namespace: monitoring
spec:
  rules:
  - host: grafana.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: monitoring-grafana
            port:
              number: 80

Аналогично настройте Ingress для Prometheus и Alertmanager, если нужен прямой доступ к их интерфейсам.

Сбор метрик Kubernetes: от узлов до приложений

kube-prometheus-stack автоматически разворачивает три ключевых экспортера:

  • node-exporter собирает метрики узлов: CPU, память, диски, сеть. Запускается как DaemonSet на каждом узле.
  • kube-state-metrics генерирует метрики на основе состояния объектов Kubernetes: статус подов, количество реплик, состояние PVC.
  • cAdvisor встроен в kubelet и собирает метрики контейнеров: использование CPU и памяти каждым контейнером.

Prometheus обнаруживает цели через ServiceMonitor и PodMonitor - CRD, которые описывают, какие сервисы опрашивать и с какими параметрами. По умолчанию чарт создает ServiceMonitor для всех компонентов стека и для kubelet. Посмотрите список активных целей в Prometheus UI: перейдите на http://localhost:9090/targets после проброса порта. Вы увидите десятки целей, сгруппированных по типу.

Мониторинг состояния узлов и подов

Метрики узлов доступны через node-exporter. Основные запросы PromQL:

  • Загрузка CPU: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) - процент использования CPU за 5 минут.
  • Использование памяти: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 - процент занятой памяти.
  • Свободное место на диске: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 - процент свободного места на корневом разделе.
  • Сетевой трафик: rate(node_network_receive_bytes_total[5m]) - входящий трафик в байтах в секунду.

Метрики подов доступны через kube-state-metrics и cAdvisor:

  • Статус подов: kube_pod_status_phase{phase="Running"} - количество работающих подов.
  • Перезапуски контейнеров: rate(kube_pod_container_status_restarts_total[1h]) - частота перезапусков за час.
  • CPU контейнера: rate(container_cpu_usage_seconds_total{container!=""}[5m]) - использование CPU каждым контейнером.
  • Память контейнера: container_memory_working_set_bytes{container!=""} - рабочая память контейнера в байтах.

Для мониторинга дискового пространства PVC используйте kubelet_volume_stats_available_bytes и kubelet_volume_stats_capacity_bytes. Детальный разбор мониторинга дисков в контейнерах есть в руководстве по мониторингу кластерных систем, где также рассмотрены специализированные инструменты для Ceph и Pacemaker.

Добавление метрик приложений

Чтобы Prometheus собирал метрики с вашего приложения, оно должно экспортировать их в формате Prometheus на HTTP-эндпоинте (обычно /metrics). Затем создайте ServiceMonitor, который укажет Prometheus, как найти этот сервис.

Пример ServiceMonitor для приложения, которое экспортирует метрики на порту 8080:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: my-app
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics
  namespaceSelector:
    matchNames:
    - default

Этот манифест говорит Prometheus опрашивать все сервисы с меткой app: my-app в namespace default каждые 30 секунд. Сервис должен иметь порт с именем metrics. После применения манифеста цель появится в списке targets Prometheus.

Создание дашбордов в Grafana для визуализации

Grafana в составе kube-prometheus-stack уже подключена к Prometheus как к источнику данных. Проверьте это: зайдите в Grafana, перейдите в Connections → Data Sources и убедитесь, что Prometheus настроен.

Импорт готовых дашбордов

kube-prometheus-stack включает десятки преднастроенных дашбордов. Они доступны сразу после установки. Перейдите в Dashboards → Browse и найдите дашборды с префиксом «Kubernetes». Рекомендую начать с этих:

  • Kubernetes / Compute Resources / Cluster - общая загрузка CPU и памяти по кластеру.
  • Kubernetes / Compute Resources / Namespace (Pods) - потребление ресурсов подами в разрезе namespace.
  • Kubernetes / Compute Resources / Node (Pods) - нагрузка на каждом узле.
  • Kubernetes / Networking / Cluster - сетевой трафик.

Если нужных дашбордов нет, импортируйте их из Grafana.com по ID. Популярные ID для Kubernetes: 315 (общий мониторинг), 6417 (детализация по узлам), 1860 (состояние подов). Для импорта перейдите в Dashboards → New → Import, введите ID и выберите источник данных Prometheus.

Создание кастомного дашборда

Готовые дашборды покрывают типовые сценарии, но для своих задач нужны кастомные панели. Создайте новый дашборд: Dashboards → New → New Dashboard → Add Visualization. Выберите источник данных Prometheus.

Примеры панелей:

  • CPU по namespace: запрос sum(rate(container_cpu_usage_seconds_total{container!="", namespace="$namespace"}[5m])) by (pod), визуализация - Time series.
  • Память по подам: запрос container_memory_working_set_bytes{container!="", namespace="$namespace"}, визуализация - Table.
  • Статусы подов: запрос kube_pod_status_phase{namespace="$namespace"}, визуализация - Stat.

Переменные делают дашборд переиспользуемым. Добавьте переменную namespace: Settings → Variables → Add Variable, тип Query, запрос label_values(kube_namespace_created, namespace). Теперь вы можете фильтровать дашборд по namespace через выпадающий список вверху.

Для быстрого старта с визуализацией используйте руководство по системам мониторинга производительности - там есть готовые дашборды и конфигурации для типовых метрик CPU, RAM и диска.

Настройка правил алертинга в Prometheus

Правила алертинга описываются в CRD PrometheusRule. kube-prometheus-stack включает набор базовых правил, но их нужно адаптировать под свою инфраструктуру. Синтаксис правила:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: custom-alerts
  namespace: monitoring
spec:
  groups:
  - name: node-alerts
    rules:
    - alert: HighCPUUsage
      expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Высокая загрузка CPU на {{ $labels.instance }}"
        description: "Загрузка CPU превышает 80% в течение 5 минут. Текущее значение: {{ $value }}%"

Ключевые элементы: expr - PromQL-выражение, которое возвращает true при срабатывании; for - как долго условие должно выполняться перед отправкой алерта (защита от ложных срабатываний); labels - метки для маршрутизации в Alertmanager; annotations - описание, которое попадет в уведомление.

Базовые правила для инфраструктуры

Набор правил, который закрывает большинство сценариев отказов:

groups:
- name: infrastructure
  rules:
  - alert: NodeHighCPU
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Высокая загрузка CPU на узле {{ $labels.instance }}"
  - alert: NodeLowMemory
    expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Нехватка памяти на узле {{ $labels.instance }}"
  - alert: NodeDiskPressure
    expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) < 0.1
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Заканчивается место на диске узла {{ $labels.instance }}"
  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
    for: 0m
    labels:
      severity: critical
    annotations:
      summary: "Под {{ $labels.pod }} в цикле перезапуска"
  - alert: PodNotReady
    expr: kube_pod_status_ready{condition="false"} == 1
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Под {{ $labels.pod }} не готов более 5 минут"

Правило for: 0m в PodCrashLooping означает мгновенную отправку алерта при обнаружении цикла перезапуска. Это оправдано: перезапускающийся под почти всегда означает проблему, требующую немедленного вмешательства.

Правила для приложений

Алертинг на бизнес-метрики приложения. Пример для веб-сервиса, который экспортирует счетчик HTTP-ошибок:

- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Высокая доля ошибок 5xx в сервисе {{ $labels.service }}"
    description: "Доля ошибок: {{ $value | humanizePercentage }} за последние 5 минут"

Это правило сработает, если более 5% запросов возвращают ошибки 5xx в течение 5 минут. Порог подбирайте под свой сервис: для высоконагруженных систем даже 1% ошибок может быть критичным.

Интеграция Alertmanager с Telegram и Slack

Alertmanager получает алерты от Prometheus и доставляет их по настроенным каналам. Конфигурация хранится в Secret alertmanager-monitoring-kube-prometheus-alertmanager в namespace monitoring. Чтобы изменить настройки, отредактируйте этот Secret или передайте конфигурацию через values.yaml при установке чарта.

Базовая структура конфигурации:

global:
  resolve_timeout: 5m
route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
  - match:
      severity: critical
    receiver: 'critical-alerts'
receivers:
- name: 'default'
- name: 'critical-alerts'

Параметры маршрутизации: group_by группирует алерты по меткам, чтобы не отправлять 50 уведомлений о падении 50 подов одного сервиса; group_wait - пауза перед отправкой первой группы (ждет сбора всех алертов); group_interval - интервал между отправками новых алертов в группе; repeat_interval - через сколько повторять алерт, если он не закрыт.

Отправка уведомлений в Telegram

Создайте бота через @BotFather в Telegram и получите токен. Узнайте chat_id: добавьте бота в группу или напишите ему лично, затем выполните запрос https://api.telegram.org/bot<токен>/getUpdates и найдите chat.id в ответе.

Добавьте receiver в конфигурацию Alertmanager:

receivers:
- name: 'telegram'
  telegram_configs:
  - bot_token: 'YOUR_BOT_TOKEN'
    chat_id: YOUR_CHAT_ID
    parse_mode: 'HTML'
    message: |
      {{ .GroupLabels.alertname }}
      Severity: {{ .CommonLabels.severity }}
      {{ range .Alerts }}
      {{ .Annotations.summary }}
      {{ .Annotations.description }}
      {{ end }}

Alertmanager использует шаблонизатор Go. Переменные в двойных фигурных скобках подставляются из меток и аннотаций алерта. .CommonLabels - метки, общие для всех алертов в группе, .Alerts - список сгруппированных алертов.

Отправка уведомлений в Slack

Создайте Incoming Webhook в Slack: перейдите в настройки рабочего пространства → Apps → Manage Apps → поиск «Incoming Webhooks» → Add to Slack. Выберите канал и скопируйте URL вебхука.

Конфигурация receiver для Slack:

receivers:
- name: 'slack'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
    channel: '#alerts'
    title: '{{ .GroupLabels.alertname }}'
    text: |
      Severity: {{ .CommonLabels.severity }}
      {{ range .Alerts }}
      *{{ .Annotations.summary }}*
      {{ .Annotations.description }}
      {{ end }}

Для маршрутизации критичных алертов в оба канала, а предупреждений только в Slack, настройте routes:

route:
  receiver: 'slack'
  routes:
  - match:
      severity: critical
    receiver: 'critical-alerts'
receivers:
- name: 'slack'
  slack_configs: [...]
- name: 'critical-alerts'
  slack_configs: [...]
  telegram_configs: [...]

Проверка и отладка системы мониторинга

После настройки алертов проверьте, что они срабатывают. Самый безопасный способ - создать тестовый под с высокой нагрузкой:

kubectl run stress-test --image=polinux/stress --restart=Never -- stress --cpu 2 --timeout 60s

Этот под загрузит 2 ядра CPU на 60 секунд. Если у вас настроен алерт на высокую загрузку CPU, он сработает через 5 минут (значение for в правиле). Проверьте статус алертов в Prometheus UI на вкладке Alerts. Вы увидите алерт в состоянии Pending (условие выполняется, но for еще не истек), затем Firing.

Если алерт не срабатывает, проверьте:

  1. Цели в Prometheus: Status → Targets. Все цели должны быть в состоянии UP. Если цель в DOWN, проверьте сетевую доступность и аннотации сервиса.
  2. Правила алертинга: Status → Rules. Найдите свое правило и проверьте, что оно активно и не имеет ошибок в выражении.
  3. Логи Alertmanager: kubectl logs -n monitoring deployment/monitoring-kube-prometheus-alertmanager. Ошибки конфигурации или проблемы с доставкой будут в логах.
  4. Метки алерта: алерт должен иметь метки, которые совпадают с маршрутами в Alertmanager. Если метка severity: critical отсутствует, алерт попадет в дефолтный receiver.

Типовая ошибка: алерт в статусе Firing, но уведомление не приходит. Причина - несовпадение меток в маршрутизации Alertmanager. Проверьте, что метки алерта (вкладка Alerts → клик на алерт → Labels) совпадают с match в конфигурации маршрутов.

Дальнейшие шаги: масштабирование и отказоустойчивость

Базовая установка kube-prometheus-stack использует один экземпляр Prometheus с локальным хранилищем. Для production-среды этого недостаточно. Два основных направления развития:

Долговременное хранение метрик. Prometheus хранит данные на локальном диске. При потере пода теряются и метрики. Настройте Persistent Volume Claim для Prometheus через values.yaml:

prometheus:
  prometheusSpec:
    storageSpec:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 100Gi

Для хранения метрик за пределами жизненного цикла кластера используйте Thanos или Cortex. Эти системы интегрируются с Prometheus и обеспечивают долговременное хранение в объектном хранилище (S3, GCS).

Федерация Prometheus. В крупных кластерах один Prometheus не справляется с объемом метрик. Федерация позволяет запустить несколько экземпляров Prometheus: одни собирают метрики с групп узлов, другой агрегирует агрегированные данные с них. Это снижает нагрузку и позволяет масштабировать мониторинг горизонтально.

Резервное копирование конфигураций. Храните PrometheusRule, ServiceMonitor и конфигурацию Alertmanager в Git. Это позволит восстановить мониторинг после сбоя и отслеживать изменения. Примените GitOps-подход: храните манифесты в репозитории и применяйте их через Flux или ArgoCD.

Стек Prometheus, Grafana и Alertmanager - это фундамент наблюдаемости Kubernetes. Начните с базовой установки, настройте алерты на критические метрики и постепенно добавляйте кастомные дашборды и правила под свои сервисы. Система мониторинга должна развиваться вместе с инфраструктурой.

Поделиться:
Сохранить гайд? В закладки браузера