Мониторинг аппаратной инфраструктуры в Zabbix
Студент научится настраивать сбор метрик (температура, статус портов, загрузка CPU) и создавать триггеры для раннего оповещения о сбоях.
Философия мониторинга: Проактивность против Реактивности
В методологии ITIL процесс управления инцидентами (Incident Management) направлен на быстрое восстановление работы. Но если вы узнаете о падении сервера от звонка разъяренного клиента — вы проиграли. Задача системного администратора — выстроить проактивный мониторинг. Вы должны узнать о деградации диска или росте температуры процессора до того, как сервер отключится.
Отраслевым стандартом мониторинга (особенно в Enterprise секторе) является система с открытым исходным кодом Zabbix. Zabbix умеет собирать данные (Метрики/Items) с любого оборудования, анализировать их по заданным логическим правилам (Триггеры/Triggers) и отправлять уведомления (Actions) в Telegram, почту или систему Service Desk.
Как Zabbix общается с железом: SNMP и IPMI
Чтобы забрать данные с операционной системы, устанавливают Zabbix Agent. Но как получить температуру процессора, если ОС зависла? Или как узнать статус портов на L2-коммутаторе, куда агента не установить? Используются аппаратные протоколы (Chunking):
1. IPMI (Intelligent Platform Management Interface): Протокол работы с BMC-чипом сервера (мы изучали его в уроке 5). Zabbix Server по сети подключается к выделенному порту управления сервера (iLO/iDRAC) и запрашивает датчики напрямую с материнской платы: обороты кулеров (RPM), статус блоков питания, температуру.
2. SNMP (Simple Network Management Protocol): Стандарт для сетевого оборудования (коммутаторы, роутеры, ИБП). Устройство хранит все свои параметры в виде древовидной базы данных — MIB (Management Information Base). Каждый параметр имеет уникальный OID (Object Identifier), например `1.3.6.1.2.1.2.2.1.8.1` (статус первого порта). Zabbix отправляет SNMP GET запрос по этому OID и получает ответ (Up/Down). Важно: В современных сетях следует использовать только SNMPv3, так как v1 и v2c передают Community String (пароль) в открытом виде.
Элементы данных (Items) и Триггеры (Triggers)
В терминологии Zabbix:
- Item (Элемент данных): Это метрика. То, что мы собираем. Например: 'Загрузка CPU', 'Температура в коридоре', 'Свободное место на диске C:'. Item просто складирует числа в базу данных.
- Trigger (Триггер): Это логическое выражение, которое оценивает собранные данные. Если условие триггера выполняется (становится TRUE), генерируется проблема (Problem).
Борьба с Alert Fatigue (Усталостью от алертов): Частая ошибка новичков — писать слишком простые триггеры. Например: last(/Server/temp) > 80 (Если последнее значение температуры > 80). Процессор может скакнуть до 85 градусов на 1 секунду во время компиляции. Вы получите алерт, а через секунду он закроется (Flapping). Если админ получает 100 ложных алертов в день, он перестает на них реагировать.
Правильный подход — использовать функции агрегации: min(/Server/temp, 5m) > 80. Это означает: генерировать алерт только если МИНИМАЛЬНОЕ значение за последние 5 минут стабильно держится выше 80 градусов. Это реальная проблема.
Задание
Сценарий (Problem-Based Learning): Вы настраиваете мониторинг аппаратного RAID-контроллера на критически важном сервере баз данных. Контроллер через SNMP отдает статус массива (Item: 'RAID Status'). Значение 1 означает 'Optimal' (все хорошо), значение 2 означает 'Degraded' (вылетел диск), значение 3 означает 'Failed' (массив разрушен). Вам нужно составить логику триггера.
- Определить Item, с которого собираются данные (например, `raid.status`).
- Понять, что нормальное состояние — это только 1. Любое другое значение (2 или 3) — это проблема.
- Написать условие триггера, которое сработает, если последнее полученное значение не равно 1.
- Установить высокую важность (Severity = High) для этого триггера, так как деградация RAID требует немедленной замены диска.
Архитектура Zabbix в распределенных сетях (Zabbix Proxy)
Если у вас один офис — Zabbix Server справится сам. Но что если у вас ЦОД в Москве, филиал в Казани и защищенный сегмент сети (DMZ) без прямого доступа в интернет? Открывать порты от каждого сервера из Казани до Москвы небезопасно и сложно в администрировании.
Для решения этой задачи применяется Zabbix Proxy. Это легковесный демон, который устанавливается в удаленном сегменте сети.
Как это работает: Все коммутаторы, серверы и ИБП в филиале в Казани отправляют свои метрики на локальный Zabbix Proxy. Proxy собирает эти данные, буферизует их у себя в локальной базе данных, и затем пакетом по одному зашифрованному каналу передает на центральный Zabbix Server в Москве. Если канал связи между Москвой и Казанью упадет, Proxy будет копить данные. Когда связь восстановится, он передаст историю, и на графиках не будет 'дыр'.