Как собирать метрики с кластера

Сбор метрик в Kubernetes: стратегии и инструменты

Сбор метрик с кластера Kubernetes — это фундаментальная задача для мониторинга, отладки и обеспечения надежности распределенных систем. На практике я использую комплексный подход, который включает сбор метрик на разных уровнях: инфраструктурном, контейнерном, на уровне подов и сервисов. Это позволяет получить полную картину работы кластера.

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

В типичном пайплайне сбора метрик выделяется несколько ключевых компонентов:

• Агенты (Agents): Сборщики метрик, которые разворачиваются на нодах в виде DaemonSet (например, Node Exporter, cAdvisor, Fluent Bit для логов).
• Серверы приложений (Application Servers): Бэкенд, который предоставляет метрики в формате Prometheus (например, /metrics эндпоинт).
• Сборщики (Collectors): Компоненты, которые опрашивают (scrape) агентов и серверы, агрегируют и временно хранят данные (например, Prometheus Server, VictoriaMetrics).
• Долговременное хранилище (Long-term Storage): Системы для хранения исторических данных (например, Thanos, Cortex, M3DB).
• Визуализация (Visualization): Инструменты для построения графиков и дашбордов (например, Grafana).
• Оператор (Operator): Для автоматизации управления компонентами мониторинга в Kubernetes (например, Prometheus Operator).

Практическая реализация с Prometheus Operator

Наиболее зрелым и распространенным решением является стек Prometheus + Grafana, управляемый через Prometheus Operator. Оператор создает и управляет Custom Resources (CRD), такими как Prometheus, ServiceMonitor, PodMonitor и PrometheusRule, что значительно упрощает конфигурацию.

Вот пример ServiceMonitor, который инструктирует Prometheus собирать метрики со всех подов, имеющих определенные лейблы:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-service-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: web
    interval: 30s
    path: /metrics
  namespaceSelector:
    any: true

Для сбора системных метрик с нод используется Node Exporter, развернутый как DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
      - name: node-exporter
        image: prom/node-exporter:latest
        ports:
        - containerPort: 9100
          name: metrics
        volumeMounts:
        - mountPath: /host/proc
          name: proc
          readOnly: true
        - mountPath: /host/sys
          name: sys
          readOnly: true
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys
      tolerations:
      - effect: NoSchedule
        operator: Exists

Выбор стратегии сбора

1. Pull-модель (Prometheus): Классический подход. Prometheus сам "вытягивает" (scrape) метрики из заданных целей по расписанию.

    *   *Плюсы*: Простота, контроль со стороны системы мониторинга, легкая идентификация недоступных таргетов.
    *   *Минусы*: Требует доступа к сервисам из сети Prometheus, сложнее при динамической среде (решается через **Service Discovery** Kubernetes).

1. Push-модель (StatsD, Telegraf): Агенты отправляют метрики на центральный сервер (например, в VictoriaMetrics через /api/v1/import/prometheus или в Graphite).

    *   *Плюсы*: Гибкость для кратковременных задач (batch jobs), простота работы из изолированных сетей.
    *   *Минусы*: Риск потери данных при недоступности сервера, сложнее контролировать нагрузку на стороне сервера.

В современных гибридных средах часто применяется Pushgateway для задач, которые живут недолго, например, CronJobs:

# Пример отправки метрики из Job
echo "my_metric 42" | curl --data-binary @- http://pushgateway.monitoring:9091/metrics/job/my_job

Ключевые метрики для сбора (The Golden Signals)

• SLO/SLA метрики: Запросов в секунду, процент успешных ответов (5xx ошибки).
• Задержка (Latency): Время обработки запроса, перцентили (p95, p99).
• Нагрузка (Traffic): RPS, сетевой трафик, количество активных соединений.
• Ошибки (Errors): Количество исключений, failed health checks.
• Ресурсы (Saturation): Использование CPU (throttling), Memory (working set), Disk I/O.

Модернизация и облачные решения

Для крупных кластеров (тысячи нод) или мультикластерных сред стоит рассмотреть:

• Thanos или Cortex для глобального view, долгосрочного хранения и сжатия данных.
• Managed-сервисы от облачных провайдеров: Amazon Managed Service for Prometheus, Google Cloud Managed Service for Prometheus (часть Google Cloud Operations). Они снимают операционную нагрузку.
• OpenTelemetry Collector как унифицированный агент для сбора метрик (и трейсов, логов), который может перенаправлять данные в разные бэкенды.

Заключение

Эффективный сбор метрик требует продуманной архитектуры, соответствующей масштабу и требованиям бизнеса. Я начинаю с базового стека Prometheus Operator + Grafana, который покрывает 90% потребностей. Для этого устанавливаю kube-prometheus-stack через Helm. По мере роста добавляю долговременное хранилище (Thanos) и стандартизирую экспорт метрик из приложений с помощью библиотек клиентов Prometheus (для Go, Java, Python и др.). Важно не просто собирать данные, а настраивать осмысленные алерты на основе PrometheusRules и создавать информативные дашборды в Grafana, чтобы данные превращались в реальную операционную пользу и помогали поддерживать Service Level Objectives (SLO).