Мониторинг сервера: какие метрики отслеживать и как настроить оповещения

Мониторинг сервера полезен тогда, когда по нему можно ответить на два вопроса: что именно ухудшилось и нужно ли действовать сейчас. Один график загрузки процессора эту задачу не решает. Сервер может иметь свободный CPU и одновременно перестать отдавать сайт, заполнить файловую систему, потерять доступ к базе данных или исчерпать память.

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

Для Linux удобная базовая схема выглядит так: node_exporter снимает системные метрики, Prometheus регулярно их собирает и проверяет правила, а Alertmanager группирует сработавшие события и отправляет уведомления. node_exporter предназначен именно для аппаратных и системных метрик Unix-подобных систем; в официальном руководстве среди примеров есть CPU, файловые системы и сеть.

Какие метрики мониторинга сервера действительно нужны

Не стоит начинать с сотен графиков. Для одного VPS или выделенного Linux-сервера сначала достаточно нескольких сигналов, каждый из которых отвечает на конкретный эксплуатационный вопрос.

Последняя проверка принципиальна. Работоспособность node_exporter подтверждает, что Prometheus видит сервер, но не доказывает, что посетителю открывается сайт. Для внешней проверки HTTP в экосистеме Prometheus используется, например, Blackbox Exporter: он способен отдельно фиксировать успешность probe, время запроса, HTTP-состояние и параметры TLS.

load average тоже полезен, но его нельзя автоматически трактовать как «процент загрузки процессора». Значение нужно сопоставлять с количеством CPU и другими показателями. Аналогично высокая занятость RAM сама по себе не означает проблему: для Linux практичнее смотреть доступную память и реальные признаки давления, а не требовать большого значения free.

Как собрать минимальный контур мониторинга сервера

Предположим, Prometheus и Alertmanager находятся на отдельном внутреннем узле, а контролируемый веб-сервер имеет приватный адрес 10.0.0.15.

На веб-сервере запускается node_exporter. По умолчанию он слушает порт 9100. Проверить, что endpoint действительно отдаёт метрики, можно локально:

wget -qO- http://127.0.0.1:9100/metrics | head

Если Prometheus расположен на другой машине, endpoint должен быть доступен ему по внутренней сети, VPN или другому защищённому каналу. Открывать 9100 всему интернету только ради удобства настройки не нужно.

В конфигурации Prometheus достаточно добавить файл правил, сервер Alertmanager и scrape-задачу:

global:
  scrape_interval: 30s
  evaluation_interval: 30s

rule_files:
  - /etc/prometheus/alerts.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "127.0.0.1:9093"

scrape_configs:
  - job_name: "node"
    static_configs:
      - targets:
          - "10.0.0.15:9100"
        labels:
          role: "web"

Prometheus поддерживает глобальный scrape_interval, отдельные scrape-конфигурации, rule_files и явное подключение Alertmanager. Интервал 30s здесь — не обязательное значение из стандарта, а спокойная стартовая настройка для небольшого веб-сервера; его стоит менять под характер нагрузки и требуемое время обнаружения проблемы.

После загрузки конфигурации первым делом проверьте запрос:

up{job="node"}

Для работающего target ожидается значение 1. Если получается 0, бессмысленно сразу настраивать десятки алертов: сначала нужно восстановить связь Prometheus с exporter.

Пороги нужно задавать по длительности, а не по одному пику

Универсального правила «CPU выше 80% — авария» нет. На сервере могут несколько секунд выполняться резервное копирование, архивация или плановый cron, и уведомление только создаст шум. Гораздо полезнее отделять мгновенное значение от устойчивого состояния.

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

groups:
  - name: server
    rules:
      - alert: InstanceDown
        expr: up{job="node"} == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Server target is unavailable"

      - alert: HighCPU
        expr: |
          100 * (
            1 - avg by (instance) (
              rate(node_cpu_seconds_total{job="node", mode="idle"}[5m])
            )
          ) > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Sustained high CPU usage"

      - alert: LowAvailableMemory
        expr: |
          100 *
          node_memory_MemAvailable_bytes{job="node"}
          /
          node_memory_MemTotal_bytes{job="node"}
          < 15
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Low available memory"

      - alert: DiskSpaceLow
        expr: |
          100 * (
            node_filesystem_avail_bytes{
              job="node",
              fstype!~"tmpfs|overlay|squashfs"
            }
            /
            node_filesystem_size_bytes{
              job="node",
              fstype!~"tmpfs|overlay|squashfs"
            }
          ) < 15
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "Low filesystem free space"

Значения 85%, 15% и выбранная продолжительность — не универсальные нормативы. Это исходные пороги для настройки: сервер базы данных, небольшой WordPress, очередь обработки видео и сервер резервного копирования имеют разный нормальный профиль.

Важная часть правила — for. Prometheus переводит условие сначала в состояние pending и считает alert firing только после того, как выражение остаётся истинным заданное время. Это позволяет не будить администратора из-за каждого короткого скачка.

Как настроить оповещения через Alertmanager

Prometheus определяет, что условие нарушено. Дальше Alertmanager решает, куда отправить событие, как сгруппировать несколько одинаковых проблем и когда повторить уведомление. В актуальной документации поддерживаются, среди прочего, email, Slack, Telegram и обычный webhook.

Для Telegram не обязательно хранить токен бота прямо в alertmanager.yml. Текущая конфигурация Alertmanager поддерживает bot_token_file и chat_id_file:

route:
  receiver: "telegram"
  group_by:
    - "alertname"
    - "instance"
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: "telegram"
    telegram_configs:
      - bot_token_file: /etc/alertmanager/telegram_bot_token
        chat_id_file: /etc/alertmanager/telegram_chat_id
        send_resolved: true

Файлы с секретами не должны попадать в Git или быть доступны всем локальным пользователям:

sudo chmod 600 \
  /etc/alertmanager/telegram_bot_token \
  /etc/alertmanager/telegram_chat_id

group_wait, group_interval и repeat_interval тоже требуют настройки под конкретную эксплуатацию. Слишком короткий повтор превратит полезный мониторинг в поток одинаковых сообщений, а слишком длинный может скрыть продолжительный инцидент.

Как проверить конфигурацию до первого реального инцидента

Мониторинг нельзя считать настроенным только потому, что появился график. Нужно отдельно проверить конфигурацию, alert rule и сам маршрут доставки сообщения.

Для Prometheus доступны штатные проверки:

promtool check config /etc/prometheus/prometheus.yml
promtool check rules /etc/prometheus/alerts.yml

Для Alertmanager:

amtool check-config /etc/alertmanager/alertmanager.yml

promtool официально умеет валидировать основную конфигурацию и rule files, а amtool — конфигурацию Alertmanager. Это позволяет поймать ошибку YAML или несовместимую конструкцию до загрузки изменённого файла.

После синтаксической проверки нужен контролируемый тест всей цепочки. На несколько минут можно добавить отдельное правило:

- alert: MonitoringPipelineTest
  expr: vector(1)
  for: 1m
  labels:
    severity: test
  annotations:
    summary: "Monitoring pipeline test"

Загрузите проверенную конфигурацию штатным способом вашей установки, дождитесь тестового сообщения, убедитесь, что оно пришло в нужный канал и что Alertmanager показывает событие. Затем удалите тестовое правило и снова проверьте конфигурацию.

Такой тест лучше искусственного повышения реальной нагрузки: он проверяет Prometheus → rule → Alertmanager → получатель, не создавая ненужный стресс для рабочего сайта.

Практический сценарий: сервер работает, но заканчивается место

Представим WordPress-сервер, на котором ночью создаётся резервная копия. Несколько недель всё работает нормально, затем старые архивы перестают удаляться. Свободное место на разделе постепенно падает до 14%.

Без мониторинга сайт ещё может открываться, поэтому проблема остаётся незаметной. Затем очередной backup или рост логов полностью заполняет раздел, после чего уже начинают ломаться запись кэша, временные файлы, загрузка медиа или работа базы данных.

С правилом DiskSpaceLow сценарий меняется. Если доля доступного пространства держится ниже выбранного порога 15 минут, Alertmanager отправляет предупреждение. Администратор может безопасно начать с диагностических команд:

df -hT
df -i
du -xhd1 /var 2>/dev/null | sort -h | tail

После этого уже определяется источник роста: backup, журналы, Docker-слои, временные файлы или данные приложения. Исправление зависит от причины — автоматически удалять неизвестные каталоги только потому, что пришёл alert, не следует.

Хороший результат здесь измерим: место освобождено, метрика вернулась в рабочий диапазон, alert перешёл в resolved, а причина заполнения устранена так, чтобы ситуация не повторялась следующей ночью.

Безопасность и границы мониторинга

Интерфейсы Prometheus, Alertmanager и exporters содержат техническую информацию об инфраструктуре и не должны без необходимости быть доступны из публичной сети. В официальной модели безопасности Prometheus отдельно предупреждается, что /metrics, API и другие служебные HTTP endpoints не следует просто публиковать в интернет; при необходимости доступа используются защищённая сеть, TLS, аутентификация или контролируемый reverse proxy.

Grafana для базового мониторинга не обязательна. Prometheus уже хранит временные ряды и выполняет запросы, а Alertmanager занимается уведомлениями. Grafana становится полезной, когда нужен удобный общий дашборд, история нескольких показателей и визуальный анализ. Prometheus data source входит в Grafana штатно и подключается указанием адреса сервера Prometheus.

Важно и другое ограничение: серверные метрики не заменяют контроль самого сайта. Нормальные CPU и RAM ничего не говорят о качестве поисковой видимости, поэтому мониторинг позиций и мониторинг запросов яндекс остаются отдельными задачами. Точно так же сервер может быть полностью здоров, когда из-за JavaScript нарушен рендеринг страницы, а слабое описание товара относится уже к содержанию и поисковой оптимизации, а не к состоянию инфраструктуры.

Рабочая система поэтому строится слоями: доступность снаружи, состояние сервера, критичные сервисы, приложение и только затем показатели конкретного проекта. Тогда уведомление сообщает не просто «что-то стало большим», а указывает, в каком слое искать причину.