Мониторинг дисков в Zabbix: от стандартных шаблонов до кастомных триггеров

Быстрый старт: импорт стандартных шаблонов и первые метрики

Zabbix 6.0 LTS и 7.0 поставляются с готовыми шаблонами для мониторинга файловых систем. Чтобы увидеть первые данные о дисках, достаточно импортировать шаблон и привязать его к хосту. Процесс занимает не более пяти минут.

Начните с проверки: Zabbix-агент должен быть установлен на целевом сервере и подключен к серверу мониторинга. Без агента стандартные шаблоны не соберут метрики - в отличие от SNMP-подходов, которые мы разберем в кейсе с Hikvision.

Импорт шаблона и привязка к хосту

Перейдите в раздел Configuration → Templates. Нажмите Import в правом верхнем углу, выберите XML-файл шаблона. Для Linux-серверов используйте Template OS Linux by Zabbix agent, для Windows - Template OS Windows by Zabbix agent. Эти шаблоны уже присутствуют в свежих установках Zabbix, импорт нужен только если вы их ранее удалили или хотите обновить.

После импорта откройте Configuration → Hosts, выберите целевой узел сети и перейдите на вкладку Templates. Нажмите Select, найдите шаблон по имени и добавьте его. Через 60 секунд (интервал обновления по умолчанию) начнут поступать данные. Проверьте их в Monitoring → Latest data, отфильтровав по хосту.

Если данные не появились, проверьте лог Zabbix-агента: tail -f /var/log/zabbix/zabbix_agentd.log. Частая причина - агент не перезапущен после изменения конфигурации или брандмауэр блокирует порт 10050.

Какие метрики доступны «из коробки»

Стандартный шаблон собирает метрики через ключи Zabbix-агента, работающие на уровне ядра. Основные элементы данных:

• vfs.fs.size[fs,] - общий объем, свободное и занятое место в байтах и процентах для каждой примонтированной файловой системы
• vfs.fs.inode[fs,] - количество использованных и свободных индексных дескрипторов
• vfs.dev.read[device,] и vfs.dev.write[device,] - операции чтения/записи, количество секторов и байт

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

Для углубленного мониторинга дискового пространства в Linux-системах с альтернативными инструментами - Prometheus, Netdata и Grafana - обратитесь к сравнительному руководству по выбору системы мониторинга.

LLD-обнаружение дисков: как Zabbix видит ваши устройства

Low-Level Discovery (LLD) автоматически находит все диски и разделы на хосте и создает элементы данных, триггеры и графики для каждого из них. Без LLD пришлось бы вручную описывать каждый раздел на каждом сервере - на практике это нерабочий подход для инфраструктуры из десятков узлов с разной конфигурацией дисков.

Принцип работы LLD в Zabbix

Механизм состоит из трех компонентов: правило обнаружения, прототипы элементов данных и прототипы триггеров. Правило выполняет ключ агента, который возвращает JSON с перечнем объектов. Для файловых систем это ключ vfs.fs.discovery.

Пример JSON, возвращаемого агентом на Linux-хосте:

[
  {"{#FSNAME}":"/", "{#FSTYPE}":"ext4"},
  {"{#FSNAME}":"/boot", "{#FSTYPE}":"ext4"},
  {"{#FSNAME}":"/var", "{#FSTYPE}":"xfs"},
  {"{#FSNAME}":"/home", "{#FSTYPE}":"ext4"}
]

Zabbix проходит по каждому объекту JSON и на основе прототипов создает реальные элементы данных. В прототипе вы указываете ключ с макросом, например vfs.fs.size[{#FSNAME},pused]. При обнаружении раздела /var Zabbix подставит макрос и создаст элемент vfs.fs.size[/var,pused].

Интервал обнаружения по умолчанию - 1 час. Для динамичных сред, где разделы могут перемонтироваться, уменьшите его до 15-30 минут в настройках правила обнаружения. Учитывайте, что частое выполнение создает дополнительную нагрузку на агент.

Настройка фильтров для исключения ненужных разделов

Без фильтрации Zabbix создаст элементы для временных файловых систем, loop-устройств и системных разделов cgroups. Это зашумляет мониторинг и расходует ресурсы сервера. Фильтры настраиваются в правиле обнаружения на вкладке Preprocessing или Filters.

Практический пример фильтра для Linux:

• Исключить файловые системы с типом tmpfs, devtmpfs, squashfs
• Исключить точки монтирования, начинающиеся с /sys/, /proc/, /run/
• Исключить loop-устройства: макрос {#FSNAME} не должен совпадать с регулярным выражением ^/dev/loop

Для Windows-хостов фильтруйте по букве диска, исключая съемные носители, если они не критичны. Используйте регулярное выражение в поле Filters: выберите макрос {#FSNAME}, оператор «does not match» и шаблон ^[C-F]: для включения только основных разделов.

Подключаем SMART: получение данных через smartctl

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) - встроенная в накопители система самодиагностики. Она фиксирует десятки атрибутов: от температуры до количества переназначенных секторов. Zabbix не умеет читать SMART напрямую, поэтому мы используем утилиту smartctl из пакета smartmontools и передаем данные через пользовательские параметры агента.

Установка и настройка smartmontools

Установите пакет на целевой хост:

# Debian/Ubuntu
apt install smartmontools -y

# CentOS/RHEL/AlmaLinux
yum install smartmontools -y

Проверьте доступность дисков:

smartctl --scan

Вывод покажет все блочные устройства с поддержкой SMART. Для каждого диска выполните тестовый запрос:

smartctl -A /dev/sda

Zabbix-агент по умолчанию работает от пользователя zabbix, у которого нет прав на чтение SMART-данных. Добавьте в /etc/sudoers через visudo:

zabbix ALL=(ALL) NOPASSWD: /usr/sbin/smartctl

Без этого шага пользовательские параметры будут возвращать пустые значения или ошибки доступа.

Создание пользовательских параметров в Zabbix-агенте

Отредактируйте конфигурационный файл агента /etc/zabbix/zabbix_agentd.conf и добавьте строки:

UserParameter=smart.attr[*],sudo smartctl -A /dev/$1 | grep -w "$2" | awk '{print $$NF}'
UserParameter=smart.temp[*],sudo smartctl -A /dev/$1 | grep Temperature_Celsius | awk '{print $$NF}'
UserParameter=smart.health[*],sudo smartctl -H /dev/$1 | grep -q "PASSED" && echo 1 || echo 0

Первый параметр принимает два аргумента: имя диска и номер SMART-атрибута. Например, smart.attr[sda,5] вернет значение атрибута Reallocated Sectors для диска /dev/sda. Второй возвращает температуру, третий - общий статус здоровья (1 - PASSED, 0 - FAILED).

Перезапустите агент:

systemctl restart zabbix-agent

Проверьте работу параметров с сервера Zabbix утилитой zabbix_get:

zabbix_get -s 192.168.1.100 -k smart.temp[sda]

Ключевые SMART-атрибуты для мониторинга

Из 200+ возможных атрибутов для предсказания отказов критичны 5-7. Они сигнализируют о механических проблемах, деградации поверхности или исчерпании ресурса ячеек памяти.

Для HDD появление даже одного переназначенного сектора (ID 5) - повод для замены диска в ближайшее время. Практика показывает: после первого ремапа лавинообразный рост происходит в течение недель, а не месяцев. Для SSD атрибуты 231 и 233 показывают оставшийся ресурс в процентах от заводского. Падение ниже 20% означает, что производитель гарантирует работоспособность, но риск отказа резко возрастает.

Если вы управляете NAS на TrueNAS или аппаратными RAID-массивами, настройка мониторинга SMART-атрибутов имеет особенности. Ознакомьтесь с руководством по настройке RAID-контроллеров с интеграцией в Zabbix - там разобраны политики кэширования и автоматизация замены дисков по SMART-триггерам.

Создание триггеров для раннего оповещения о деградации диска

Триггеры переводят сырые данные SMART в оповещения, которые реально предотвращают потерю данных. Правильно настроенный триггер срабатывает за дни или недели до полного отказа, оставляя время на плановую замену.

Триггеры для HDD: Reallocated Sectors, Spin Retry Count

Базовое выражение триггера для атрибута Reallocated Sectors Count (ID 5):

{host:smart.attr[sda,5].last()}>0

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

• Warning: значение > 0
• High: значение > 10 или прирост за сутки > 2

Для Spin Retry Count (ID 10) логика аналогична: любое ненулевое значение указывает на проблемы с механикой шпинделя. Диск пытается повторно раскрутиться - это предвестник заклинивания двигателя.

Триггеры для SSD: Wear Leveling Count, Media Wearout Indicator

SSD не имеют движущихся частей, но их ячейки памяти имеют ограниченный ресурс перезаписи. Атрибут Wear Leveling Count (ID 231) показывает оставшийся ресурс в процентах. Триггер:

{host:smart.attr[sda,231].last()}<20

Для дата-центровых SSD с интенсивной записью настройте предупреждение на уровне 30% и критический порог на 10%. Учитывайте, что разные производители по-разному нормализуют значения: у Samsung атрибут 177 (Wear Leveling Count) уменьшается от 100 к 0, у Intel атрибут 233 (Media Wearout Indicator) работает так же. Проверьте документацию к вашей модели.

Настройка порогов и уровней важности

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

• Information: температура HDD > 45°C, температура SSD > 65°C - не требует немедленной реакции, но фиксирует тренд
• Warning: Reallocated Sectors > 0, Wear Leveling < 30% - запланируйте замену в течение месяца
• High: Reallocated Sectors > 10, Current Pending Sectors > 0, Wear Leveling < 10% - замените диск при ближайшем обслуживании
• Disaster: SMART-статус FAILED, диск недоступен - немедленная замена

Привяжите разные уровни к разным каналам оповещений: Information - только дашборд, Warning - email, High и Disaster - Telegram или мессенджер дежурной смены. Готовые скрипты для интеграции Zabbix с Telegram и email-уведомлениями вы найдете в руководстве по автоматическому мониторингу дисков с уведомлениями.

Мониторинг заполнения разделов: предотвращаем переполнение

Переполнение дискового раздела - самая частая причина отказов сервисов после человеческих ошибок. База данных, не сумевшая записать транзакцию, веб-сервер, не создающий лог, контейнеризация, падающая из-за нехватки места в overlayfs - все это следствия отсутствия мониторинга свободного места.

Стандартные триггеры и их кастомизация

Шаблон Template OS Linux содержит триггеры на заполнение файловых систем с порогом 80% для предупреждения и 90% для критического уровня. Пороги управляются макросами:

• {$VFS.FS.PUSED.MAX.WARN} - порог предупреждения (по умолчанию 80)
• {$VFS.FS.PUSED.MAX.CRIT} - критический порог (по умолчанию 90)

Для разделов с логами, которые могут быстро заполняться, задайте индивидуальные пороги на уровне хоста. Откройте Configuration → Hosts, выберите хост, перейдите на вкладку Macros. Добавьте макрос {$VFS.FS.PUSED.MAX.WARN:/var/log} со значением 70 - так вы получите предупреждение раньше, чем стандартный триггер.

Для корневого раздела на серверах с большим объемом диска (от 500 ГБ) порог 80% может быть избыточным: 20% от 500 ГБ - это 100 ГБ свободного места, что достаточно для работы. Поднимите порог до 90% для предупреждения и 95% для критического уровня через макросы.

Мониторинг inode: когда место есть, но файлы не создаются

Исчерпание индексных дескрипторов (inode) - менее очевидная, но столь же критичная проблема. Файловая система может иметь гигабайты свободного места, но если закончились inode, создать новый файл невозможно. Симптомы: ошибки «No space left on device» при наличии свободного места в выводе df -h.

Стандартный шаблон включает элемент данных vfs.fs.inode[/,pused] и триггер с порогом 80%. Типичные сценарии исчерпания inode:

• Кэш сессий PHP, создающий миллионы мелких файлов в /tmp
• Почтовый сервер с очередью из сотен тысяч писем в /var/spool
• Docker, накапливающий слои образов и остановленные контейнеры

Проверьте текущее использование inode на хосте: df -i. Если какой-либо раздел использует более 50% inode при небольшом заполнении по объему, добавьте для него отдельный триггер с пониженным порогом.

Кейс: мониторинг дисков в регистраторах Hikvision

Регистраторы Hikvision работают на проприетарной ОС, установка Zabbix-агента на них невозможна. Мониторинг организуется через SNMP - протокол, который поддерживают все модели Hikvision с сетевым интерфейсом. Этот же подход применим к любому оборудованию без агента: коммутаторам, IP-камерам, ИБП.

Получение данных с регистратора по SNMP

Включите SNMP на регистраторе: Configuration → Network → Advanced Settings → SNMP. Задайте community string (аналог пароля) для SNMP v2c и укажите IP-адрес сервера Zabbix в списке разрешенных.

На сервере Zabbix установите утилиты SNMP:

apt install snmpwalk -y

Найдите OID, отвечающие за статус дисков. Для Hikvision они находятся в ветке HIKVISION-MIB. Выполните обход дерева:

snmpwalk -v2c -c public 192.168.1.200 1.3.6.1.4.1.39165

Вывод покажет OID для каждого диска: статус (Normal=1, Error=0), общая емкость, свободное место. Зафиксируйте числовые идентификаторы - они потребуются для создания элементов данных.

Создание шаблона и триггеров для Hikvision

Создайте новый шаблон в Configuration → Templates. Добавьте правило обнаружения типа SNMP agent с ключом snmp.discovery и OID, который возвращает список индексов дисков. Настройте прототипы элементов данных:

• Статус диска: SNMP agent, OID 1.3.6.1.4.1.39165.X.X.X.{#SNMPINDEX}, тип Integer
• Емкость диска: аналогично, OID для общего объема в мегабайтах

Прототип триггера для статуса:

{host:disk.status[{#SNMPINDEX}].last()}<>1

Триггер сработает, если статус диска отличается от «Normal». Дополните его триггером на свободное место с порогом 10% от общей емкости.

Привяжите шаблон к узлу сети, представляющему регистратор. Узел должен иметь интерфейс типа SNMP с корректным community string. Через несколько минут в Latest data появятся статусы всех дисков регистратора.

Для комплексного мониторинга кластерной инфраструктуры, включающей серверы хранения и обработки данных, используйте руководство по развертыванию Prometheus и Grafana для кластеров - там рассмотрены готовые дашборды для Ceph и Pacemaker.

Централизованный контроль: дашборды и отчеты

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

Построение дашборда для мониторинга дисков

Перейдите в Monitoring → Dashboards, создайте новый дашборд. Добавьте виджеты:

• Топ-10 дисков по температуре: тип «Top hosts», элемент данных - ваш SMART-ключ температуры, сортировка по убыванию. Сразу видно, где перегревается накопитель
• График заполнения разделов: тип «Graph (classic)», выберите несколько критичных разделов с разных хостов. Показывает тренд заполнения за неделю или месяц
• Список проблемных SMART-атрибутов: тип «Problems», фильтр по тегу «SMART» или имени триггера. Выводит только активные проблемы с дисками
• Общая статистика: тип «Clock» или «Plain text» с суммарным количеством дисков под мониторингом и числом дисков в статусе Warning/High

Разместите виджеты в логическом порядке: сверху - общая статистика, ниже - графики и топы, внизу - список активных проблем. Дашборд должен читаться за 10 секунд: именно столько времени у дежурного администратора на оценку ситуации.

Автоматические отчеты о состоянии дискового парка

Zabbix начиная с версии 6.0 поддерживает Scheduled Reports - PDF-отчеты, отправляемые по расписанию на email. Настройте еженедельный отчет для руководителя отдела инфраструктуры:

1. Administration → General → Scheduled Reports → Create report
2. Выберите дашборд, созданный на предыдущем шаге, в качестве источника
3. Задайте расписание: каждый понедельник в 9:00
4. Укажите получателей и тему письма: «Еженедельный отчет: состояние дискового парка»

В отчет попадут графики заполнения разделов за неделю, список дисков с проблемными SMART-атрибутами и прогноз: какие разделы достигнут критического порога в ближайшие 30 дней. Для прогнозирования используйте функцию тренда в триггерах: trendavg(1M) покажет среднюю скорость заполнения за месяц и предскажет дату достижения порога.

Для автоматизации реакции на инциденты с дисками - от создания тикета в Jira до запуска скрипта очистки логов - используйте готовые скрипты автоматизации на Python и Bash. Они интегрируются с Zabbix через Actions и внешние вызовы.