Мониторинг серверной инфраструктуры: какие метрики отслеживать
Большинство отказов сервера не происходит внезапно — им предшествуют признаки, которые видны за дни или недели до сбоя: растущая температура процессора, диск с увеличивающимся числом переназначенных секторов, блок питания, начавший работать с перегрузкой. Мониторинг существует именно для того, чтобы увидеть эти признаки раньше, чем они превратятся в простой. Разберём, какие метрики стоит отслеживать в первую очередь и с какой периодичностью.
Аппаратные показатели
Это тот уровень мониторинга, который не заменить программными средствами — данные снимаются напрямую с датчиков сервера.
Температура. Каждый современный сервер HPE и Dell имеет встроенные датчики температуры процессоров, памяти и воздуха на входе/выходе. Критично отслеживать не только пиковые значения, но и тренд — процессор, который стабильно работает на 5–10°C выше обычного для этой нагрузки, часто сигнализирует о забитом пылью радиаторе или неисправном вентиляторе задолго до критического перегрева.
Состояние вентиляторов. Скорость вращения каждого вентилятора видна в системе управления сервером. Резкий рост оборотов при той же нагрузке — верный признак того, что один из вентиляторов вышел из строя, а остальные компенсируют его отсутствие.
Блоки питания. В серверах с резервированием (Hot Plug БП) важно не только знать, что оба блока в строю, но и следить за распределением нагрузки между ними — перекос может говорить о деградации одного из блоков.
S.M.A.R.T.-показатели дисков. Количество переназначенных секторов, число часов наработки, температура диска — это данные, которые почти всегда доступны заранее и почти всегда предсказывают выход диска из строя за какое-то время до реального отказа.
Утилизация ресурсов
Здесь задача — не просто зафиксировать текущую загрузку, а увидеть тренд, чтобы спланировать апгрейд до того, как нехватка ресурсов начнёт напрямую тормозить бизнес-процессы.
CPU — средняя и пиковая загрузка, особенно важно отслеживать очередь процессов (load average), а не только процент использования: высокая очередь при невысокой загрузке в процентах может говорить о неэффективном распределении между ядрами.
Память — не только объём занятой памяти, но и активность подкачки (swap). Активное использование подкачки на сервере — почти всегда сигнал, что памяти физически не хватает, и это будет напрямую бить по производительности.
Дисковый I/O — задержка отклика диска (latency) информативнее, чем просто скорость чтения/записи в мегабайтах в секунду. Латентность, которая начала расти при той же нагрузке, — ранний признак деградации массива или приближения его к пределу производительности.
Сеть — загрузка интерфейсов, число ошибок и отброшенных пакетов. Растущее число ошибок при стабильной загрузке часто указывает на проблему с кабелем или портом коммутатора, а не на сам сервер.
Здоровье RAID-массива
Мониторинг RAID — отдельная тема, которую часто недооценивают именно потому, что при отказе одного диска в отказоустойчивом массиве (например, RAID 10 или RAID 5) сервер продолжает работать как ни в чём не бывало — деградация массива незаметна пользователям, но опасна. Мы подробно разбирали логику выбора уровня RAID в статье RAID 1, 5, 6, 10 для сервера — сравнение — то же самое правило работает и для мониторинга: чем меньше избыточности в выбранном уровне, тем критичнее вовремя заметить деградацию до того, как откажет второй диск.
Ключевая метрика здесь — статус массива (Optimal / Degraded / Failed) и время ребилда после замены диска. Уведомление о переходе массива в статус Degraded должно приходить администратору мгновенно, а не обнаруживаться при плановой проверке раз в неделю.
Доступность и время безотказной работы
Uptime сервера — базовая метрика, но важна она не сама по себе, а в связке с тем, что простой стоит бизнесу реальных денег. Мы считали эту логику подробнее в статье про TCO серверного оборудования — простои напрямую входят в полную стоимость владения сервером, и мониторинг доступности — один из немногих инструментов, которые позволяют сократить эту статью расходов практически бесплатно.
Как собирать эти данные
Современные серверы HPE и Dell не требуют установки дополнительного агента для базового мониторинга — данные снимаются через встроенные контроллеры управления (HPE iLO, Dell iDRAC), которые работают независимо от операционной системы и доступны, даже если сервер выключен или завис. Многие из них поддерживают Redfish API — мы разбирали этот протокол отдельно в статье Что такое Redfish API — именно он сейчас становится стандартом для получения этих данных программным способом.
Для сведения метрик со всех серверов в единую систему с графиками, историей и уведомлениями обычно используют отдельные платформы мониторинга — Zabbix, PRTG, или встроенные средства HPE OneView и Dell OpenManage для парка из однотипных серверов одного производителя.
Пороговые значения: с чего начать
Метрика | Норма | Когда тревога | Периодичность проверки |
|---|---|---|---|
Температура CPU | По спецификации модели, обычно до 70–80°C под нагрузкой | Стабильный рост при той же нагрузке | Постоянно, с уведомлением |
Загрузка CPU | До 70–80% в среднем | Регулярные пики выше 90% | Постоянно |
Использование памяти | До 80% | Активное использование подкачки | Постоянно |
Latency диска | Единицы миллисекунд для SSD/NVMe | Устойчивый рост при той же нагрузке | Постоянно |
Статус RAID | Optimal | Degraded или Failed | Мгновенное уведомление |
Ошибки сетевого интерфейса | Единичные | Растущее число при стабильной загрузке | Ежедневно |
Точные пороги стоит откалибровать под конкретную модель сервера и характер вашей нагрузки — таблица выше задаёт стартовую точку, а не универсальный стандарт для всех случаев.
Частые вопросы
Нужен ли отдельный сервер под систему мониторинга? Для небольшого парка (до 10–15 серверов) обычно достаточно виртуальной машины с выделенными ресурсами. Для крупной инфраструктуры систему мониторинга стоит выносить на отдельное физическое или виртуальное окружение, не зависящее от мониторируемых серверов.
Что делать, если сервер уже старый и не поддерживает современные протоколы вроде Redfish? Более старые контроллеры управления (например, ранние версии iLO) всё равно предоставляют похожие данные через собственные API или SNMP — просто с меньшей стандартизацией. Настройка потребует чуть больше индивидуальной работы, но принципиально возможна.
Как часто стоит пересматривать пороговые значения тревог? Минимум раз в полгода, а также при любом значимом изменении нагрузки — например, после ввода нового бизнес-приложения или роста числа пользователей.
Если планируете выстроить систему мониторинга для своего серверного парка или подбираете новое оборудование с учётом удобства удалённого управления — напишите нам, поможем подобрать конфигурацию с нужными возможностями мониторинга уже на уровне встроенных контроллеров.