Минимальный мониторинг серверов, который действительно помогает

Минимальный — значит покрывающий отказ сервиса

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

Минимальный контур обнаруживает полную недоступность, исчерпание конечного ресурса, остановку ключевого процесса, провал резервного копирования и приближение предсказуемого срока — например, окончания сертификата. Он не обязан сразу объяснять корневую причину, но должен дать достаточно контекста для первого безопасного действия.

Покрытие проверяют от пользовательского результата к компонентам. ICMP показывает достижимость узла, но не работу HTTPS. Открытый TCP-порт не подтверждает корректный ответ приложения. Успешный HTTP 200 не гарантирует доступ к базе данных, если проверяется статическая страница. Нужны несколько недорогих уровней, а не одна «универсальная» проверка.

• Инвентарь: имя, роль, среда, владелец, критичность и окно обслуживания.
• Проверка снаружи наблюдаемого узла, а не только локальный агент.
• Ресурсные метрики с трендом, а не одиночным порогом.
• Проверка результата backup и возможность тестового восстановления.
• Маршрут оповещения с живым ответственным.

Разделить внешнюю доступность и внутреннее состояние

Внешний probe отвечает, доступен ли сервис из нужной сети. Агент отвечает, что происходит внутри ОС. Эти сигналы дополняют друг друга: если внешняя проверка падает, а агент жив, вероятна проблема приложения, firewall, DNS или пути; если оба недоступны, возможен отказ хоста, сети или питания.

Проверку размещают за пределами того же отказового домена. Probe на виртуальной машине рядом с целевым сервером не обнаружит потерю всего гипервизора как независимый наблюдатель. Для публичного сайта нужен внешний пункт, для внутреннего сервиса — пункт из пользовательского сегмента и при необходимости из серверной сети.

Интервал выбирают по допустимому времени обнаружения и цене проверки. Частый тяжёлый login-тест способен сам создать нагрузку. Простые TCP/HTTP проверки можно выполнять чаще, глубокую синтетическую транзакцию — реже. Несколько последовательных неуспехов уменьшают ложные события от единичной потери пакета, но увеличивают задержку обнаружения.

Контролировать CPU и память без ложной точности

Высокий CPU — не авария сам по себе. Пакетная задача может штатно использовать все ядра, а сервис оставаться быстрым. Полезнее устойчивое насыщение вместе с ростом latency, load/run queue или steal time. На виртуальной машине steal указывает, что vCPU ждёт физический процессор гипервизора; добавление vCPU гостю не всегда исправляет дефицит.

Для Linux значение free memory почти всегда мало из-за page cache. Наблюдают available memory, swap activity, major page faults и события OOM. Для Windows полезны Available MBytes, committed bytes, paging и события завершения процессов. Один процент памяти без знания модели ОС создаёт ложные тревоги.

Алерт должен учитывать длительность. Пять минут устойчивого CPU выше рабочего порога и единичный пик в одну выборку — разные события. Базовые пороги начинают консервативно, затем уточняют по истории и SLO сервиса. Не следует автоматически копировать 80% на все узлы.

uptime
vmstat 1 5
free -h
journalctl -k --since today | grep -i -E 'oom|out of memory'
systemd-cgtop

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

Диски: место, inode, ошибки и задержка

Контроль только процента занятого filesystem недостаточен. Небольшому разделу 10% может хватить на часы, большому — на месяцы. Нужны процент, абсолютный остаток и прогноз роста. Для Linux отдельно контролируют inode: множество малых файлов способно запретить создание новых данных при свободных гигабайтах.

Заполненный диск — не единственный отказ. Рост latency, queue и I/O errors может остановить базу данных задолго до заполнения. Следят за состоянием RAID/ZFS, SMART или аппаратного контроллера, но интерпретируют в контексте носителя и виртуализации. SMART внутри облачной ВМ обычно недоступен и не должен считаться пробелом агента.

Точки монтирования проверяют явно. Если сетевое хранилище не смонтировалось после загрузки, каталог существует на корневом диске, и backup может успешно записать данные не туда. Контроль должен подтверждать тип filesystem или mount, доступ на чтение и, где безопасно, минимальную тестовую запись.

• Использование filesystem в процентах и абсолютных байтах.
• Свободные inode для Linux.
• Темп роста и прогноз времени до исчерпания.
• Disk latency, queue и ошибки ядра/контроллера.
• Состояние RAID, ZFS, Ceph или SAN отдельным сигналом.
• Наличие ожидаемых mount points.

df -hT
df -i
findmnt --verify
iostat -xz 1 5
journalctl -k -p warning..alert --since today

Проверять процессы, порты и прикладной результат

Состояние systemd service или Windows Service полезно, но процесс может быть running и не обслуживать запросы. Для каждого критичного компонента выбирают дешёвую функциональную проверку: HTTP health endpoint, DNS query, SQL ping с минимальными правами, SMTP banner или получение метрики очереди.

Health endpoint должен проверять только необходимые зависимости и быстро отвечать. Если он синхронно обращается к десяти внешним системам, сбой одной зависимости делает все экземпляры приложения «неживыми» и может запустить каскад перезапусков. Для readiness и диагностики зависимостей лучше раздельные сигналы.

Автоматический restart уменьшает время простоя, но не отменяет alert. Частые перезапуски могут скрывать утечку памяти или повреждённые данные. Контролируют число рестартов и изменение PID, а не только текущее active.

Backup, сертификаты и плановые задания

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

Восстановление проверяется отдельно. Периодическая тестовая реставрация подтверждает доступ к хранилищу, ключам шифрования и пригодность формата. Частота зависит от критичности и скорости изменений. Мониторинг должен напоминать о просроченном restore test, а не обещать восстановимость только по статусу job.

TLS-сертификаты, домены, лицензии и секреты имеют дату окончания. Для публичного сертификата проверяют фактически отдаваемую цепочку с точки клиента, а не файл на диске: reverse proxy или балансировщик может использовать другой экземпляр. Порог предупреждения должен оставлять время на ручное исправление автоматического renewal.

• Возраст последней успешной копии по каждому объекту.
• Неожиданное уменьшение объёма backup.
• Ошибки проверки целостности и недостаток retention.
• Дата последнего успешного тестового восстановления.
• Срок TLS, домена и критичных лицензий.

openssl s_client -connect example.org:443 -servername example.org </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject
systemctl list-timers --all
journalctl -u <backup-unit> --since yesterday

Сделать оповещение действующим

Alert без владельца — запись в журнале. Каждое actionable-событие должно иметь severity, маршрут, рабочее время или дежурство, краткое влияние и ссылку на runbook. Если ночью никто не должен реагировать на заполнение тестового диска, уведомление не должно будить команду; достаточно рабочего канала или тикета.

Событие открывают после устойчивого нарушения, закрывают после устойчивого восстановления и дедуплицируют по объекту и причине. Hysteresis предотвращает постоянное переключение около порога: например, открытие при 10% свободного места и закрытие при 15%. Зависимости подавляют вторичный шум: при недоступном гипервизоре отдельные алерты всех его ВМ редко помогают.

Runbook начинается с безопасной проверки, а не с команды restart. Он содержит владельца, контекст, диагностические команды, критерии эскалации и допустимые автоматические действия. Опасные операции — очистка диска, failover базы, перезапуск кластера — требуют отдельного контроля.

• Название говорит о симптоме и объекте.
• В сообщении есть текущее значение, порог и длительность.
• Ссылка ведёт на релевантный dashboard и runbook.
• Recovery приходит в тот же канал и связывается с проблемой.
• Maintenance window подавляет только ожидаемые сигналы.

Ввести мониторинг и регулярно проверять его

Развёртывание начинают с одного представителя каждого типа серверов, сверяют метрики с локальными командами и только затем масштабируют шаблон. Автообнаружение удобно, но требует фильтров: ephemeral filesystem, loop devices и временные интерфейсы не должны автоматически создавать постоянные тревоги.

После подключения проводят контролируемые тесты. Останавливают некритичный тестовый сервис, создают временный безопасный порог, проверяют маршрут сообщения и recovery. Проверка «система отправляет тестовое письмо» недостаточна: она не проходит полный путь от условия до ответственного.

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

1. Составить инвентарь и назначить владельцев.
2. Подключить внешний probe и агент на пилотных узлах.
3. Добавить ресурсы, сервисы, backup и сроки.
4. Настроить severity, зависимости и maintenance.
5. Провести тест problem/recovery до конечного канала.
6. Зафиксировать покрытие и дату следующего пересмотра.