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

Алерт vfs.fs.size[C:,free]=0 бесполезен: база и IIS уже мертвы. На WS-042 держите два слоя: Warning по свободному проценту/гигабайтам с учётом размера тома и Disaster по timeleft()/forecast() — «при текущем тренде кончится через N часов». Не один порог 5% на том 100 ГБ и на том 10 ТБ. Шум: ложные алерты. Молчание триггера: не срабатывает. Linux inode отдельно: Linux server.

Сервер опроса 10.0.20.50, PSK psk-ws042, UI zabbix.example.

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

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

  • тикет от пользователей «диск полный», в Problems пусто или только что открылось;
  • триггер last(/WS-042/vfs.fs.size[C:,pfree])<1 — слишком поздно;
  • каждую ночь Warning на / из-за backup, утром OK;
  • tmpfs/overlay в LLD орёт раньше системного диска.

Отличия:

ПоведениеКуда
Нет item дискаLLD фильтр/агент
Item есть, триггер молчитexpression/maintenance
Алерт есть, но поздноэтот материал
Алерт на мусорных FSLLD

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

  1. Только порог 0 или 1% pfree.
  2. Нет учёта inode (vfs.fs.inode[/,pfree]): байты есть, файлов нет.
  3. Интервал item 1h — тренд бесполезен, дырка между точками.
  4. timeleft на короткой истории после создания item (мало точек).
  5. Рост логами ночью не попадает в avg днём.
  6. Триггер на C: а заполняется D:\data.
  7. Редко: квота пользователя, Zabbix видит свободно, приложение нет.

Диагностика

1. Что реально собирается

zabbix_get -s 10.0.20.42 -p 10050 -k 'vfs.fs.size[C:,pfree]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk
zabbix_get -s 10.0.20.42 -p 10050 -k 'vfs.fs.size[C:,free]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

Linux:

zabbix_get -s 10.0.20.42 -p 10050 -k 'vfs.fs.size[/,pfree]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk
zabbix_get -s 10.0.20.42 -p 10050 -k 'vfs.fs.inode[/,pfree]' \
  --tls-connect psk --tls-psk-identity psk-ws042 \
  --tls-psk-file /etc/zabbix/psk-ws042.psk

Latest data: есть ли free, pfree, inode. График 7 дней: линейный рост или ступеньки backup.

2. Текущий expression

Если last()<1 pfree — вот почему «поздно». Если min(5m)<10 на 10 ТБ — вот почему шум.

3. История для timeleft

timeleft в 6.0/7.0 требует достаточный период в expression (например 1h–1d данных). Сразу после link template функция нестабильна — не считайте «не работает навсегда».

Решение

Сценарий A. Двухступенчатые пороги по макросам

На шаблоне макросы {$VFS.FS.PFREE.MIN.WARN} / CRIT, override на больших томах. Пример духа (цифры подставьте после графика):

max(/WS-042/vfs.fs.size[{#FSNAME},pfree],5m)<{$VFS.FS.PFREE.MIN.WARN}

Для тома данных 8 ТБ: warn при free < 200G (абсолют), не 5%.

max(/WS-042/vfs.fs.size[D:,free],5m)<200G

Суффиксы единиц в trigger 6.0/7.0 поддерживаются в expression — не пишите сырые байты руками, если можно 200G.

Сценарий B. Тренд timeleft

Идея: PROBLEM если при текущем тренде место кончится быстрее SLO (например 24h):

timeleft(/WS-042/vfs.fs.size[C:,pfree],1h,0)<1d

Уточните параметры функции по документации вашей minor 6.0/7.0 (порядок аргументов timeleft/forecast). Проверьте Test trigger на реальной истории. Recovery: timeleft снова > 3d, hysteresis чтобы не флапать.

Сценарий C. Inode

Отдельный триггер vfs.fs.inode[/,pfree]<10. Иначе «байты есть, postfix не принимает почту».

Сценарий D. Интервал сбора

Для системного тома 5m достаточно. 1h — слепые к взрыву логов. Не 10s — NVPS.

Сценарий E. Нужный том

SQL/backup path мониторить явно, не надеяться что LLD видит все mount. Windows: C: и том данных. Linux: /, /var, /var/lib/postgresql.

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

На стенде заполните том тестовым файлом до Warning, не до 0. PROBLEM должен открыться до отказа службы. Сотрите файл — OK по hysteresis. Inode: много мелких файлов на стенде. В проде: инцидент «логи раздулись» за сутки должен дать Warning вечером, не утром «SQL не стартует».

Не тестируйте заполнением боевой C: до нуля.

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

  • timeleft неизвестен: мало истории или функция не на том item type.
  • Алерт есть, никто не смотрит Warning — карта алертов/severity.
  • Заполняется snapshot/VSS теневое, pfree врёт относительно «для пользователя» — смотрите том теней отдельно.
  • Квоты NTFS.

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

  • Макросы порогов по классу хоста (DC, SQL, файловый).
  • Не хранить backup на том же томе, что OS, без отдельного триггера.
  • LLD только боевых FS.
  • Runbook: что удалять при Warning (логи, не NTDS).

Разделите тома по смыслу. Система C: или / предупреждает раньше: логи и обновления убивают ОС. Том данных SQL — абсолютные гигабайты и timeleft, потому что пять процентов от 8 ТБ бессмысленны. Том backup — возраст копии важнее pfree: место может быть, job уже красный. Не один LLD-прототип с макросом 10% на все FS.

Пилиобразный график (ночь чистит, день пишет) ломает timeleft: функция решает, что место не кончится никогда. Тогда алерт на рост за шесть часов больше N гигабайт плюс абсолютный пол. Не отключайте timeleft глобально из-за одного тома — override макроса на хосте.

Inode на Linux убивает почту и PHP при живом df -h. Если в шаблоне только байты, вы повторите классический инцидент. В runbook df -i стоит рядом с df -h, и в Zabbix так же.

FAQ

Почему не достаточно 10% на всех?

Потому что 10% от 100 ГБ и от 20 ТБ — разный смысл. База порогов — как CPU, см. пороги.

forecast vs timeleft

Обе смотрят тренд. Выберите одну на шаблон, протестируйте на реальном графике, не обе с одним порогом (дубль).

Можно ли алертить только timeleft?

Опасно на плоском графике: тренд «никогда не кончится», а потом копируют 400 ГБ за час. Нужен абсолютный пол.

Windows pagefile на C:

Рост pagefile съедает C:. Мониторьте C: и не держите pagefile+data+backup вместе без порогов.

Агент не видит новый диск D:

LLD фильтр или ждать discovery interval. Check now на discovery rule.

0 байт всё равно нужен как Disaster?

Как последний рубеж — да, но он не заменяет Warning. Если дошёл до 0 — процесс мониторинга опоздал, разберите почему.