Мониторинг серверов и СХД: как организовать и какие инструменты выбрать

Мониторинг серверов отвечает на два вопроса: что происходит с оборудованием прямо сейчас и что с ним случится через неделю. С первым справляется почти любая система мониторинга. Второй требует показателей, до которых доходят редко: износ накопителей, время работы дискового массива с пониженной избыточностью, рост очередей к контроллеру хранилища.

Разберём, какие показатели снимать с серверов и систем хранения данных и чем их собирать: агентом, по SNMP или через контроллер управления сервером. Отдельно — как выстроить процесс, чтобы оповещения приводили к действию.

Материал пригодится тем, кто запускает мониторинг серверов с нуля или дополняет уже работающую систему метриками уровня оборудования.

Что даёт мониторинг серверов и СХД

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

На практике это нужно для трёх задач:

• Поймать деградацию до отказа. Накопители, блоки питания и вентиляторы выходят из строя постепенно. Оборудование заранее сообщает об ошибках коррекции, росте времени доступа и перегреве — если эти сообщения кто-то читает.
• Найти причину замедления. Когда пользователи жалуются на медленную работу программ, данные мониторинга показывают, где возникла задержка: на диске, в сети, на стороне приложения или в хранилище.
• Планировать закупки по фактам. Тренд роста задержек и заполнения ёмкости говорит о необходимости расширения за месяцы до того, как инфраструктура упрётся в потолок.

Как контролировать состояние сервера

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

Ресурсы: процессор, память, диски и сеть

Базовый набор для контроля нагрузки сервера — его снимает любая система мониторинга. Полезны не только средние значения, но и производные показатели:

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

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

Железо: температура, питание, вентиляторы и RAID-контроллер

Аппаратные показатели операционной системе видны частично или не видны вовсе. Их собирают через контроллер управления сервером:

• Температура процессоров, модулей памяти, накопителей и воздуха на входе в корпус.
• Состояние блоков питания и наличие резервирования. Отказ одного блока в паре не останавливает сервер, поэтому без мониторинга его замечают не сразу.
• Обороты вентиляторов. Остановившийся вентилятор перегревает соседние компоненты и ускоряет их износ.
• Состояние RAID-контроллера: исправность массива, режим кэша, заряд батареи или конденсатора кэша. При разряженной батарее контроллер переключается на сквозную запись, и производительность падает без единой аппаратной ошибки.
• Журнал системных событий оборудования — записи об ошибках памяти, шины и питания.

Доступность служб и приложений

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

Как предсказать отказ диска в сервере и СХД

Накопители выходят из строя постепенно. Сначала растёт время отклика, увеличивается число повторных операций, появляются ошибки коррекции — и всё это время формальный статус диска остаётся нормальным. Если диск меняют уже после отказа, данные держатся только на избыточности массива, и всё время до замены массив работает без запаса.

Ранние признаки собирают через технологию самодиагностики накопителей S.M.A.R.T. Она отдаёт счётчики, по которым видно состояние диска задолго до отказа:

• Жёсткие диски. Переназначенные и ожидающие переназначения секторы, ошибки чтения, рост времени раскрутки и позиционирования, температура.
• Твердотельные накопители. Остаточный ресурс записи, объём записанных данных, число доступных резервных блоков, ошибки носителя.

Стабильность времени записи S.M.A.R.T. не отдаёт — её отслеживают отдельно, по времени отклика на уровне операционной системы.

Значение имеет динамика: диск с двумя переназначенными секторами за год работает нормально, а тот же прирост за неделю — повод планировать замену. Поэтому счётчики S.M.A.R.T. снимают регулярно и хранят историю.

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

Какие параметры СХД критичнее остальных

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

Мониторинг хранилища строят вокруг других показателей.

• Задержки чтения и записи. Главный индикатор состояния СХД: время между запросом и ответом первым реагирует на перегрузку, проблемы с дисками, переполнение кэша и ограничения контроллера. Смотрят распределение и пики — на практике 95-й и 99-й перцентили задержки: кратковременные всплески часто важнее плавного роста среднего. Запись деградирует раньше чтения, особенно при заполнении кэша и перестройке массива.
• Пропускная способность вместе с задержками. Сама по себе скорость обмена вводит в заблуждение: хранилище показывает высокие цифры в тестах, а при реальной нагрузке отклик растёт из-за очередей. Полезен другой показатель — устойчивость пропускной способности при увеличении числа операций.
• Очереди запросов. Показатель, на который смотрят реже остальных. Рост очередей означает, что хранилище перестаёт справляться с текущим профилем нагрузки, даже когда остальные метрики выглядят приемлемо.
• Контроллеры и кэш. Проблемы контроллера маскируются под дисковые. Кэш какое-то время сглаживает пики нагрузки, но когда сброс на диски перестаёт успевать за потоком записи, задержки резко растут. Отслеживают долю попаданий в кэш, режим его работы и состояние резервного питания.
• Ёмкость на уровне пулов и томов. При тонком выделении ёмкости сумма объявленных LUN и томов может превышать физический объём пула. Когда физическая ёмкость пула заканчивается, запись во все тонкие тома прекращается, хотя операционная система сервера по-прежнему видит свободное место на своём диске. Поэтому свободное место контролируют по пулу, а не по логическому диску на сервере.
• Пути к хранилищу. В схеме с несколькими путями отказ одного из них не заметен для приложений, но лишает инфраструктуру резерва и увеличивает нагрузку на оставшиеся пути.

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

Чем снимать метрики с серверов и СХД

Способ сбора определяет, какие показатели вообще попадут в систему. Часть данных доступна только изнутри операционной системы, часть — только в обход неё.

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

Агент на сервере

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

SNMP и трапы

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

Опрос показывает динамику, трапы приносят события между опросами. Для оборудования полезны оба режима: авария блока питания придёт трапом сразу, а тренд температуры соберётся опросом.

IPMI, BMC и Redfish: мониторинг мимо операционной системы

В серверы встроен отдельный контроллер управления — BMC, у производителей он носит собственные названия: iDRAC, iLO и другие. Контроллер питается от дежурной линии блока питания, имеет свой сетевой адрес и остаётся доступен, даже когда сервер выключен или операционная система не загрузилась.

Через него доступны показатели, которых нет в операционной системе: температуры датчиков, обороты вентиляторов, напряжения, состояние блоков питания и журнал аппаратных событий. Обращаются к контроллеру по интеллектуальному интерфейсу управления платформой IPMI либо по более современному Redfish, который отдаёт те же данные через REST API.

Этот канал закрывает главный пробел агентного мониторинга: если сервер перестал отвечать, контроллер управления покажет, перегрелся он или остановился по ошибке оборудования, а после восстановления питания в журнале останется запись о том, что произошло.

Интерфейсы управления СХД

Системы хранения отдают показатели через собственный API, по SNMP или по отраслевому стандарту управления хранилищами SMI-S, построенному на моделях CIM и WBEM. Глубина метрик зависит от модели: одни массивы отдают задержки по каждому тому, другие ограничиваются общим статусом. Для распространённых линеек хранилищ есть готовые шаблоны под популярные системы мониторинга, и это заметно ускоряет запуск.

Какие инструменты мониторинга серверов выбрать

Систему мониторинга серверов и СХД собирают из нескольких компонентов: сбор показателей, хранилище данных, визуализация и оповещения. Одни продукты покрывают все четыре роли, другие берут на себя одну.

• Zabbix. Собирает данные агентом, по SNMP, по IPMI и через собственные проверки, поэтому одним продуктом наблюдают и за серверами, и за хранилищами. Готовые шаблоны есть под серверные платформы и под распространённые линейки СХД; под редкие модели шаблоны дорабатывают.
• Prometheus с экспортёрами. Работает по модели опроса и получает данные от небольших программ-посредников: один отдаёт метрики операционной системы, другой опрашивает устройства по SNMP, третий забирает показатели с контроллера управления сервером. Удобен там, где инфраструктура часто меняется.
• Grafana. Визуализация поверх собранных данных и оповещения по заданным правилам. Подключается к разным источникам и собирает показатели серверов и хранилищ на общие панели.
• Российские системы мониторинга. Работают с серверами и СХД, как правило входят в реестр отечественного программного обеспечения и поддерживают российские операционные системы. Актуальны там, где требования к импортозамещению закреплены документами.

Встречаются и другие открытые продукты — Nagios, Icinga, Netdata, Cacti, Munin. Часть зарубежных вендоров прекратила продажи и продление лицензий в России, поэтому в новых проектах их рассматривают реже.

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

Как организовать мониторинг серверов и СХД

Порядок работ примерно одинаков независимо от выбранного продукта.

1. Инвентаризация. Соберите перечень серверов, хранилищ, гипервизоров и служб. Отметьте, какие сервисы критичны для работы компании — от этого зависят пороги и приоритеты оповещений.
2. Определение метрик. Для каждого типа объектов зафиксируйте набор показателей. Серверу нужны ресурсы, датчики оборудования и службы, хранилищу — задержки, очереди, состояние пулов и дисков.
3. Настройка сбора. Разверните агенты, откройте доступ к контроллерам управления и интерфейсам хранилищ, подключите шаблоны. Центральный сервер мониторинга разместите отдельно от наблюдаемой инфраструктуры — иначе авария заберёт с собой и систему, которая должна о ней сообщить.
4. Фиксация базовой линии. Дайте системе поработать в обычном режиме и запишите нормальные значения. Без базовой линии отличить аномалию от рабочего колебания невозможно, а на новом оборудовании запишите её сразу после ввода в эксплуатацию.
5. Пороги и оповещения. Задайте границы срабатывания от базовой линии, распределите уведомления по каналам и получателям.
6. Обслуживание и поддержка. Пересматривайте пороги при изменении нагрузки, добавляйте новые объекты, убирайте оповещения, которые ни разу не привели к действию.

Пороги и дежурство в мониторинге серверов

Главная проблема работающего мониторинга — избыток сообщений. Когда система шлёт десятки уведомлений в день, администраторы перестают их читать, и вместе с шумом теряется настоящая авария.

Что помогает удержать поток оповещений на разумном уровне:

• Пороги от базовой линии. Загрузка процессора в 80 процентов бывает штатной для сервера баз данных и признаком проблемы для файлового сервера.
• Разделение по важности. Отказ блока питания требует реакции немедленно, рост заполнения раздела — в течение рабочего дня. Разные уровни идут разными каналами: критичные — звонком или в мессенджер, остальные — почтой и в систему заявок.
• Оповещение о причине, а не о следствии. Одна авария хранилища порождает сообщения от всех серверов, которые с ним работают. Связывание объектов между собой оставляет одно сообщение вместо десятков.
• Дежурство и эскалация. Определите, кто отвечает на сообщения вне рабочего дня и что происходит, если ответа нет. Без правила передачи ночное уведомление ждёт утра, а вместе с ним ждёт и авария.
• Регулярный пересмотр. Раз в квартал разберите сработавшие оповещения: какие привели к работам, а какие оказались шумом. Первые оставьте, вторые перенастройте или отключите.

Отдельно проверяют работоспособность самой системы мониторинга. Она может перестать собирать данные и не подать ни одного сигнала — при сбое сервера мониторинга, переполнении очереди или ошибке в настройках. От этого слепого пятна защищает контрольный сигнал: система периодически отправляет тестовое сообщение во внешний сервис, и пропажа сигнала сама становится поводом для оповещения.

С чего начать мониторинг серверов и СХД

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

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

Расскажите о своей инфраструктуре — проведём аудит, составим перечень работ и посчитаем стоимость обслуживания.