Построение стека мониторинга от htop до Grafana

Хостинг-провайдер «ХостМастер» эксплуатирует 150 серверов в двух дата-центрах Москвы и обслуживает более 3000 клиентских проектов. До обращения к нам мониторинг состоял из самописного bash-скрипта, который раз в 5 минут проверял доступность серверов по ping и отправлял SMS при недоступности.

Проблемы были системными:

• Реактивный подход — о проблемах узнавали от клиентов, а не от системы мониторинга. Среднее время обнаружения инцидента: 23 минуты.
• Отсутствие метрик — не было данных о CPU, RAM, диске, сети. Администраторы подключались по SSH и запускали top вручную.
• Нет истории — невозможно выяснить, что происходило на сервере вчера в 3 часа ночи, когда клиент жаловался на тормоза.
• Слепые зоны — дисковый I/O и сетевой трафик не мониторились вообще.

Руководство «ХостМастер» поставило задачу: за 4 недели внедрить комплексный мониторинг, который позволит выявлять проблемы до того, как пострадают клиенты.

Первым делом мы стандартизировали набор CLI-утилит на всех 150 серверах. Администратор, подключившийся к серверу по SSH, должен иметь под рукой правильные инструменты для быстрой диагностики.

Мы подготовили Ansible-роль, которая устанавливает и настраивает набор утилит:

# Установка полного набора диагностических утилит
apt install -y htop atop iotop iftop sysstat dstat nethogs nmon glances

# Настройка atop для записи истории каждые 10 минут
systemctl enable atop
sed -i 's/INTERVAL=600/INTERVAL=300/' /etc/default/atop
systemctl restart atop

Для глубокой диагностики конкретных подсистем мы внедрили специализированные инструменты:

# iotop — кто нагружает диск
# Показывает потребление дискового I/O по процессам
sudo iotop -oa
# -o — только процессы с активным I/O
# -a — накопительный счётчик (кто больше всего записал за сессию)

# Типичный вывод:
# PID   USER      DISK READ  DISK WRITE  COMMAND
# 1842  mysql     12.5 MB/s  45.2 MB/s   mysqld
# 943   www-data  0.00 B/s   2.1 MB/s    php-fpm
# 128   root      156 KB/s   0.00 B/s    [jbd2/sda3-8]

# iftop — кто нагружает сеть (требует root)
sudo iftop -i eth0 -n
# -i — интерфейс
# -n — не резолвить DNS (быстрее)

# Показывает пары IP-адресов и объём трафика между ними
# Позволяет быстро обнаружить, кто "ест" полосу

# nethogs — сетевой трафик по процессам
sudo nethogs eth0

# В отличие от iftop, показывает ПРОЦЕССЫ, а не IP-пары
# PID    USER    PROGRAM                    DEV    SENT      RECEIVED
# 2845   nginx   /usr/sbin/nginx            eth0   45.2 MB   12.8 MB
# 1842   mysql   /usr/sbin/mysqld           eth0   8.5 MB    22.1 MB

Мы составили «книгу рецептов» из 15 типичных сценариев диагностики: «сервер тормозит», «кончается диск», «высокий load average при низком CPU» и т.д. Для каждого сценария — последовательность команд и интерпретация результатов.

CLI-утилиты незаменимы для диагностики «здесь и сейчас», но для полноценного мониторинга 150 серверов нужна централизованная система сбора метрик. Мы выбрали Prometheus — стандарт отрасли для метрик.

На каждый сервер мы установили Node Exporter через Ansible:

# Ansible-роль для Node Exporter
- name: Установка Node Exporter
  block:
    - name: Скачиваем Node Exporter
      get_url:
        url: "https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz"
        dest: /tmp/node_exporter.tar.gz

    - name: Распаковываем
      unarchive:
        src: /tmp/node_exporter.tar.gz
        dest: /usr/local/bin/
        remote_src: yes
        extra_opts: [--strip-components=1]

    - name: Создаём systemd-сервис
      copy:
        dest: /etc/systemd/system/node_exporter.service
        content: |
          [Unit]
          Description=Prometheus Node Exporter
          After=network.target

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

          [Install]
          WantedBy=multi-user.target

    - name: Запускаем
      systemd:
        name: node_exporter
        state: started
        enabled: yes

Конфигурация Prometheus-сервера для сбора метрик со всех 150 серверов:

# /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

scrape_configs:
  - job_name: 'nodes'
    file_sd_configs:
      - files:
          - '/etc/prometheus/targets/*.yml'
        refresh_interval: 5m

  # Автоматическое обнаружение через файлы
  # /etc/prometheus/targets/dc1.yml:
  # - targets:
  #     - 'srv-01.dc1:9100'
  #     - 'srv-02.dc1:9100'
  #   labels:
  #     datacenter: 'dc1'
  #     role: 'web'

Визуализация метрик — через Grafana. Мы создали четыре уровня дашбордов:

1. Overview Dashboard — общая картина по всем 150 серверам на одном экране. Цветовая кодировка: зелёный (норма), жёлтый (предупреждение), красный (критично). Руководство и дежурный инженер видят состояние всей инфраструктуры одним взглядом.

2. Server Dashboard — детальные метрики одного сервера: CPU по ядрам, RAM (used/cached/buffers), дисковые I/O (IOPS, throughput, latency), сетевой трафик (in/out по интерфейсам), файловые системы (процент заполнения).

3. Service Dashboard — метрики сервисов: Nginx (requests/s, error rate, response time), PostgreSQL (QPS, connections, cache hit ratio), PHP-FPM (active workers, queue length).

4. Capacity Planning Dashboard — тренды за 30/90/365 дней. Прогноз заполнения дисков, рост потребления RAM, динамика нагрузки. Позволяет планировать закупку оборудования заблаговременно.

Пример PromQL-запроса для дашборда:

# CPU usage по серверу (исключая idle и iowait)
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# RAM usage в процентах
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Disk I/O utilization (процент времени, когда диск занят)
rate(node_disk_io_time_seconds_total[5m]) * 100

# Network traffic (Мбит/с)
rate(node_network_receive_bytes_total{device="eth0"}[5m]) * 8 / 1024 / 1024

# Прогноз заполнения диска (дней до 90%)
(node_filesystem_avail_bytes{mountpoint="/"} / (node_filesystem_size_bytes{mountpoint="/"} * 0.1))
/ (deriv(node_filesystem_avail_bytes{mountpoint="/"}[7d]) * -1) / 86400

Мониторинг без алертинга — это просто красивые графики. Мы настроили трёхуровневую систему оповещений через Alertmanager:

# /etc/prometheus/alerts/node_alerts.yml
groups:
  - name: node_alerts
    rules:
      # CRITICAL: Сервер недоступен
      - alert: NodeDown
        expr: up == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Сервер {{ $labels.instance }} недоступен"
          description: "Node Exporter не отвечает более 2 минут."

      # WARNING: Высокая загрузка CPU
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU на {{ $labels.instance }} выше 85%"
          description: "Текущая загрузка: {{ $value | humanize }}%"

      # CRITICAL: Диск заполнен на 90%+
      - alert: DiskSpaceCritical
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Диск на {{ $labels.instance }} заполнен на {{ $value | humanize }}%"

      # WARNING: RAM usage > 90%
      - alert: HighMemoryUsage
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 90
        for: 10m
        labels:
          severity: warning

      # WARNING: Диск заполнится через 7 дней
      - alert: DiskWillFillIn7Days
        expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[7d], 7 * 86400) < 0
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "Диск на {{ $labels.instance }} заполнится через ~7 дней"

Маршрутизация алертов: критические уходят в Telegram дежурному с звуковым уведомлением, предупреждения — в общий канал команды, информационные — агрегируются в ежедневном дайджесте. Подробнее о нашем подходе к мониторингу читайте на itfresh.ru.

По итогам проекта мы составили матрицу применимости инструментов, которая стала частью внутренней документации «ХостМастер»:

Проект был завершён за 3.5 недели. Вот измеримые результаты за первые 2 месяца эксплуатации:

Самым ценным оказался алерт DiskWillFillIn7Days — предиктивное оповещение о заполнении диска. За 2 месяца он сработал 14 раз, и каждый раз администраторы успевали решить проблему до того, как она затронула клиентов. Стоимость проекта: 1.4 млн рублей, включая лицензии, внедрение и обучение команды из 6 администраторов.