Зачем нужен Prometheus Operator и как он упрощает жизнь
Ручная настройка Prometheus в Kubernetes - это постоянная правка ConfigMap, перезагрузка сервера при каждом изменении и риск потерять новые поды из виду. Prometheus Operator заменяет этот процесс декларативным управлением. Вы описываете, какие сервисы мониторить, через стандартные объекты Kubernetes - ServiceMonitor и PodMonitor, а оператор сам находит цели, генерирует конфигурацию и применяет её без перезапуска.
Оператор вводит в кластер набор Custom Resource Definitions (CRD). Основные из них: Prometheus (описывает экземпляр Prometheus), ServiceMonitor (сбор метрик через сервисы), PodMonitor (прямой сбор с подов), PrometheusRule (правила алертинга) и Alertmanager (управление оповещениями). Каждый компонент конфигурируется отдельно, а оператор следит за их согласованностью.
Преимущества такого подхода:
- Динамическое обнаружение целей. Новый деплоймент с аннотациями prometheus.io/scrape автоматически появляется в списке таргетов.
- Управление правилами алертинга через Git. PrometheusRule хранится в репозитории, версионируется и применяется через kubectl apply.
- Масштабирование. Оператор поддерживает шардирование и федерацию Prometheus для кластеров из сотен узлов.
- Интеграция с Grafana. Источник данных настраивается один раз, дашборды обновляются автоматически.
Если вы уже работали со стеком мониторинга серверов Prometheus и Grafana, то оператор покажется логичным продолжением - он переносит те же принципы в мир оркестрации.
Установка Prometheus Operator в кластер
Для установки нужен работающий кластер Kubernetes (версия 1.24+) и kubectl, настроенный на него. Рекомендуемый способ - Helm-чарт kube-prometheus-stack, который включает сам оператор, Prometheus, Alertmanager и Grafana. Он покрывает 90% сценариев и требует минимум ручной донастройки.
Установка через Helm: быстрый старт
Добавьте репозиторий и установите чарт:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install monitoring prometheus-community/kube-prometheus-stack \
--namespace monitoring --create-namespace \
--set prometheus.prometheusSpec.retention=15d \
--set grafana.adminPassword=StrongPass123Ключевые параметры, которые стоит задать сразу:
- prometheus.prometheusSpec.retention - срок хранения метрик. По умолчанию 10 дней, для продакшена увеличивают до 15-30 дней.
- prometheus.prometheusSpec.storageSpec - настройки PersistentVolume. Если не задать, данные потеряются при перезапуске пода.
- grafana.adminPassword - пароль администратора Grafana. В продакшене используют Sealed Secrets или внешний Secret.
- alertmanager.alertmanagerSpec.storageSpec - хранилище для Alertmanager, чтобы не терять состояние алертов.
Проверьте результат:
kubectl get pods -n monitoring
# Ожидаемый вывод: prometheus-operator-*, prometheus-*, alertmanager-*, grafana-*После установки Prometheus доступен через сервис monitoring-prometheus, Grafana - через monitoring-grafana. Для быстрого доступа используйте port-forward:
kubectl port-forward -n monitoring svc/monitoring-grafana 3000:80Установка из манифестов: полный контроль
Если Helm не подходит, используйте манифесты из репозитория kube-prometheus. Этот репозиторий генерирует полный набор YAML-файлов через jsonnet, но для быстрого старта можно взять готовую сборку:
git clone https://github.com/prometheus-operator/kube-prometheus.git
cd kube-prometheus
kubectl apply --server-side -f manifests/setup
kubectl apply -f manifests/Первый apply создаёт CRD и неймспейсы, второй - все компоненты. Обновление делается повторным применением манифестов. Минус подхода - сложнее управлять параметрами: для изменения retention придётся править StatefulSet Prometheus вручную.
Настройка сбора метрик: ServiceMonitor и PodMonitor
После установки оператора Prometheus уже собирает метрики с компонентов Kubernetes: kubelet, kube-state-metrics, node-exporter. Следующий шаг - добавить свои приложения. Для этого используют ServiceMonitor (основной способ) и PodMonitor (для особых случаев).
ServiceMonitor: мониторинг через сервисы
ServiceMonitor находит цели через Kubernetes Service. Он смотрит на селектор сервиса, находит поды за ним и добавляет их в список скрапинга. Пример для веб-приложения, которое отдаёт метрики на порту 8080 по пути /metrics:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: my-app
namespace: production
spec:
selector:
matchLabels:
app: my-web-app
endpoints:
- port: metrics
interval: 30s
path: /metrics
namespaceSelector:
matchNames:
- productionРазбор полей:
- selector.matchLabels - метки сервиса, который указывает на поды приложения.
- endpoints.port - имя порта из спецификации сервиса, не номер.
- interval - как часто опрашивать. 30 секунд - стандарт для большинства приложений.
- namespaceSelector - в каких неймспейсах искать сервисы. Если не указать, ищет только в своём.
Проверьте, что цель появилась: откройте Prometheus UI (port-forward на порт 9090), перейдите в Status → Targets и найдите свой сервис. Состояние "UP" означает, что метрики собираются.
PodMonitor: прямой мониторинг подов
PodMonitor нужен, когда сервиса нет - например, для мониторинга etcd, kubelet или собственных операторов, которые не создают Service. Он подключается напрямую к подам по их IP:
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: etcd-monitor
namespace: kube-system
spec:
selector:
matchLabels:
component: etcd
podMetricsEndpoints:
- port: metrics
interval: 30sОтличие от ServiceMonitor - поле podMetricsEndpoints вместо endpoints. Всё остальное работает аналогично: оператор находит поды по меткам и добавляет их в конфигурацию Prometheus.
Если вы настраиваете мониторинг для высоконагруженных систем, посмотрите руководство по наблюдаемости для высоконагруженных систем - там разобраны метрики и алерты для production-окружений.
Алертинг с PrometheusRule: как не пропустить проблемы
Сбор метрик без алертов - это как камеры наблюдения без охраны. PrometheusRule описывает правила, по которым Prometheus генерирует алерты и отправляет их в Alertmanager. Правила пишутся на PromQL и группируются по severity.
Создание правил алертинга
Пример PrometheusRule для критичных ситуаций в кластере:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: cluster-critical
namespace: monitoring
spec:
groups:
- name: node.rules
rules:
- alert: NodeHighCPU
expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 10m
labels:
severity: critical
annotations:
summary: "Узел {{ $labels.instance }} перегружен по CPU"
description: "Загрузка CPU выше 90% последние 10 минут."
- alert: NodeOutOfMemory
expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
for: 5m
labels:
severity: critical
annotations:
summary: "Узел {{ $labels.instance }} исчерпал память"
- alert: PodCrashLooping
expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
for: 5m
labels:
severity: warning
annotations:
summary: "Под {{ $labels.pod }} в цикле перезапуска"Ключевые элементы:
- expr - PromQL-выражение. Если возвращает значение, алерт срабатывает.
- for - сколько времени условие должно выполняться до отправки алерта. Предотвращает ложные срабатывания на кратковременных всплесках.
- labels.severity - уровень критичности. Используется для маршрутизации в Alertmanager.
- annotations - описание, которое попадёт в уведомление.
Для диагностики проблем с подами через метрики пригодятся готовые PromQL-запросы из руководства по Kubernetes troubleshooting - там собраны запросы для поиска утечек памяти, перегрузки CPU и сетевых проблем.
Настройка Alertmanager для отправки уведомлений
Alertmanager получает алерты от Prometheus, группирует их и отправляет получателям. Конфигурация задаётся в манифесте Alertmanager или через values.yaml при установке через Helm:
alertmanager:
config:
global:
slack_api_url: 'https://hooks.slack.com/services/YOUR/TOKEN'
route:
group_by: ['severity']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receiver: 'slack-critical'
routes:
- match:
severity: critical
receiver: 'slack-critical'
- match:
severity: warning
receiver: 'slack-warning'
receivers:
- name: 'slack-critical'
slack_configs:
- channel: '#alerts-critical'
title: '[CRITICAL] {{ .GroupLabels.severity }}'
text: '{{ .CommonAnnotations.description }}'
- name: 'slack-warning'
slack_configs:
- channel: '#alerts-warning'Маршрутизация работает так: алерт с severity=critical попадёт в канал #alerts-critical, с severity=warning - в #alerts-warning. Параметр group_interval (5 минут) означает, что новые алерты в той же группе не отправляются чаще этого интервала - это защита от шторма уведомлений.
Визуализация метрик в Grafana
Grafana из состава kube-prometheus-stack уже подключена к Prometheus как к источнику данных. Если вы устанавливали оператор из манифестов, источник нужно добавить вручную.
Подключение источника данных Prometheus
В интерфейсе Grafana перейдите: Configuration → Data Sources → Add data source → Prometheus. В поле URL укажите внутренний адрес сервиса Prometheus:
http://monitoring-prometheus.monitoring.svc:9090Нажмите Save & Test. Если соединение установлено, появится зелёная галочка.
Импорт готовых дашбордов для Kubernetes
Самые полезные дашборды для старта:
- Kubernetes Cluster Monitoring (ID 315) - обзор кластера: загрузка узлов, состояние подов, использование ресурсов.
- Node Exporter Full (ID 1860) - детальные метрики каждого узла: CPU, память, диск, сеть.
- Kubernetes Pods (ID 6417) - состояние конкретных подов, рестарты, потребление ресурсов.
Импорт: Dashboards → Import → введите ID → Load → выберите источник Prometheus → Import. Дашборды сразу наполняются данными, если метрики собираются.
Для создания кастомного дашборда под своё приложение начните с панели Graph, выберите метрику через PromQL (например, rate(http_requests_total{app="my-app"}[5m])) и настройте визуализацию. Grafana сохраняет дашборды в JSON, их можно версионировать в Git.
Лучшие практики и типичные ошибки
Хранение метрик и управление ресурсами
Prometheus хранит метрики на диске. По умолчанию retention - 10 дней, для продакшена увеличивайте до 15-30 дней через параметр retention в манифесте Prometheus. Объём хранилища рассчитывайте по формуле: количество метрик × размер одной метрики (~2 байта) × retention в секундах. Для кластера из 10 узлов с 200 тысячами метрик на 15 дней нужно около 50 ГБ.
Обязательно задавайте resource requests и limits:
prometheus:
prometheusSpec:
resources:
requests:
memory: 2Gi
cpu: 500m
limits:
memory: 4Gi
cpu: 2000mБез лимитов Prometheus может занять всю память узла при всплеске метрик. Без requests планировщик Kubernetes может разместить его на перегруженном узле.
Частые проблемы и их решение
ServiceMonitor не видит цели. Проверьте три вещи: совпадают ли метки в селекторе ServiceMonitor с метками сервиса, совпадает ли имя порта в endpoints с именем в спецификации сервиса, и разрешён ли доступ к неймспейсу в namespaceSelector. Откройте лог оператора: kubectl logs -n monitoring deployment/prometheus-operator - там будет ошибка с деталями.
Алерты не срабатывают. Проверьте в Prometheus UI вкладку Alerts - алерт должен быть в состоянии "Pending" или "Firing". Если алерт не появляется, скопируйте выражение из expr в PromQL-редактор и проверьте, возвращает ли оно данные. Если возвращает, но алерта нет - проверьте параметр for, возможно, условие не держится достаточно долго.
Grafana не получает данные. Проверьте соединение с источником данных (Data Sources → Prometheus → Test). Если соединение есть, но графики пустые - проверьте временной диапазон дашборда и селекторы метрик. Часто проблема в том, что метрики есть, но за другой период или с другими метками.
Слишком частый скрапинг. Интервал 5 секунд для 1000 целей создаёт огромную нагрузку. Для большинства приложений достаточно 30-60 секунд. Критичные метрики (например, состояние etcd) опрашивайте чаще, остальные - реже.
Для углублённого изучения полного цикла настройки мониторинга с нуля до продакшена используйте пошаговое руководство по настройке мониторинга и алертинга в Kubernetes - оно охватывает весь стек и содержит проверенные конфигурации.