Мониторинг: как не следить за системой, а управлять ею

Мониторинг — это не просто набор дашбордов с графиками и алертами. Это система, которая должна работать на команду, а не наоборот. Если ваш мониторинг требует постоянного ручного вмешательства, генерирует тысячи ложных тревог или просто лежит без дела, значит, он плохо спроектирован. В этой статье разберёмся, как сделать мониторинг рабочим инструментом, а не декорацией для дата-центра.

Проблема: зачем мониторинг, если всё работает?

Представьте ситуацию: у вас есть сервис, который стабильно работает годами. Никаких инцидентов, клиенты довольны, а команда спит спокойно. Вопрос: нужен ли мониторинг в этом случае?

Да, нужен. Но не тот, который вы, вероятно, себе представляете.

Реальная ценность мониторинга проявляется не тогда, когда система падает, а когда она начинает медленно деградировать. Например:

  • Латенси запросов растёт на 10% в неделю из-за утечки памяти в одном из микросервисов.
  • Дисковое пространство на базе данных сокращается из-за неудаленной старых логов.
  • Один из реплик сервиса начинает отставать, но никто этого не замечает, пока не произойдёт разрыв репликации.

Мониторинг должен отвечать на вопросы:

  1. Что происходит сейчас? (текущее состояние системы)
  2. Что изменилось? (тренды, аномалии)
  3. Что скоро сломается? (предсказательная аналитика)
  4. Что уже сломалось? (постфактум-анализ для постмортема)

Если ваш мониторинг не даёт ответы хотя бы на первые два вопроса — он бесполезен.

Практика: как не сделать мониторинг мусором

1. Начинайте с минимальной жизнеспособной конфигурации (MVP)

Не нужно сразу настраивать мониторинг для всех возможных метрик. Начните с критических путей и ключевых бизнес-метрик. Например:

  • Для веб-сервиса: HTTP-статусы (2xx, 5xx), латенси, количество запросов в секунду.
  • Для базы данных: количество подключений, использование CPU, время ответа на запросы.
  • Для кэша: hit/miss ratio, количество выброшенных объектов.

Пример конфигурации Prometheus для веб-сервиса (фрагмент):

scrape_configs:
  - job_name: 'web_service'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['web-1:8080', 'web-2:8080']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

2. Автоматизируйте всё, что можно

Ручная настройка метрик, ручное добавление хостов, ручное создание дашбордов — это путь к хаосу. Используйте:

  • Автоматическое обнаружение (например, kube-state-metrics для Kubernetes).
  • Темплейты для дашбордов (Grafana позволяет сохранять шаблоны для разных типов сервисов).
  • CI/CD для конфигов (храните конфигурации мониторинга в репозитории и провайдите их вместе с кодом).

Пример использования kube-state-metrics для автоматического сбора метрик о подах:

apiVersion: v1
kind: Service
metadata:
  name: kube-state-metrics
  labels:
    app: kube-state-metrics
spec:
  ports:
  - name: http-metrics
    port: 8080
    targetPort: http-metrics
  selector:
    app: kube-state-metrics

3. Настройте умные алерты, а не ловушки для стресса

Ложные тревоги — враг номер один в мониторинге. Правильные алерты должны:

  • Быть специфичными (не "CPU > 90%", а "CPU > 95% на хосте X в течение 5 минут").
  • Иметь контекст (например, алерт на "высокий латенси API" должен включать пример запроса, который тормозит).
  • Не дублировать друг друга (если у вас есть алерт на "диск заполнен на 90%", не нужно отдельный на "диск заполнен на 95%").

Пример конфигурации алерта в Prometheus (Alertmanager):

groups:
- name: disk-alerts
  rules:
  - alert: HighDiskUsage
    expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "High disk usage on {{ $labels.instance }}"
      description: "Disk is {{ printf \"%.2f\" $value }}% full (threshold: 10%)"

Типичные ошибки и как их избежать

  1. Слишком много метрик, слишком мало смысла

    • Ошибка: Собираете все возможные метрики "на всякий случай".
    • Решение: Начните с 5-10 ключевых метрик на сервис. Добавьте остальные только если они действительно помогают в диагностике.

  2. Алерты без контекста

    • Ошибка: Алерт "CPU > 90%" без указания, какой именно процесс его потребляет.
    • Решение: Используйте аннотации с деталями (например, PID процесса, запрос, который тормозит).

  3. Мониторинг только инфраструктуры, игнорирование бизнес-метрик

    • Ошибка: Отслеживаете только CPU, RAM, диск, но не смотрите на конверсию, доход на пользователя, время ответа с точки зрения клиента.
    • Решение: Включите в мониторинг метрики, которые важны для бизнеса (например, user_drop_rate для веб-сервиса).

  4. Отсутствие архивации и анализа истории

    • Ошибка: Метрики хранятся только в реальном времени, нет возможности анализировать тренды.
    • Решение: Настройте долговременное хранение (например, в InfluxDB или TimescaleDB) и используйте его для поиска причин инцидентов.

  5. Мониторинг как "черный ящик"

    • Ошибка: Команда не понимает, как работают алерты и метрики, боится их настраивать.
    • Решение: Проведите обучение, напишите документацию с примерами, покажите, как использовать мониторинг для решения реальных проблем.

Пример: как мы настраивали мониторинг для микросервисной архитектуры

У нас была проблема: после миграции на Kubernetes мониторинг стал слишком шумным — тысячи метрик, алерты на каждую мелочь. Мы сделали следующее:

  1. Сгруппировали сервисы по функциональности (например, "API-шлюз", "базы данных", "кэш").
  2. Создали унифицированные дашборды для каждого типа сервиса (шаблон Grafana для Node.js, для Go, для Python).
  3. Настроили алерты только на критическое:
    • Падение сервиса (статус 5xx > 1% от запросов).
    • Высокая латенси (P99 > 1с для API).
    • Заполнение диска/памяти > 90%.
  4. Добавили бизнес-метрики:
    • Количество ошибок авторизации (для безопасности).
    • Время обработки платежей (для финансовых сервисов).
  5. Автоматизировали добавление новых сервисов:
    • При деплое нового пода в Kubernetes автоматически добавляются метрики и алерты через Prometheus Operator.

Результат:

  • Количество ложных тревог упало с 500 в месяц до 10.
  • Время реагирования на инциденты сократилось с 30 минут до 5.
  • Команда перестала бояться настраивать новые алерты.

Вывод: мониторинг — это не цель, а средство

Хороший мониторинг — это не набор инструментов, а система, которая помогает команде принимать обоснованные решения. Он должен:

  1. Предотвращать проблемы до того, как они произойдут (тренды, предиктивные алерты).
  2. Объяснять, что пошло не так (контекстные данные в алертах).
  3. Ускорять реагирование (автоматизация, быстрый доступ к данным).
  4. Упрощать жизнь команде (не добавлять рутинную работу).

Что делать прямо сейчас?

  1. Пройдитесь по своим сервисам и выберите 5 ключевых метрик для каждого.
  2. Настройте один умный алерт (не "CPU высокий", а "CPU высокий на хосте X из-за процесса Y").
  3. Создайте один дашборд, который показывает состояние всей системы на одном экране.
  4. Автоматизируйте добавление новых метрик при деплое новых сервисов.

Мониторинг — это не роскошь, а необходимость. Но только если он правильно настроен.