Мониторинг сервера для начинающих: CPU, память, диск и сеть
Мониторинг нужен не для красивого дашборда, а чтобы вовремя заметить ухудшение и быстро ответить, какой ресурс или сервис изменился вместе с симптомом.
Начинайте с пользовательского сигнала
Первый уровень — доступность и время ответа сервиса. Сервер может иметь свободный CPU, но приложение уже возвращает ошибки. Поэтому инфраструктурные метрики дополняют, а не заменяют HTTP-проверки, процент ошибок и длительность ключевых операций.
Определите нормальный диапазон в разное время суток. Одна и та же загрузка может быть штатной во время пакетной обработки и аномальной ночью. Сравнение с базовой линией полезнее универсального порога из чужой инструкции.
CPU: загрузка не равна проблеме
Смотрите использование CPU по ядрам, load average и время ожидания ввода-вывода. Высокий CPU вместе с ростом времени ответа указывает на вычислительное ограничение. Высокий load при умеренном CPU может означать ожидание диска или большое число заблокированных задач.
Короткий пик не всегда требует алерта. Полезнее условие, которое держится несколько минут и совпадает с ухудшением сервиса. Для расследования добавьте разрез по процессам, но не храните каждую секунду бесконечно: выберите разумный интервал и срок хранения.
Память: учитывайте кеш и swap
Показатель free в Linux может быть небольшим, потому что система использует память под кеш. Оценивайте available, динамику swap, ошибки выделения памяти и завершения процессов OOM killer. Постоянный рост памяти одного процесса важнее единичного высокого значения.
Если используется контейнеризация, проверяйте лимит контейнера отдельно от памяти хоста. Процесс может получить OOM внутри контейнера, хотя на сервере еще есть свободный ресурс.
Диск и файловая система
Контролируйте занятое место, число inode, задержку операций и очередь диска. Свободные гигабайты не помогут, если закончились inode из-за миллионов маленьких файлов. Резкий рост журналов или временных файлов следует связывать с конкретным приложением.
Алерт по месту должен оставлять время на реакцию. Вместо одного порога добавьте предупреждение и критический уровень, а также прогноз заполнения для разделов, которые растут стабильно.
Сеть и полезные алерты
Для сети смотрите ошибки интерфейса, потери, задержку до зависимостей, число соединений и повторные передачи. Общий трафик без контекста мало говорит: рост может быть успехом продукта или атакой. Сопоставляйте его с запросами и ответами приложения.
Каждый алерт должен отвечать на три вопроса: что ухудшилось, насколько срочно и где начать проверку. Добавьте ссылку на дашборд и короткую инструкцию. Если уведомление регулярно не требует действия, измените условие или уберите его.
- доступность и время ответа;
- ошибки приложения;
- CPU, load и I/O wait;
- available memory, swap и OOM;
- место, inode и задержка диска;
- ошибки сети и доступность зависимостей.
