Какие вы знаете модели мониторинга и в чем их ключевые различия?

В DevOps мы используем несколько взаимодополняющих моделей мониторинга, каждая из которых отвечает на свой круг вопросов.

1. Blackbox (мониторинг "снаружи") vs Whitebox (мониторинг "изнутри"): Это основное концептуальное разделение.

• Blackbox мониторинг:

  • Что это: Проверка работы сервиса с точки зрения внешнего пользователя или зависимой системы. Не требует знания внутреннего устройства.
  • Что отслеживает: Доступность (HTTP 200 OK), корректность ответа (наличие ключевых слов в HTML), время отклика, работа TCP-портов, DNS-запросы.
  • Инструменты: Prometheus Blackbox Exporter, Synthetic monitoring в Grafana Cloud/CloudWatch, Pingdom.
  • Пример конфигурации Blackbox Exporter для Prometheus:

    # prometheus.yml
    scrape_configs:
      - job_name: 'blackbox-http'
        metrics_path: /probe
        params:
          module: [http_2xx]
        static_configs:
          - targets:
            - https://api.example.com/health
            - https://frontend.example.com
        relabel_configs:
          - source_labels: [__address__]
            target_label: __param_target
          - source_labels: [__param_target]
            target_label: instance
          - target_label: __address__
            replacement: blackbox-exporter:9115

• Whitebox мониторинг:

  • Что это: Глубокий мониторинг внутреннего состояния приложения и инфраструктуры. Требует инструментации кода или установки агентов.
  • Что отслеживает: Метрики приложения (количество запросов, ошибок, тайминги бизнес-логики), метрики системы (CPU, память, диск, сеть), метрики рантайма (JVM heap, Go goroutines).
  • Инструменты: Prometheus Node Exporter, клиентские библиотеки (Prometheus, OpenTelemetry), JMX Exporter для Java.

2. Pull vs Push модели сбора метрик:

• Pull (Вытягивание): Сервер мониторинга сам опрашивает (scrape) цели по HTTP. Пример: Prometheus.

  • Плюсы: Централизованное управление тем, что и как часто собирать; простота отладки (можно вручную запросить /metrics).
  • Минусы: Требует сетевой доступности цели от сервера мониторинга; сложнее для кратковременных задач (например, CI/CD джоб).

• Push (Отправка): Агенты или приложения сами отправляют метрики на сервер. Пример: StatsD, InfluxDB Telegraf, CloudWatch Agent.

  • Плюсы: Работает из-за NAT/firewall; подходит для задач с коротким временем жизни.
  • Минусы: Может потерять данные при недоступности сервера; требует больше конфигурации на стороне агента.

3. Метрики (Metrics) vs Логи (Logs) vs Трейсы (Traces): Три столпа observability.

Итог: Эффективная система observability строится на комбинации Blackbox (здоров ли сервис?) и Whitebox (почему он медленный?), используя метрики для алертинга и дашбордов, логи для детального расследования и трейсы для анализа производительности в микросервисных архитектурах.