Гайд по настройке оповещений о заполнении диска в TrueNAS Scale и Core

Переполнение пула ZFS в TrueNAS приводит к деградации производительности, отказу в записи и риску повреждения метаданных. Восстановление файловой системы после инцидента может занять часы, а часть данных окажется потерянной безвозвратно. Этот гайд даёт готовую конфигурацию алертов: email-уведомления, интеграцию с Telegram и Slack через Webhook, корректные пороги ZFS Pool capacity и фильтрацию ложных срабатываний на снапшотах.

Материал проверен на TrueNAS Scale 24.10 и TrueNAS Core 13.3. Все команды и пути в интерфейсе актуальны на июль 2026 года. Вы получите работающую схему мониторинга за 30-40 минут, следуя инструкциям по порядку.

Зачем нужны оповещения о заполнении диска в TrueNAS

ZFS использует копирование при записи (Copy-on-Write). При заполнении пула выше 80% механизм вынужден искать свободные блоки среди фрагментированного пространства. Скорость операций падает экспоненциально. На отметке 95-98% пул переходит в режим только чтения, а при 100% возможна паника ядра и потеря пула.

Встроенная система алертов TrueNAS отслеживает занятость пула и отправляет предупреждения. Проблема в том, что стандартные пороги не всегда соответствуют вашим сценариям, а снапшоты маскируют реальную картину. Правильная настройка решает три задачи:

• Раннее предупреждение: вы узнаете о росте занятости до того, как он повлияет на сервисы.
• Точность данных: исключение снапшотов из расчёта показывает фактическое использование.
• Доставка в нужный канал: email для отчётов, Telegram/Slack для срочных инцидентов.

Перед настройкой оповещений убедитесь, что базовые компоненты TrueNAS работают корректно. Если вы только развернули систему, обратитесь к сравнению NAS-решений для выбора подходящей платформы и к руководству по настройке сетевого доступа для корректной работы SMB/NFS.

Настройка email-уведомлений в TrueNAS Scale и Core

Email остаётся базовым каналом доставки алертов. TrueNAS отправляет через него предупреждения о состоянии пулов, сбоях дисков, ошибках SMART и завершении задач репликации. Настройка SMTP обязательна, даже если вы планируете использовать Telegram или Slack как основной канал - почта служит резервным транспортом.

Настройка SMTP в TrueNAS Scale

В TrueNAS Scale интерфейс алертов унифицирован. Путь к настройкам: System Settings → Alerts → Email.

Заполните поля:

• From Email: адрес отправителя, например truenas-alert@example.com. Почтовые серверы часто проверяют SPF/DKIM для этого адреса, используйте реальный ящик.
• Outgoing Mail Server: SMTP-хост. Для Gmail - smtp.gmail.com, для Яндекс.Почты - smtp.yandex.ru.
• Port: 587 (STARTTLS) или 465 (SSL). Порт 25 заблокирован большинством облачных провайдеров и домашних ISP.
• Security: выберите STARTTLS для порта 587 или SSL для 465.
• Authentication: включите и укажите логин/пароль. Для Gmail требуется создать пароль приложения в настройках аккаунта (раздел «Безопасность → Двухфакторная аутентификация → Пароли приложений»).

Нажмите Send Test Email. Если письмо не пришло, проверьте лог в System Settings → Alerts → Alert Settings → Show Alert Logs. Типичная ошибка - неверный пароль приложения или блокировка порта на уровне фаервола. Убедитесь, что TrueNAS может разрешить DNS-имя SMTP-сервера и установить исходящее соединение.

Настройка SMTP в TrueNAS Core

В TrueNAS Core путь короче: System → Email. Интерфейс похож, но есть нюанс с Root Email - это адрес, на который система отправляет критические алерты уровня безопасности.

Заполните те же поля: From Email, Outgoing Mail Server, Port, Security, Authentication. Для корпоративного Exchange-сервера укажите внутренний IP и порт 587. После сохранения нажмите Send Test Email.

Частая проблема в Core - отсутствие маршрута до внешнего SMTP из jail-окружения. Проверьте сетевые настройки: Network → Global Configuration, поля Default Gateway и DNS Servers. Без корректного шлюза исходящая почта не уйдёт.

Интеграция с Telegram и Slack через Webhook

Webhook-интеграции доставляют алерты за 1-3 секунды против 15-60 секунд у email. Это критично для инцидентов, требующих немедленной реакции, например, при достижении Critical-порога пула. TrueNAS Scale поддерживает Webhook нативно, в Core потребуется скрипт.

Настройка Telegram-бота и получение Webhook URL

Откройте Telegram и найдите @BotFather. Отправьте команду /newbot, укажите имя и username бота. В ответ получите токен - строку вида 123456:ABC-DEF1234ghikl-zyx57W2v1u123ew11. Сохраните токен, он потребуется для URL.

Теперь получите chat_id. Найдите @getidsbot, нажмите Start и перешлите любое сообщение из целевого чата или группы. Бот вернёт числовой идентификатор. Для личных сообщений chat_id совпадает с вашим user ID.

Сформируйте Webhook URL:

https://api.telegram.org/bot<токен>/sendMessage?chat_id=<chat_id>&text=<сообщение>

TrueNAS подставит текст алерта в параметр text автоматически при использовании переменных. Готовый URL выглядит так:

https://api.telegram.org/bot123456:ABC-DEF1234ghikl-zyx57W2v1u123ew11/sendMessage?chat_id=123456789

Добавление Webhook в TrueNAS Scale

Перейдите в System Settings → Alerts → Alert Services → Add. Выберите тип Slack (он универсален для Webhook). Заполните:

• Name: произвольное имя, например Telegram Alerts.
• Webhook URL: ваш URL из предыдущего шага.
• Channel: для Telegram не используется, оставьте пустым или введите любой текст.

Нажмите Send Test Alert. В течение 2-5 секунд бот отправит сообщение в чат. Если тест не проходит, проверьте доступность api.telegram.org из сети TrueNAS командой curl -I https://api.telegram.org в Shell.

Для Slack процесс аналогичен: создайте Incoming Webhook в настройках рабочего пространства Slack, скопируйте URL и вставьте в поле Webhook URL. Канал укажите в формате #alerts.

Альтернативы для TrueNAS Core

TrueNAS Core не имеет встроенного меню Alert Services. Используйте раздел Tasks → Init/Shutdown Scripts или Cron Jobs для запуска кастомного скрипта. Пример скрипта для отправки в Telegram:

#!/bin/bash
TOKEN="123456:ABC-DEF1234ghikl-zyx57W2v1u123ew11"
CHAT_ID="123456789"
POOL="tank"
CAPACITY=$(zpool list -H -o cap $POOL | tr -d '%')
if [ $CAPACITY -ge 80 ]; then
  MESSAGE="Критическое заполнение пула $POOL: $CAPACITY%"
  curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT_ID -d text="$MESSAGE"
fi

Сохраните скрипт в /root/scripts/check_pool.sh, дайте права chmod +x и добавьте в Cron Jobs с интервалом 5-15 минут. Этот метод работает и в Scale, если нужна более тонкая логика, чем стандартные алерты.

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

Настройка порогов заполнения ZFS Pool capacity

ZFS Pool capacity - метрика, показывающая процент занятого пространства пула относительно общего размера. TrueNAS использует её для генерации предупреждений (Warning) и критических алертов (Critical). Пороги задаются индивидуально для каждого пула.

Путь в TrueNAS Scale: Storage → Pools → выберите пул → Settings (шестерёнка) → Edit Pool Options. Путь в TrueNAS Core: Storage → Pools → выберите пул → Edit Options.

Поля для настройки:

• Pool Capacity Warning: процент, при котором генерируется предупреждение.
• Pool Capacity Critical: процент для критического алерта.

Рекомендованные значения порогов для разных сценариев

Не выставляйте Warning ниже 60% - это генерирует шумовые алерты и снижает внимание к реальным проблемам. Не поднимайте Critical выше 90% - после этой отметки ZFS может не справиться с дефрагментацией при удалении данных.

Фильтрация ложных срабатываний на снапшотах

Снапшоты ZFS хранят копии изменённых блоков. При удалении файла снапшот продолжает удерживать его блоки, поэтому общий объём занятого пространства (USED) не уменьшается. Стандартный алерт TrueNAS смотрит на USED и может сообщить о заполнении 80%, хотя реальные данные занимают 50%, а остальное - старые снапшоты.

Решение: мониторить метрику usedbydataset вместо used. Она исключает пространство, занятое только снапшотами.

Анализ реального использования пространства с помощью ZFS команд

Подключитесь к Shell TrueNAS и выполните:

zfs list -o space -r tank

Вывод содержит колонки:

• AVAIL: доступное пространство.
• USED: общее занятое, включая снапшоты.
• USEDSNAP: занято только снапшотами.
• USEDDS: занято данными датасета (без снапшотов).
• USEDREFRESERV: зарезервировано под refreservation.
• USEDCHILD: занято дочерними датасетами.

Для расчёта реального заполнения используйте формулу: (USED - USEDSNAP) / (USED + AVAIL) * 100. Пример для пула tank с USED=8T, USEDSNAP=3T, AVAIL=2T: реальное заполнение = (8-3)/(8+2)*100 = 50%. Стандартный алерт показал бы 80% и создал ложную тревогу.

Настройка кастомных алертов на основе usedbydataset

Создайте скрипт, который проверяет usedbydataset и отправляет уведомление только при реальном заполнении:

#!/bin/bash
POOL="tank"
WARNING=70
CRITICAL=80
TOKEN="123456:ABC-DEF1234ghikl-zyx57W2v1u123ew11"
CHAT_ID="123456789"

# Получаем значения
USED=$(zfs get -Hp -o value used $POOL)
USEDSNAP=$(zfs get -Hp -o value usedbysnapshots $POOL)
AVAIL=$(zfs get -Hp -o value available $POOL)

# Реальное использование в процентах
REAL_USED=$(( (USED - USEDSNAP) * 100 / (USED + AVAIL) ))

if [ $REAL_USED -ge $CRITICAL ]; then
  curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d chat_id=$CHAT_ID \
    -d text="КРИТИЧЕСКОЕ заполнение $POOL: $REAL_USED% (без снапшотов)"
elif [ $REAL_USED -ge $WARNING ]; then
  curl -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \
    -d chat_id=$CHAT_ID \
    -d text="Предупреждение: заполнение $POOL: $REAL_USED% (без снапшотов)"
fi

Добавьте скрипт в System Settings → Advanced → Cron Jobs (Scale) или Tasks → Cron Jobs (Core) с интервалом 15 минут. Стандартные алерты пула можно оставить включёнными как дополнительный уровень контроля.

Для отслеживания удаления снапшотов и других критичных операций с ZFS настройте аудит через интеграцию auditd с SIEM-системой.

Тестирование и проверка работы оповещений

После настройки любого канала доставки обязательно проведите тестирование. Встроенная кнопка Send Test Alert проверяет только связность, но не логику срабатывания по порогам. Нужна симуляция реального заполнения.

Симуляция заполнения пула для проверки алертов

Создайте временный файл, который займёт достаточно места для пересечения порога Warning:

# Узнайте текущее свободное место и рассчитайте размер файла
zfs list -o avail tank
# Создайте файл, который заполнит пул до нужного процента
dd if=/dev/zero of=/mnt/tank/test_alert_file bs=1M count=50000

Подберите count так, чтобы занятость превысила Warning-порог. После срабатывания алерта удалите файл:

rm /mnt/tank/test_alert_file

Проверьте логи алертов: System Settings → Alerts → Alert Settings → Show Alert Logs (Scale) или значок колокольчика в правом верхнем углу (Core). Убедитесь, что событие зафиксировано с правильным уровнем (Warning/Critical) и текстом.

Для теста Webhook запустите скрипт вручную из Shell и проверьте доставку в мессенджер. Если сообщение не пришло, выполните curl с флагом -v для диагностики:

curl -v -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" -d chat_id=$CHAT_ID -d text="test"

Ошибка 403 означает неверный токен, 400 - неверный chat_id, таймаут соединения - сетевую проблему или блокировку API на уровне провайдера.

Типичные проблемы и их решение

Собраны проблемы, с которыми сталкиваются администраторы при настройке оповещений в TrueNAS, и способы их устранения.

Email не отправляется, тест падает с ошибкой «Connection timed out». Причина: порт 25 или 587 заблокирован исходящим фаерволом. Решение: используйте порт 465 с SSL или настройте SMTP-релэй внутри сети. Проверьте доступность порта: nc -zv smtp.gmail.com 587.

Email уходит, но попадает в спам. Причина: отсутствие SPF/DKIM для адреса отправителя. Решение: настройте SPF-запись для домена, указанного в From Email, или используйте SMTP-сервер с уже настроенной репутацией (Gmail, SendGrid).

Webhook возвращает ошибку 400 Bad Request. Причина: неверный формат JSON или отсутствие обязательных параметров. Решение: проверьте URL, убедитесь, что chat_id передан как строка, а не число. Для Slack проверьте формат payload в документации.

Алерты не приходят, хотя порог превышен. Причина: отключен Alert Service или неверно заданы пороги в настройках пула. Решение: проверьте, что Alert Service активен (зелёный индикатор в списке), и сверьте значения порогов в Edit Pool Options.

Ложные срабатывания продолжаются после настройки скрипта. Причина: стандартные алерты пула не отключены и работают параллельно с кастомным скриптом. Решение: отключите встроенные алерты для конкретного пула в Alert Settings или поднимите их пороги до 95%, оставив как аварийный резерв.

Скрипт в Cron Jobs не выполняется. Причина: неверный shebang, отсутствие прав на исполнение или ошибка в пути. Решение: всегда указывайте #!/bin/bash первой строкой, дайте права chmod +x /путь/к/скрипту.sh, проверьте выполнение вручную из Shell.

Настроенная система оповещений - фундамент эксплуатации хранилища. Без неё даже правильно спроектированный пул с репликацией остаётся уязвимым. Начните с email как резервного канала, добавьте Telegram для оперативного реагирования и настройте кастомные пороги с фильтрацией снапшотов. Проверьте каждый канал тестовым алертом и симуляцией заполнения. 30 минут настройки сегодня предотвратят часы восстановления завтра.