Мониторинг состояния системы: базовые метрики, пороги и оповещения для начинающих

Почему без мониторинга сервер ломается внезапно

Отказ оборудования почти всегда идёт по наклонной: температура растёт, напряжение проседает, память заканчивается не за секунду, а за часы или сутки. Вышедший из строя вентилятор не выключает процессор сразу: температура поднимается на 0,5-1 °C в час, и только через несколько дней срабатывает тепловая защита. Утечка памяти в сервисе добавляет 50-200 МБ в час, и OOM killer приходит на четвёртые сутки. Деградация блока питания проявляется редкими перезагрузками под нагрузкой, при этом в логах не остаётся ни одной внятной записи.

Ждать, пока пользователи сообщат о проблеме, дорого: простой веб-сервиса или файлового хранилища съедает часы рабочего времени всей команды. Метрики дают окно в несколько часов или дней, когда деградацию видно на тренде, а не по факту падения сервиса.

Четыре группы метрик закрывают основную часть типовых инцидентов на одиночном сервере: доступность, загрузка CPU, использование памяти, температура и питание. Глубокий APM с трассировками и профилированием нужен, но он не подскажет, что у сервера проседает питание на линии 12 В. Начинать стоит с базы, а расширять её по мере появления конкретных задач.

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

Список, который стоит настроить на любом сервере с первого дня эксплуатации:

Доступность: ICMP ping, открытые TCP-порты (22, 80, 443), ответ HTTP с кодом 200, состояние systemd-юнита.
CPU: user, system, iowait, idle, load average.
Память: MemAvailable, used, использование swap, счётчик OOM-событий.
Физические параметры: температура CPU и дисков, напряжение по линиям блока питания, обороты вентиляторов, атрибуты SMART.

Именно эти показатели первыми сигналят о деградации. Перегрев ведёт к троттлингу и внезапному выключению, просадка питания к перезагрузкам, рост потребления CPU и памяти к замедлению сервисов. Дисковая подсистема добавляет к этому рост iowait и задержки ввода-вывода. Порядок разбора метрик ниже соответствует частоте, с которой они помогают поймать реальную проблему.

Доступность: жив ли хост и отвечают ли сервисы

ICMP ping ловит полную потерю сети, но пропускает зависший веб-сервер: хост отвечает, а порт 443 не открывается. Проверок должно быть три уровня. Первый: ping до адреса сервера. Второй: TCP-соединение с портом сервиса (22, 80, 443, 5432, 6379). Третий: HTTP-запрос с ожиданием кода 200 и проверкой, что тело ответа не пустое.

В Zabbix это делается элементом данных типа Simple check с ключами icmpping, net.tcp.service[ssh] и web.page.get или HTTP agent с ожидаемым кодом 200. В Prometheus за внешние проверки отвечает blackbox_exporter: пробы icmp, tcp_connect и http_2xx описываются в одном конфигурационном файле, а Prometheus забирает результат как обычную метрику probe_success.

Интервал проверки для боевых сервисов: 30-60 секунд, для критичных точек входа 10-15 секунд. Дополнительно стоит отслеживать состояние systemd-юнита: процесс может быть жив, но уже не обслуживать запросы. Без доступности остальные метрики бесполезны, поэтому эта группа настраивается первой.

Загрузка CPU: user, system, iowait

Процент утилизации CPU считается как 100 минус idle. Разбивка по режимам объясняет причину нагрузки:

user: время в пользовательском пространстве, растёт при вычислениях в приложении.
system: работа ядра, всплески дают сетевые пакеты, syscall и файловые операции.
iowait: процессор ждёт диск или сеть, сам CPU при этом свободен.
idle: простой, база для расчёта загрузки.

Высокий iowait чаще указывает на проблемы с дисковой подсистемой, а не с процессором. Если iowait держится выше 20% в течение пяти минут, смотрите на задержки диска и очереди, а не на частоту ядер. Быстро найти, кто именно грузит диск или сеть, помогают готовые команды для поиска источника высокой загрузки.

Практические пороги: warning при загрузке выше 80% в течение 5 минут, critical при 95% в течение 5 минут. Load average сравнивайте с числом ядер: значение 8 на четырёх ядрах означает очередь из задач, а не нормальную работу. Подробный разбор метрик CPU, памяти, дисковых I/O и сети с рабочими порогами собран в руководстве по мониторингу производительности серверов.

Использование памяти: used, available, swap

В Linux свободная память почти всегда уходит под page cache, поэтому показатель free близок к нулю и тревоги не вызывает. Ориентироваться нужно на MemAvailable: это оценка памяти, которую ядро отдаст приложению без вытеснения на диск. Если available падает ниже 10% и держится так 10 минут, это warning. Рост swap выше 50% от выделенного объёма: critical, сервис начинает тормозить на вытеснении страниц.

Утечку памяти видно по медленному росту used при стабильной нагрузке: приложение добавляет 100 МБ в час, и через двое суток сервер уходит в OOM. Отслеживайте счётчик vm.oom_kill и наличие записей oom-killer в dmesg. Если процесс убивают регулярно, метрика памяти расскажет об этом раньше, чем пользователи заметят перезапуски сервиса.

Температура и питание: физические параметры, которые нельзя игнорировать

Источники данных: ipmitool sensor для серверов с BMC, lm-sensors для настольного железа, smartctl -A для дисков, коллектор hwmon в node_exporter. В Zabbix для этого есть шаблон Template IPMI, в Prometheus - ipmi_exporter.

Ориентировочные пороги для CPU: warning на 75 °C, critical на 85 °C. Троттлинг большинства серверных процессоров начинается в районе 80-90 °C, аварийное выключение срабатывает ближе к 95-100 °C, точное значение зависит от модели. Для жёстких дисков: warning 45-50 °C, critical 55-60 °C, выше этих значений растёт частота отказов механики. Отдельно контролируйте обороты вентиляторов: падение до нуля при работающем сервере означает отказ крыльчатки.

Питание проверяется по датчикам IPMI. Отклонение напряжения 12 В или 5 В на 5% от номинала: warning, на 10%: critical. Напряжение уплывает постепенно, и тренд за месяц виден раньше, чем сервер начнёт спонтанно перезагружаться. Схожие принципы применяются и в промышленной автоматике: например, контроллер температуры PMA KS 94 питается от 90-250 В AC и держит процесс по ПИД-алгоритму, но в серверной стойке его показания не заменяют датчики самого сервера.

Практическая настройка базовых проверок в Zabbix

Схема работы: на сервере стоит Zabbix Agent, он отдаёт метрики на Zabbix Server, сервер применяет к ним триггеры и запускает действия по уведомлениям. Дополнительно настраиваются внешние проверки, если агент установить нельзя.

Установка и настройка Zabbix Agent

Для Debian и Ubuntu агент ставится из официального репозитория проекта:

apt update
apt install -y zabbix-agent
systemctl enable --now zabbix-agent

В файле /etc/zabbix/zabbix_agentd.conf задаются три ключевых параметра:

Server=10.0.0.10
ServerActive=10.0.0.10
Hostname=web-01

Server ограничивает список адресов, с которых принимаются запросы, ServerActive нужен для активных проверок, Hostname должен совпадать с именем хоста в веб-интерфейсе Zabbix. После правки конфигурации агент перезапускается командой systemctl restart zabbix-agent. Проверка связи с сервера Zabbix выполняется так:

zabbix_get -s 10.0.0.11 -k system.cpu.load[percpu,avg1]

Дальше в веб-интерфейсе создаётся хост, указывается его IP и привязывается шаблон Template OS Linux by Zabbix agent: он сразу даёт набор элементов данных по CPU, памяти, дискам и сети. Для температуры и питания добавляется Template IPMI, а в хосте прописываются IPMI-интерфейс и учётные данные BMC.

Создание триггеров с порогами: примеры для CPU, памяти и температуры

Триггер описывается выражением на языке Zabbix. Примеры, которые можно взять за основу и заменить имя хоста:

{web-01:system.cpu.util[,idle].avg(5m)}<20
{web-01:system.cpu.util[,idle].avg(5m)}<10
{web-01:vm.memory.utilization.avg(5m)}>90
{web-01:ipmi.sensor.temperature[CPU].last()}>75
{web-01:ipmi.sensor.temperature[CPU].last()}>85

Первое выражение срабатывает, когда idle ниже 20%, то есть загрузка выше 80% и держится пять минут, функция avg сглаживает короткие всплески. Порог 10% соответствует 90% загрузки и подходит для critical. Уровень серьёзности задаётся в свойствах триггера: Warning, High, Disaster. Для температуры 75 °C: Warning, 85 °C: Disaster.

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

Практическая настройка базовых проверок в Prometheus

Prometheus забирает метрики по HTTP раз в 15 секунд, хранит их как временные ряды и вычисляет алерты по правилам. Метрики с серверов отдаёт node_exporter, алерты уходят через Alertmanager.

Установка node_exporter и сбор метрик

Архив node_exporter распаковывается на сервере, бинарник копируется в /usr/local/bin, запуск оформляется systemd-юнитом:

tar xvf node_exporter-*.tar.gz
cp node_exporter-*/node_exporter /usr/local/bin/
useradd --no-create-home --shell /bin/false node_exporter
node_exporter --web.listen-address=:9100

На стороне Prometheus достаточно добавить задание сбора в prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['10.0.0.11:9100', '10.0.0.12:9100']

После перезапуска Prometheus проверьте страницу /targets: все цели должны быть в состоянии UP. Метрика node_exporter_build_info подтверждает, что сбор идёт. Если нужен полный маршрут от установки до дашбордов, смотрите пошаговое руководство по node_exporter с ключевыми метриками и алертами, а общая схема со Grafana и оповещениями разобрана в инструкции по развёртыванию стека мониторинга.

Написание alerting rules: примеры для CPU, памяти и температуры

Правила складываются в отдельный файл, например rules.yml, и подключаются в prometheus.yml через rule_files. Основные алерты для базового набора выглядят так:

groups:
  - name: node-basics
    rules:
      - alert: HighCpuLoad
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Загрузка CPU выше 80% на {{ $labels.instance }}"

      - alert: HighIowait
        expr: avg by (instance) (rate(node_cpu_seconds_total{mode="iowait"}[5m])) * 100 > 20
        for: 10m
        labels:
          severity: warning

      - alert: LowMemoryAvailable
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10
        for: 10m
        labels:
          severity: warning

      - alert: HighCpuTemperature
        expr: node_hwmon_temp_celsius > 85
        for: 3m
        labels:
          severity: critical

Параметр for: 5m означает, что алерт перейдёт в состояние firing только если условие держится непрерывно пять минут. Разовый скачок CPU при запуске бэкапа уведомления не создаст. Метрики hwmon появляются у node_exporter автоматически, если на сервере есть датчики, доступные ядру; для IPMI используется отдельный ipmi_exporter с метриками вида ipmi_voltage или ipmi_temperature_celsius.

Маршрутизацию и дедупликацию выполняет Alertmanager:

route:
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: telegram-warning
  routes:
    - matchers: [severity="critical"]
      receiver: telegram-critical

Как выбрать пороги и не утонуть в ложных срабатываниях

Порог имеет смысл только относительно нормы конкретного сервера. Сервер с обычной загрузкой CPU 30% и порогом 80% даст полезный алерт, а тот же порог на сервере с рабочей нагрузкой 70% будет срабатывать каждый день и быстро попадёт в игнор.

Сбор baseline: как понять нормальное поведение системы

Первые одну-две недели собирайте метрики без включённых алертов. Смотрите на графики в Zabbix или Grafana и отмечайте суточный профиль: пики в 2:00 от бэкапа, рост памяти к концу рабочего дня, скачки сети при синхронизации реплик. По этим данным выбираются рабочие значения: если нормальная загрузка держится в диапазоне 20-45%, порог 80% даёт запас и не шумит.

Для сервисов с плавающей нагрузкой полезнее динамический порог: сравнение текущего значения со средним за ту же неделю и тот же час. Простое правило вида "на 2 сигмы выше среднего за 7 дней" отсекает сезонные колебания и ловит аномалии точнее статичной цифры.

Дедупликация и эскалация: как не пропустить важное

Дедупликация группирует одинаковые уведомления, чтобы сто серверов с одной проблемой не отправили сто писем. В Alertmanager за это отвечает group_by: ['alertname', 'instance'], а также group_wait и group_interval. В Zabbix похожий эффект даёт группировка операций в Action и макросы в теме письма.

Эскалация нужна, когда первый получатель не отреагировал. В Zabbix она настраивается шагами: на шаге 1 письмо инженеру, через 30 минут на шаге 2 SMS дежурному, ещё через час звонок руководителю смены. В Alertmanager эскалацию строят через маршруты с разными получателями и repeat_interval. Без эскалации critical-алерт в 3 часа ночи спокойно пролежит до утра в почте.

Каналы уведомлений: email, мессенджеры, SMS

Канал выбирается по тому, насколько быстро сообщение должно дойти до дежурного.

Канал	Скорость доставки	Стоимость	Когда использовать
Email	минуты	бесплатно	warning, отчёты, архив уведомлений
Telegram, Slack	секунды	бесплатно	warning и critical для дежурной смены
SMS	секунды	платно, зависит от оператора	critical вне рабочего времени
Голосовой звонок	секунды	платно	авария уровня "сервис недоступен"

Рабочая схема: warning уходит в мессенджер, critical дублируется в мессенджер и SMS. В Zabbix интеграции с Telegram и Slack настраиваются через webhook media type, в Prometheus через Alertmanager receivers. Каждый канал проверяется тестовым уведомлением до ввода в эксплуатацию: пустой токен бота или неверный chat_id молча теряют все алерты. Если отдельного сервера под стек мониторинга нет, его можно поднять на VDS: например, арендовать облачный сервер под Zabbix или Prometheus быстрее, чем собирать железо.

Типовые инциденты, которые ловятся на ранней стадии

Отказ вентилятора и перегрев. Температура CPU поднимается с 55 до 75 °C за несколько часов, срабатывает Warning. Если реакции нет, к 85 °C включается троттлинг, растёт iowait, падает производительность сервисов. Замена вентилятора до аварийного выключения обходится дешевле простоя.
Просадка питания. Линия 12 В уходит с 12,1 В к 11,4 В, это отклонение 5%, срабатывает Warning. При 10,8 В (10%) счётчик перезагрузок BMC показывает спонтанные рестарты. Блок питания меняется по плану, без внезапной остановки сервера.
Утечка памяти в приложении. MemAvailable падает на 100-200 МБ в час при стабильной нагрузке, swap доходит до 40-60%, затем vm.oom_kill увеличивается. Перезапуск сервиса по алерту предотвращает падение всей системы.
Деградация диска. iowait растёт с 3 до 25%, задержки ввода-вывода увеличиваются, атрибут SMART Reallocated_Sector_Ct показывает новые переназначенные сектора. Диск выводится из массива до потери данных.

Типичные ошибки при настройке мониторинга

Пороги взяты из чужого конфига. Решение: собрать baseline за неделю и выставить значения с запасом по своей нагрузке.
Слишком низкие пороги. Алерты приходят десятками, дежурный перестаёт их читать. Решение: сглаживание avg(5m) в Zabbix и for: 5m в Prometheus плюс пересмотр порогов раз в месяц.
Мониторинг только CPU и памяти. Перегрев и просадка питания остаются незамеченными. Решение: добавить IPMI или hwmon и SMART.
Нет дедупликации и эскалации. Почта забита, critical теряется среди warning. Решение: group_by в Alertmanager, шаги эскалации в Zabbix Actions.
Непроверенные каналы уведомлений. Токен бота истёк, SMS не подключены. Решение: тестовая отправка после каждой правки настройки.
iowait игнорируется. Дисковая проблема выглядит как медленное приложение. Решение: отдельный алерт на iowait выше 20% за 10 минут.
Сервер мониторинга без контроля. Prometheus упал, никто не заметил. Решение: внешняя проверка доступности самого стека или dead man's switch, который ждёт сигнал каждые 5 минут и молчит при его отсутствии. Разбор ошибок проектирования с чек-листом собран в материале про типовые ошибки при разработке систем мониторинга.

Чек-лист для быстрого старта

Установите Zabbix Agent или node_exporter на сервер и убедитесь, что метрики доходят до сервера мониторинга.
Настройте сбор по четырём группам: доступность, CPU, память, температура и питание.
Добавьте проверки доступности отдельно для хоста и для каждого критичного сервиса.
Собирайте baseline одну-две недели без включённых алертов.
Включите триггеры и alerting rules с порогами по baseline и сглаживанием за 5 минут.
Настройте каналы: warning в мессенджер, critical в мессенджер и SMS, плюс шаг эскалации.
Проверьте каждый алерт искусственной нагрузкой и убедитесь, что уведомление дошло.
Пересматривайте пороги раз в квартал или после крупных изменений в инфраструктуре.

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