Короткий ответ

Один df -h на SQL01 не видит пул tank, inode и LVM thin. Сделайте набор рядов: (1) пул ZFS CAPACITY, (2) каждый dataset quota, (3) df -i, (4) lvs data_percent, (5) Windows volumes + VSS, (6) RAID VD свободное в ФС после expand. Пороги: предупреждение ~70–80% на ZFS пуле (раньше, чем на NTFS), critical до 90%, thin ещё строже. Алерт должен открывать тикет до остановки записи.

Связка с тонким пулом и снимками.

Симптомы и как отличить

Типичная картина:

  • мониторинг зелёный (C: 40% free), iSCSI LUN встал;
  • df ок, df -i 100%;
  • TrueNAS шлёт 90%, Zabbix молчит — разные системы;
  • вырос USEDSNAP, AVAIL в UI ещё «есть».

Если уже ENOSPC — сначала ёмкость, потом допишите алерт.

Возможные причины

  1. Смотрим только гостевой диск.
  2. Нет inode.
  3. Нет thin/zvol used.
  4. Порог 99%.
  5. Алерты в почте, которую не читают.
  6. Собрали df с /, забыли /var отдельный VG.

Диагностика

1. Ubuntu хост

df -hT
df -i
zpool list
zfs list -o name,used,avail,refer,quota,usedsnap -r tank
sudo lvs -o lv_name,data_percent,metadata_percent,lv_size 2>/dev/null

Скрипт мониторинга должен парсить эти поля, не HTML UI.

2. TrueNAS

Reporting + SNMP/TrueNAS API если есть в вашей версии. Минимум: pool capacity, dataset used, snapshot count. Shell для сверки.

3. Windows SQL01

Get-Volume | Format-Table DriveLetter, FileSystem, SizeRemaining, Size
Get-ClusterResource 2>$null
vssadmin list shadowstorage
Get-IscsiSession

Том CSV/кластер — отдельные счётчики, не только D:.

4. RAID

Свободное на vd0 = ФС. Контроллер не знает файлы. Расширение VD без extend NTFS = ложный «места нет» наоборот.

Решение

Сценарий A. Пороги

ОбъектWarnCrit
ZFS pool CAP75–80%90%
NTFS/ext4 том80%90–95%
inodes70%90%
LVM thin data70%85%
zvol used vs volsizeпо политикедо 90% пула

Не копируйте порог NAS на boot 20 ГБ.

Сценарий B. Что писать в алерт

Имя хоста NAS01, пул tank, CAP, AVAIL, топ dataset, число snap. Для thin — data_percent. Человек должен понять слой без SSH вслепую.

Сценарий C. Исключения

tmpfs, overlay, CD-ROM, /snap snapd — exclude, иначе шум. Не exclude /var/lib/docker если это прод.

Сценарий D. Проверка, что алерт живой

Раз в квартал: заполнить тестовый dataset или снизить порог на копии. Мёртвый webhook = нет контроля.

Сценарий E. Корреляция

Рост 5% в сутки на tank → тикет ёмкости, не ждать 90. Связь с планированием.

Минимальный набор графиков: CAP пула tank, AVAIL, USEDSNAP, data_percent thin, inode корня и /var, том D на SQL01, число PD против baseline, длительность последнего scrub и rebuild. Один дашборд storage, не пять писем с разными порогами.

Эскалация: warn — задача на неделю (снимки, архив), crit — инцидент с остановкой некритичных writer. Не одинаковый пейджер на 81 процент архивного пула и на 81 процент SQL LUN.

Раз в месяц проверяйте, что агент жив. Исключение overlay Docker не должно скрыть реальный /var. Документируйте список exclude, иначе через год никто не знает, почему диск 100 процентов молчит.

Как проверить, что проблема устранена

Тестовый алерт сработал и дошёл. Дашборд показывает пул и гостя раздельно. Инсценировка: заполнили lab-том — тикет. После реальной уборки алерт закрылся. df -i в том же dashboard.

Если не помогло

  • Шум каждую ночь backup: отдельные пороги/maintenance window, не disable.
  • SNMP не отдаёт ZFS: агент/версия, перейдите на script zpool.
  • Windows 0 байт на thin: добавьте метрику NAS, не ещё один df.
  • Иноды закончились при зелёном df: добавили -i слишком поздно — статья уже про аварии.

Профилактика

  • Карта томов: что где живёт (SQL LUN, share, backup).
  • Retention снимков как код.
  • fstrim в графике (indirect).
  • Review порогов после расширения массива (забывают поднять, или наоборот).
  • Ответственный за NAS01 в oncall.

Проверка ложных зелёных: скрипт раз в сутки сравнивает zpool list CAP с порогом и шлёт, даже если node_exporter по /mnt/tank/share показывает квоту, а не пул. Два независимых источника на критичный NAS01.

Для inode отдельный график на каталогах с миллионами мелких файлов (маил, 1С кэш, web sessions). df -h там врёт годами. Порог 70 процентов inode даёт время на чистку или новый dataset.

Не забудьте том boot TrueNAS и C: гипервизора: они не tank, но кладут весь NAS, когда логи middleware забивают 16 ГБ. Алерт на них мельче порогом, но обязателен.

Добавьте синтетический probe записи: маленький файл в шару и в SQL temp, раз в N минут, с алертом на ошибку ENOSPC/EROFS. Графики CAP запаздывают, probe ловит «уже нельзя писать» раньше пользователя. Не делайте probe на 1 ГБ, хватит килобайт.

Храните inventory томов в том же репозитории, что алерты: иначе порог 80 процентов висит на переименованном dataset и молчит на новом tank/share2.

Порог без имени хоста в тексте алерта бесполезен ночью: пишите NAS01 tank CAP, не «Filesystem usage». Иначе дежурный полезет не на тот сервер и потеряет час.

Проверяйте часовой пояс графиков: смена UTC ломает корреляцию backup-окна и скачка CAP, и вы лечите «утечку», которой нет.

FAQ

Хватит ли TrueNAS встроенных alert 80%?

Как база — да. Добавьте thin/zvol и inode на Linux-клиентах.

Prometheus node_exporter достаточно?

node_filesystem не знает zpool CAP как ZFS. Нужен zfs exporter или script.

Алерт на 50% для архивного HDD?

Можно выше, если рост нулевой. Политика по SLA.

Нужен ли контроль RAID spare?

Да: spare отсутствует = риск, это не байты, но тот же dashboard storage.

df в cron на почту?

Лучше чем ничего, хуже метрик с порогом. Не единственный канал.