Как бы вы настроили мониторинг для 200 серверов?

«Как бы вы настроили мониторинг для 200 серверов?» — вопрос из категории Мониторинг и логирование, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Для мониторинга парка из 200 серверов я бы развернул отказоустойчивый стек на основе Prometheus, Grafana и Alertmanager, используя автоматическое обнаружение целей (service discovery).

Архитектура решения:

  1. Агенты сбора (Node Exporter): Установил бы node_exporter на каждый сервер для сбора системных метрик (CPU, memory, disk, network). Для автоматизации использовал бы Ansible или систему управления конфигурациями.

  2. Сбор метрик (Prometheus): Развернул бы кластер Prometheus (2+ инстанса) для надежности. Вместо статического списка в prometheus.yml использовал бы service discovery (например, через файлы, Consul или облачные провайдеры).

    # prometheus.yml - пример с файловым SD
    scrape_configs:
      - job_name: 'node'
        file_sd_configs:
          - files:
            - '/etc/prometheus/targets/nodes*.json'

    Файл /etc/prometheus/targets/nodes.json динамически обновлялся бы скриптом или системой инвентаризации.

  3. Визуализация (Grafana): Настроил бы Grafana с дашбордами для инфраструктуры (например, "Node Exporter Full") и бизнес-метрик. Источник данных — Prometheus.

  4. Оповещения (Alertmanager): Настроил бы Alertmanager для группировки и маршрутизации алертов в Slack, Telegram, PagerDuty или Opsgenie. Пример правила в Prometheus:

    groups:
      - name: node_alerts
        rules:
        - alert: HighMemoryUsage
          expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "High memory usage on {{ $labels.instance }}"
  5. Долгосрочное хранение и масштабирование: Для долгосрочного хранения метрик и обработки нагрузки добавил бы VictoriaMetrics или Thanos (Sidecar + Query).

  6. Логирование: Параллельно развернул бы стек для логов EFK (Elasticsearch, Fluentd/Fluent Bit, Kibana) или Loki (более легковесный). Агент Fluent Bit собирал бы логи с серверов и отправлял в центральное хранилище.

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