Замена Munin на современный мониторинг: сравнение систем для 300 серверов

Интернет-провайдер «ПровайдерНет» эксплуатировал Munin для мониторинга 300 серверов. Система работала на одном сервере с 4 ядрами и 8 GB RAM и генерировала графики через RRDtool. По мере роста инфраструктуры проблемы стали критичными:

• Время обновления графиков: 15-20 минут вместо штатных 5 — Munin не успевал обработать все ноды за один цикл
• Потребление ресурсов: CPU загружен на 95% постоянно, 6.5 GB RAM занято RRDtool
• Отсутствие алертинга: Munin умеет только подсвечивать warning/critical на графиках, но не отправляет уведомления
• Неудобный интерфейс: статические PNG-графики, невозможно выбрать произвольный временной диапазон
• Масштабируемость: добавление нового сервера требовало ручной правки конфигов и перезапуска

Руководство поставило задачу: выбрать современную систему мониторинга, мигрировать без потери наблюдаемости, настроить алертинг в Telegram и Slack.

Перед тем как тестировать системы, мы зафиксировали требования вместе с командой «ПровайдерНет»:

1. Метрики: не меньше, чем собирал Munin — CPU, RAM, disk, network, процессы, MySQL, Nginx, Postfix
2. Масштабируемость: 300 серверов сейчас, план до 500 через год
3. Алертинг: Telegram, Slack, email с группировкой по severity
4. Кастомные метрики: возможность написать плагин на bash для мониторинга специфичных сервисов
5. Один график — несколько серверов: сравнение метрик разных нод на одной панели
6. Ресурсы: агент не должен потреблять больше 50 MB RAM и 5% CPU на ноде
7. Хранение: минимум 12 месяцев истории с секундным разрешением за последнюю неделю
8. Open Source

Мы развернули тестовый стенд из 10 серверов и протестировали каждую систему в течение недели.

Nagios / Icinga 2

Nagios — ветеран мониторинга (с 1999 года), написан на C. Icinga 2 — его современный форк с улучшенным веб-интерфейсом и поддержкой MySQL/PostgreSQL/Oracle. Оба работают по принципу проверок (checks) и хорошо подходят для мониторинга доступности сервисов, но слабы в сборе и визуализации метрик. Конфигурация через текстовые файлы громоздкая:

# Nagios: определение хоста
define host {
    use             linux-server
    host_name       web-node-15
    alias           Web Node 15
    address         10.0.1.15
    max_check_attempts  5
    check_period    24x7
    notification_interval   30
    notification_period     24x7
}

define service {
    use                 generic-service
    host_name           web-node-15
    service_description CPU Load
    check_command       check_nrpe!check_load
}

Вердикт: отлично для алертов на доступность, но не замена Munin для метрик и графиков.

Zabbix

Полноценная платформа мониторинга: сбор метрик, визуализация, алертинг, discovery, карты сети. Ядро на C, веб-интерфейс на PHP, поддерживает MySQL/PostgreSQL. Мощная система шаблонов с автообнаружением сервисов:

# Установка Zabbix Agent 2 (Go)
apt install zabbix-agent2

# /etc/zabbix/zabbix_agent2.conf
Server=10.0.0.5
ServerActive=10.0.0.5
Hostname=web-node-15

# Кастомный UserParameter для мониторинга очереди Postfix
UserParameter=postfix.queue,find /var/spool/postfix/active -type f | wc -l

Минусы: тяжёлый веб-интерфейс (2-4 GB RAM на сервере Zabbix), сложная настройка для новичков, медленные дашборды при большом количестве элементов данных.

Prometheus + Grafana

Prometheus (Go) использует pull-модель — сам ходит к агентам за метриками. Встроенная TSDB, мощный язык запросов PromQL, интеграция с Kubernetes. Grafana — отдельный инструмент визуализации:

# Установка node_exporter на ноду
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
useradd -rs /bin/false node_exporter

# /etc/systemd/system/node_exporter.service
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=node_exporter
ExecStart=/usr/local/bin/node_exporter \
  --collector.systemd \
  --collector.processes \
  --web.listen-address=:9100

[Install]
WantedBy=multi-user.target

# prometheus.yml — конфигурация сбора
scrape_configs:
  - job_name: 'nodes'
    file_sd_configs:
      - files: ['/etc/prometheus/targets/*.yml']
    scrape_interval: 15s

Минусы: два отдельных продукта (Prometheus + Grafana), нет встроенного long-term storage (нужен Thanos или VictoriaMetrics).

Netdata

Написана на C, работает как агент на каждой ноде и предоставляет веб-интерфейс прямо на порту 19999. Собирает 2000+ метрик из коробки с секундным разрешением. Не требует внешней TSDB — хранит данные в RAM и на диске локально:

# Установка одной командой
bash <(curl -Ss https://my-netdata.io/kickstart.sh)

# Потребление: 30-50 MB RAM, < 2% CPU

Минусы: каждая нода — отдельный интерфейс (Netdata Cloud решает, но это SaaS), алертинг базовый.

Telegraf + InfluxDB + Grafana (TIG)

Весь стек на Go. Telegraf — универсальный агент с 300+ input-плагинами, InfluxDB — специализированная TSDB, Grafana — визуализация:

# Установка Telegraf
apt install telegraf

# /etc/telegraf/telegraf.conf (основные секции)
[agent]
  interval = "10s"
  flush_interval = "10s"
  hostname = "web-node-15"

[[outputs.influxdb_v2]]
  urls = ["http://10.0.0.5:8086"]
  token = "$INFLUX_TOKEN"
  organization = "providernet"
  bucket = "monitoring"

[[inputs.cpu]]
  percpu = true
  totalcpu = true

[[inputs.mem]]
[[inputs.disk]]
[[inputs.diskio]]
[[inputs.net]]
[[inputs.processes]]
[[inputs.system]]

# Мониторинг Nginx
[[inputs.nginx]]
  urls = ["http://127.0.0.1:8080/nginx_status"]

# Мониторинг MySQL
[[inputs.mysql]]
  servers = ["reader:password@tcp(127.0.0.1:3306)/"]

# Кастомная метрика через exec
[[inputs.exec]]
  commands = ["/opt/scripts/check_postfix_queue.sh"]
  data_format = "influx"
  interval = "30s"

Для «ПровайдерНет» мы выбрали стек Telegraf + InfluxDB + Grafana. Ключевые причины:

• Telegraf покрывает все метрики Munin и добавляет 300+ плагинов. Поддержка bash-скриптов через exec-плагин
• InfluxDB — специализированная TSDB мощнее RRDtool. Retention policies для автоматического прореживания старых данных
• Grafana — единый интерфейс, дашборды из коммьюнити, алертинг в Telegram/Slack/email
• Всё на Go — единый бинарник на каждый компонент, минимальные зависимости, простое обновление

Prometheus мы не выбрали из-за отсутствия встроенного long-term storage (для 300 серверов с 12-месячной историей нужен Thanos/Cortex — дополнительная сложность). Zabbix отпал из-за тяжеловесности PHP-интерфейса и высокого потребления ресурсов на сервере.

Серверную часть (InfluxDB + Grafana) мы развернули на выделенном сервере с 8 ядрами и 32 GB RAM:

# InfluxDB 2.x
curl -sL https://repos.influxdata.com/influxdata-archive.key | gpg --dearmor -o /usr/share/keyrings/influxdb-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/influxdb-archive-keyring.gpg] https://repos.influxdata.com/debian stable main" > /etc/apt/sources.list.d/influxdb.list
apt update && apt install influxdb2

# Настройка retention policies
influx bucket create -n monitoring -o providernet -r 8760h  # 12 месяцев
influx bucket create -n monitoring-downsampled -o providernet -r 26280h  # 3 года

# InfluxDB Task для прореживания старых данных (из 10s в 5m)
# Выполняется автоматически каждый час
option task = {name: "downsample_cpu", every: 1h}
from(bucket: "monitoring")
  |> range(start: -2h)
  |> filter(fn: (r) => r._measurement == "cpu")
  |> aggregateWindow(every: 5m, fn: mean)
  |> to(bucket: "monitoring-downsampled")

Раскатку Telegraf на 300 серверов мы автоматизировали через Ansible:

# ansible/roles/telegraf/tasks/main.yml
- name: Install Telegraf
  apt:
    name: telegraf
    state: latest
    update_cache: yes

- name: Deploy Telegraf config
  template:
    src: telegraf.conf.j2
    dest: /etc/telegraf/telegraf.conf
    owner: telegraf
    group: telegraf
    mode: '0640'
  notify: Restart Telegraf

- name: Deploy custom scripts
  copy:
    src: "{{ item }}"
    dest: /opt/telegraf-scripts/
    mode: '0755'
  loop:
    - check_postfix_queue.sh
    - check_ssl_expiry.sh
    - check_disk_health.sh

# Раскатка:
ansible-playbook -i inventory/production site.yml --tags telegraf

Алертинг настроили через Grafana с маршрутизацией по severity:

# Grafana alerting — пример правила для CPU
# Настраивается через UI или provisioning YAML:
apiVersion: 1
groups:
  - orgId: 1
    name: Infrastructure
    folder: Alerts
    interval: 1m
    rules:
      - uid: cpu-high
        title: "CPU Usage > 90%"
        condition: C
        data:
          - refId: A
            datasourceUid: influxdb
            model:
              query: |
                from(bucket:"monitoring")
                  |> range(start: -5m)
                  |> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage_idle" and r.cpu == "cpu-total")
                  |> mean()
                  |> map(fn: (r) => ({r with _value: 100.0 - r._value}))
          - refId: C
            datasourceUid: "-100"
            model:
              type: threshold
              conditions:
                - evaluator: {type: gt, params: [90]}
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage is {{ $values.A }}% on {{ $labels.host }}"

Контакт-поинты:

• Critical (disk full, service down) → Telegram группа дежурных + SMS
• Warning (CPU > 90%, RAM > 85%) → Telegram канал мониторинга
• Info (SSL-сертификат истекает через 14 дней) → email ответственным

Миграция с Munin заняла 3 недели: первая неделя — развёртывание TIG параллельно с Munin, вторая — перенос кастомных плагинов и настройка дашбордов, третья — валидация данных и отключение Munin. Ни одного пропуска алертов за время миграции.

Через месяц работы TIG-стека на 300 серверах:

Главный эффект — команда «ПровайдерНет» стала реагировать на инциденты проактивно. Раньше узнавали о проблемах от клиентов, теперь — из Telegram за минуту до того, как проблема станет заметной. Если вам нужна помощь с настройкой мониторинга — обращайтесь в ITFresh.