Мониторинг Debian-сервера: Prometheus, node_exporter, Grafana за одно утро

Здравствуйте! Я Евгений Семёнов, директор ITFresh. Знаете, что такое сервер без приличного мониторинга? Это как бомба с часовым механизмом. Неужели вы хотите, чтобы о проблемах первой узнала ваша служба поддержки, когда телефоны уже раскалены добела? Диск может отказать, OOM-киллер не справится, а swap просто исчезнет – и вы об этом не узнаете, пока не станет совсем поздно. У нас в ITFresh есть железное правило: любой Debian-сервер, который мы запускаем в работу, сразу же, в первый день, получает полный комплект. Это Prometheus, node_exporter, Grafana и Alertmanager. Туда же входят Telegram-уведомления и пара готовых дашбордов. Сейчас я покажу, как мы это делаем.

Архитектура стека

И никаких сюрпризов! Мы ставим всё исключительно из стандартных репозиториев Debian 12. Это гарантия максимальной простоты и надёжности.

Установка node_exporter на всех серверах

# На каждом сервере, который хотите мониторить
apt update
apt install -y prometheus-node-exporter

systemctl enable --now prometheus-node-exporter
ss -lntup | grep 9100
# Метрики: curl http://localhost:9100/metrics | head

Рекомендую закрыть порт 9100 от внешнего мира: либо через iptables/nftables, либо слушать только на внутреннем интерфейсе (директива --web.listen-address=10.0.0.5:9100).

Установка сервера Prometheus

# Отдельный сервер мониторинга
apt install -y prometheus prometheus-alertmanager

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

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

rule_files:
  - "/etc/prometheus/rules.d/*.yml"

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node'
    static_configs:
      - targets:
          - web01.corp.example.ru:9100
          - web02.corp.example.ru:9100
          - db01.corp.example.ru:9100
          - backup.corp.example.ru:9100
        labels:
          env: production

  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
          - https://corp.example.ru
          - https://mail.corp.example.ru
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115

systemctl restart prometheus
systemctl restart prometheus-alertmanager

Правила алертов

# /etc/prometheus/rules.d/node.yml
groups:
  - name: node_health
    interval: 30s
    rules:
      - alert: NodeDown
        expr: up{job="node"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Сервер {{ $labels.instance }} недоступен"

      - alert: DiskSpaceLow
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|squashfs"} / node_filesystem_size_bytes{fstype!~"tmpfs|squashfs"}) < 0.1
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "На {{ $labels.instance }} диск {{ $labels.mountpoint }} меньше 10%"

      - alert: HighCPU
        expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "CPU {{ $labels.instance }} > 90% более 15 минут"

      - alert: MemoryLow
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.1
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "RAM {{ $labels.instance }} меньше 10% свободно"

      - alert: RaidDegraded
        expr: node_md_disks_required - node_md_disks{state="active"} > 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "RAID на {{ $labels.instance }} деградирован"

promtool check rules /etc/prometheus/rules.d/*.yml
systemctl reload prometheus

Alertmanager с Telegram

# /etc/prometheus/alertmanager.yml
route:
  receiver: 'telegram'
  group_by: [alertname, instance]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  routes:
    - receiver: 'telegram-critical'
      match:
        severity: critical
      repeat_interval: 30m

receivers:
  - name: 'telegram'
    webhook_configs:
      - url: 'http://localhost:8080/alert/warn'

  - name: 'telegram-critical'
    webhook_configs:
      - url: 'http://localhost:8080/alert/crit'

# Проверка и перезапуск
amtool check-config /etc/prometheus/alertmanager.yml
systemctl restart prometheus-alertmanager

Промежуточный webhook-сервис: минимальный Go-бот alertmanager-telegram или свой. Структура POST-а от Alertmanager — JSON, шлём в Bot API.

Grafana и дашборды

# Репозиторий Grafana
apt install -y apt-transport-https software-properties-common
wget -q -O - https://apt.grafana.com/gpg.key | apt-key add -
echo "deb https://apt.grafana.com stable main" > /etc/apt/sources.list.d/grafana.list
apt update
apt install -y grafana
systemctl enable --now grafana-server
# http://сервер:3000  admin/admin

После входа:

1. Вот как это настроить: заходим в Configuration, затем Data sources, нажимаем Add. Выбираем Prometheus, указываем `http://localhost:9090`. Всё, жмём Save&Test!
2. Чтобы получить полную картину: идём в Dashboards, выбираем Import. Вбиваем ID 1860 — это наш Node Exporter Full, дашборд с десятками полезных панелей. Просто, правда?
3. А для внешних проверок (probe) возьмите ID 7587. Загружаем Dashboards → Import → ID 7587 (Blackbox) — и готово.
4. Не забудьте настроить оповещения: в разделе Alerts перейдите в Contact points. Там вы сможете добавить Telegram или email для всех критичных сообщений.

Reinforce mit blackbox_exporter

apt install -y prometheus-blackbox-exporter

# /etc/prometheus/blackbox.yml (обычно работает из коробки)
# Перезапуск: systemctl restart prometheus-blackbox-exporter

# Проверка
curl 'http://localhost:9115/probe?target=https://corp.example.ru&module=http_2xx'

Знаете, как бывает? Настроил blackbox_exporter и просто забыл о нём. Он умеет проверять HTTP(S), ICMP, TCP, DNS, и даже SSH-probe. Обычно я добавляю 10-15 важнейших целей: это главные сайты наших клиентов, 25-й почтовый порт, 3389 для RDP, а также все DNS-серверы. Это реально выручает.

Service discovery для большого парка

Но что делать, если у вас не 5, а 50+ хостов? Ручное добавление IP-адресов в `static_configs` быстро превратится в сущий ад. Вот какие есть варианты:

• file_sd_configs — JSON-файл, генерируемый Ansible/Terraform.
• consul_sd_configs — динамическая регистрация через Consul.
• dns_sd_configs — SRV-записи в DNS.

scrape_configs:
  - job_name: 'node'
    file_sd_configs:
      - files:
          - /etc/prometheus/targets/node-*.json
        refresh_interval: 30s

# /etc/prometheus/targets/node-prod.json
[
  {
    "targets": ["web01:9100", "web02:9100"],
    "labels": {"env": "production", "role": "web"}
  },
  {
    "targets": ["db01:9100"],
    "labels": {"env": "production", "role": "db"}
  }
]

Реальный кейс: мониторинг на 60 серверов за один день

Возьмём реальный кейс: в марте 2025 года к нам обратилась одна торговая компания из ЮВАО Москвы. У них было 60 серверов, смесь Debian и Ubuntu. Мониторинг работал на старых Cacti/Nagios, но с огромными пробелами: админы просто перестали доверять алертам из-за кучи ложных срабатываний. Наша задача? Заменить всё это за один-единственный рабочий день на полностью современный стек с централизованной панелью управления и, конечно, Telegram-алертами.

Наш план действий был максимально чётким. Утром, сразу с началом рабочего дня, мы раскатали `node_exporter` с помощью нашего Ansible-плейбука. И знаете что? На все 60 серверов ушло каких-то 30 минут! К обеду мы уже успели поднять сам Prometheus, Alertmanager и Grafana на нашей мощной виртуалке Dell Xeon Platinum 8280, которая находится в дата-центре МТС Москва. Ну а после обеда оставалось только настроить дашборды, прописать нужные правила и, конечно, подключить Telegram-бота.

И что вы думаете? Уже к 18:30 того же дня вся система была в строю и работала как часы! А что самое интересное: за первые же сутки мы получили сразу два реально важных алерта. На одном сервере раздел `/var` оказался забит на 96%, а на файлохранилище внезапно обнаружилась деградация RAID – как выяснилось, один диск выпал ещё неделю назад, но предыдущий мониторинг этого просто не заметил. За всю эту работу мы взяли 34 000 рублей.

Лучшие практики из многолетнего опыта

• Крайне важно добавлять метки `env`, `role`, `team` к каждой job! Без них ваши PromQL-запросы очень быстро превратятся в настоящий кошмар, разобраться в котором будет почти нереально.
• Помните: 'alert fatigue' — наш главный враг. Не пытайтесь запустить сразу 150 правил! Начните с 10-15, самых важных. Остальные добавляйте постепенно, по мере возникновения реальных потребностей.
• Наш подход к хранению данных такой: Retention в Prometheus выставляем на 15 дней. А для долгосрочного хранения используем `remote_write` в Victoria Metrics — там данные хранятся целый год.
• Забудьте про хранение дашбордов Grafana в базе данных! Мы в ITFresh всегда настаиваем: используйте Git-провижининг. Это значит, что все ваши драгоценные дашборды будут жить прямо в Git-репозитории, а не где-то там в БД. Разве не удобнее управлять ими, как обычным кодом?
• Сервер мониторинга? Ему не место рядом с боевыми приложениями! Мы всегда подчеркиваем: он должен быть отдельным. Представьте ситуацию: прод-приложение падает, и из-за этого умирает ваш мониторинг. Вы даже не узнаете, что произошло! Выделите отдельный сервер — это обеспечит стабильность и независимость вашей системы наблюдения.
• Раз уж речь зашла о бэкапах, то вот что точно нужно сохранять: обязательно копируйте `/etc/prometheus` – там все ваши конфигурации. Не забудьте про данные Prometheus в `/var/lib/prometheus`; если у вас есть возможность, лучше всего сделать snapshot этого раздела. И, конечно же, `/var/lib/grafana` – там все ваши дашборды, пользователи и настройки. Иначе при восстановлении придётся рисовать всё заново, а это никому не хочется, правда?
• HTTPS и аутентификация для Grafana? Это не опции, которые можно отложить на потом! Настраивайте их с первого дня запуска, без компромиссов. Вы же не хотите, чтобы ваши ценные метрики и графики оказались доступны кому угодно, или чтобы кто-то чужой мог зайти и что-то изменить? Безопасность — это не головная боль, это фундамент. Сделайте это сразу и спите спокойно.

FAQ — вопросы о мониторинге Debian

На каком Debian работает стек?

Debian 11/12 и Ubuntu 20.04+. Пакеты доступны в apt или через официальные репозитории.

Сколько ресурсов нужно Prometheus-серверу?

На 50-100 хостов — 2 vCPU, 4 ГБ RAM, 100 ГБ SSD. Рост хранилища ~1-2 ГБ/мес на 100 метрик.

Prometheus подходит для долгосрочного хранения?

Стандартно 15 дней. Для годов — Victoria Metrics, Thanos или Mimir через remote_write.

Как передавать алерты в Telegram?

Через Alertmanager webhook_configs и промежуточный бот-прокси (alertmanager-telegram-bot).

Что лучше для Debian: Prometheus или Checkmk/Zabbix?

Зависит от задач. Для простого инфраструктурного — Checkmk. Для приложений и кастомных метрик — Prometheus.