Как мониторить «пропадающие» диски в Proxmox через Zabbix — даже если SMART чист

Иногда Proxmox (а точнее — ядро Linux) отключает или перемонтирует диск в режим «только чтение», даже если smartctl -a показывает, что всё «в норме». Причина — не физическая поломка, а таймауты I/O, сбои питания, плохой кабель или «зависания» диска.

SMART не увидит этого! Зато Zabbix — увидит, если правильно настроить.

Важно: Эта заметка — стартовый набор. Настрой, проверь, потом дополни под свои диски и серверы.

1. Ловим ошибки I/O в ядре (dmesg / journalctl)

Ядро пишет об ошибках в /var/log/kern.log или в journalctl. Ищем ключевые фразы: I/O error, timeout, reset failed.

Способ A: Лог-мониторинг через Zabbix (просто и мощно)

Добавь в Zabbix такой item:

Name: I/O errors in kernel log (active)
Type: Zabbix agent (active)
Key: logrt[/var/log/kern\.log,"(I/O error|timeout|reset failed|failed command|Buffer I/O error)",,skip]
Type of information: Log

Этот item не даёт число, но срабатывает как событие. Его можно использовать в триггере:

{host:logrt[/var/log/kern\.log,"(I/O error|timeout|reset failed|failed command|Buffer I/O error)",,skip].nodata(5m)}=0

Способ B: Счётчик ошибок за последние N минут (удобнее для графиков)

Создай скрипт:

#!/bin/bash
# /usr/local/bin/count_io_errors.sh
exec journalctl -k --since "5 minutes ago" 2>/dev/null | \
  grep -ciE "(I/O error|ata.*timeout|reset failed|failed command|Buffer I/O error)"

Сделай исполняемым:

chmod +x /usr/local/bin/count_io_errors.sh

Добавь в /etc/zabbix/zabbix_agentd.d/userdisks.conf:

UserParameter=custom.io.error.recent, /usr/local/bin/count_io_errors.sh

Item в Zabbix:

Name: Recent I/O errors (last 5 min)
Key: custom.io.error.recent
Type: Zabbix agent
Type of info: Numeric (unsigned)
Update interval: 5m

Триггер:

{host:custom.io.error.recent.last()}>0

2. Проверяем, смонтирован ли диск

Proxmox мог отмонтировать ФС, но диск остался «жив».

# /etc/zabbix/zabbix_agentd.d/userdisks.conf
UserParameter=custom.mount.check[*], if mountpoint -q "$1"; then echo 1; else echo 0; fi

Item:

Name: Mount status: /mnt/data
Key: custom.mount.check[/mnt/data]
Type: Numeric (unsigned)

Триггер:

{host:custom.mount.check[/mnt/data].last()}=0

3. SMART — всё равно читаем (на всякий)

Даже если сейчас чисто — читаем атрибуты раз в 6 часов.

Пример для Reallocated_Sector_Ct:

# /etc/zabbix/zabbix_agentd.d/userdisks.conf
UserParameter=smart.realloc[*], sudo smartctl -A $1 | awk '/Reallocated_Sector_Ct/{print $10}'
UserParameter=smart.temp[*], sudo smartctl -A $1 | awk '/Temperature_Celsius/{print $10}'

Не забудь дать права Zabbix'у:

echo "zabbix ALL=(ALL) NOPASSWD: /usr/sbin/smartctl" | sudo tee /etc/sudoers.d/zabbix-smart

Item:

Name: SMART Reallocated (sdb)
Key: smart.realloc[/dev/sdb]

Триггер (если значение > 0):

{host:smart.realloc[/dev/sdb].last()}>0

4. Дополнительно: проверка наличия диска в системе

Иногда диск исчезает из /dev. Проверим:

UserParameter=custom.disk.exists[*], if [ -b "$1" ]; then echo 1; else echo 0; fi

Item:

Key: custom.disk.exists[/dev/sdb]

Триггер:

{host:custom.disk.exists[/dev/sdb].last()}=0

Что делают профи?

• Не полагаются только на SMART. Он — для предсказания поломки, а не для отлова таймаутов.
• Мониторят ядро. Большинство реальных проблем — в dmesg.
• Используют «защиту от дурака»: триггер на отмонтирование + триггер на I/O ошибки.
• Проверяют железо: SATA-кабель, блок питания, температуру.

Совет: Если диск «отваливается» — сначала замени SATA-кабель. Это решает 60% подобных проблем.

Что делать дальше?

1. Разверни эти item'ы на одном тестовом хосте.
2. Проверь, что скрипты работают от пользователя zabbix:

sudo -u zabbix /usr/local/bin/count_io_errors.sh

3. Настраивай триггеры с уведомлениями.
4. Добавь графики — будет видно, как растёт нагрузка перед сбоем.

Удачи! И помни: если Linux перемонтировал диск в ro — он что-то видел. Надо искать в логах, а не в SMART.