Правильный мониторинг серверов: какие метрики смотреть и что с ними делать

Мониторинг — это не «Zabbix стоит, значит, мы мониторим». Настоящий мониторинг показывает проблему до того, как пользователь позвонит. Разбираем, какие метрики действительно полезны, какие пороги ставить, и как не утонуть в потоке ложных алёртов.

Уровень 1 — железо

Базовые физические параметры. Без этого слоя любой мониторинг выше — бессмыслен.

CPU utilization

Длительная загрузка выше 80% — повод проверить. Скачки до 100% на секунды — норма. Порог алёрта: > 85% в течение 5 минут.

Load average (Linux) / Процессорная очередь (Windows)

Более важный показатель, чем простая утилизация. Если load average на Linux выше количества ядер в течение 10 минут — очередь растёт, реальная производительность падает.

Memory / RAM

Не просто «занято», а «сколько свободно + кэш». На Linux важна метрика `available`, а не `free`. Алёрт: < 10% свободной памяти в течение 10 минут.

Swap usage

Swap выше 20% — красная лампочка. Сервер активно использует диск как память, производительность упала в 10+ раз.

Disk space

Алёрт warning: > 80%, critical: > 90%. Отдельно мониторить корневой раздел, /var, /var/log, разделы с базами данных.

Disk IO / latency

Не только «сколько места», но и «как быстро читаем-пишем». Алёрт: IO wait > 20% в течение 5 минут. На SSD latency выше 10 мс — повод проверить.

SMART диска

Атрибуты pending_sector, reallocated_sector, temperature, power_on_hours. Растущие pending_sector = диск умирает в ближайшие дни.

RAID-статус

Состояние каждого диска в массиве. Деградированный RAID — моментальный критический алёрт.

Температура и питание

CPU / материнка / диски. Блоки питания (если есть IPMI / iDRAC / iLO). Сбой вентилятора — warning.

Уровень 2 — операционная система и сеть

• Время работы (uptime) — неожиданная перезагрузка = инцидент.
• Количество процессов / потоков — аномальный рост часто указывает на зависший процесс или утечку.
• Открытые файловые дескрипторы — приближение к лимиту (обычно 1024 или 65535) = скоро appкrash.
• Сетевая утилизация — bandwidth на каждом интерфейсе, errors, drops, collisions.
• Потери пакетов — ping к шлюзу и ключевым соседям. Рост > 1% = проблемы в сети.
• Время синхронизации времени (NTP) — разъезжающееся время ломает AD, Kerberos, логи.
• Количество TCP-соединений — TIME_WAIT, ESTABLISHED, CLOSE_WAIT.
• Firewall drops — резкий рост = атака или неправильное правило.

Уровень 3 — приложения

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

Базы данных (PostgreSQL / MS SQL)

• Количество активных соединений (vs лимит `max_connections`).
• Долгие транзакции — запросы дольше 5 минут = мёртвая блокировка или неоптимальный код.
• Cache hit ratio — на PostgreSQL ниже 95% значит, что shared_buffers маловат.
• Replication lag — для реплик, > 10 сек критично.
• Размер базы, рост в день — чтобы вовремя планировать место.

Веб-серверы / backend

• HTTP requests per second, 4xx, 5xx — рост 5xx = поломка приложения.
• Latency p50 / p95 / p99 — важнее, чем средняя. Средняя скрывает медленные хвосты.
• Время ответа /health-endpoint.
• Количество воркеров / процессов PHP-FPM / Gunicorn.

1С

• Доступность кластера 1С (по RAC).
• Количество сеансов, аномальный рост = утечка или зацикленность.
• Размер долгих запросов через технологический журнал.
• Размер базы и лог-файлов.

Уровень 4 — бизнес-метрики

Уровень, до которого многие не доходят, но который даёт самую раннюю сигнализацию.

• Количество заказов в час — упало по сравнению со средним? Что-то сломалось.
• Количество проводок в 1С — нет проводок 30 минут в рабочее время — ненормально.
• Количество отправленных чеков в ОФД — критично для розницы.
• Успешность платежей через эквайринг — резкий спад = провайдер сломался.
• Количество успешных логинов — аномальный спад = проблема с AD / LDAP / SSO.

Как не утонуть в ложных алёртах

1. Отделить алёрты от графиков. Все метрики собирать — но не по каждой алёртить. Алёрт только если нужно действие.
2. Приоритизировать. Critical (серверу плохо прямо сейчас) — звонок в любое время. Warning (плохо завтра) — email / Telegram в рабочее время. Info (интересно знать) — только в дашборде.
3. Группировать. Если упал коммутатор, вы получите 200 алёртов «не доступен сервер X». Правильная система группирует это в один инцидент «сеть 192.168.0.0/24 недоступна».
4. Ставить осмысленные пороги. Не «загрузка CPU > 50%», а «load average > N ядер в течение 10 минут». Первый порог будет срабатывать каждый час.
5. Регулярно пересматривать алёрты. Раз в месяц — список: какие срабатывали, на какие никто не реагировал, какие оказались ложными. Удалять шум, добавлять то, чего не хватило.

Какими инструментами это делать

• Zabbix
• Prometheus + Grafana
• Netdata
• PRTG
• LibreNMS
• Nagios / Icinga
• Uptime Kuma
• Alertmanager
• VictoriaMetrics
• Loki

Наш типовой стек для клиентов — Zabbix для железа/ОС/сетей и Prometheus + Grafana для приложений и бизнес-метрик. Алёрты ведутся в Telegram-канал дежурной смены + email для warning.

Главное

Связанные услуги

Мы настраиваем мониторинг 24/7 для клиентов на IT-аутсорсинге: железо, ОС, базы, 1С и бизнес-метрики в единой системе. Дежурная смена реагирует на критические алёрты в любое время суток. Читайте также: что делать, если сервер упал. Подключить мониторинг.