Мониторинг TrueNAS Scale с Netdata в 2026: установка, настройка дашбордов и алертов (Telegram, Slack)

Почему Netdata для TrueNAS Scale: ключевые возможности и преимущества

Встроенные средства мониторинга TrueNAS Scale дают базовый срез: загрузку CPU, использование памяти, состояние пулов. Этого достаточно для оценки «жив-здоров», но критически мало для диагностики аномалий до того, как они превратятся в инцидент. Netdata закрывает этот пробел.

Агент Netdata работает с минимальным потреблением ресурсов - около 1% CPU и 20-30 МБ RAM в типовой конфигурации. Он автоматически обнаруживает сервисы и устройства, начиная сбор тысяч метрик в первую секунду после запуска. Для NAS на базе TrueNAS это означает немедленный доступ к детализированным данным по S.M.A.R.T., ZFS, ARC и сетевому стеку без ручного конфигурирования коллекторов.

Сравним со штатными инструментами. TrueNAS показывает текущее состояние диска через веб-интерфейс и отправляет email-алерт при падении SMART-атрибутов ниже порога. Netdata строит графики трендов по каждому атрибуту: вы видите, что число перемещенных секторов росло последние три дня, а не просто получили сообщение о критическом значении. Это даёт фору на упреждающую замену диска до деградации пула. Аналогично с ARC: штатная статистика TrueNAS ограничена hit ratio в моменте, Netdata же показывает корреляцию между размером кэша, промахами и нагрузкой на диски.

Интеграция с Telegram и Slack - вторая причина выбрать Netdata. Штатный почтовый алертинг TrueNAS надёжен, но мгновенные уведомления в мессенджер с деталями инцидента ускоряют реакцию. Вы получаете не просто «Pool tank is DEGRADED», а карточку с конкретным диском, его серийным номером и графиком ошибок за последний час.

Подготовка TrueNAS Scale к установке Netdata

Системные требования и совместимость

Netdata в контейнере на TrueNAS Scale требует минимум 1 vCPU и 256 МБ RAM. Для небольших инсталляций с 2-4 дисками этого достаточно. При мониторинге крупных систем с десятками дисков и высокой нагрузкой на ZFS выделите 2 vCPU и 512-1024 МБ RAM - дополнительная память уходит на буферизацию метрик перед сбросом на диск.

Инструкция проверена на TrueNAS Scale 24.10 (Electric Eel) и совместима с версией 25.04 (Fangtooth). Если вы используете более ранний релиз, обновитесь - в версиях до 24.04 механизм приложений на основе Docker отличается, и часть шагов по пробросу устройств может не работать.

Перед установкой убедитесь, что пул приложений (обычно apps или отдельный SSD-пул) создан и доступен. Если вы ещё не настраивали приложения, обратитесь к руководству по выбору и начальной настройке TrueNAS, где разобраны базовые шаги.

Настройка окружения: датасеты и разрешения

Netdata хранит конфигурацию, базу метрик и алерты в файлах. Чтобы эти данные сохранялись между обновлениями контейнера, создайте отдельный датасет.

1. В веб-интерфейсе TrueNAS перейдите в раздел Datasets.
2. Выберите пул приложений и нажмите Add Dataset.
3. Назовите датасет netdata-config. Остальные параметры оставьте по умолчанию.
4. После создания откройте права доступа (Permissions) датасета. На вкладке ACL добавьте запись для пользователя apps (UID 568) с полными правами. Этот пользователь используется контейнерами приложений TrueNAS.

Создайте второй датасет netdata-cache для временных метрик - это снизит износ SSD основного пула при интенсивной записи. Размер можно ограничить квотой в 2-5 ГБ, Netdata автоматически ротирует старые данные.

Установка Netdata из каталога приложений TrueNAS

Конфигурация приложения: основные параметры

TrueNAS Scale включает Netdata в официальный каталог приложений. Установка занимает меньше минуты.

1. Перейдите в раздел Apps → Discover Apps.
2. В строке поиска введите netdata и выберите приложение из каталога.
3. Нажмите Install. Откроется форма конфигурации.

Основные параметры для заполнения:

• Application Name: оставьте netdata или задайте своё имя. Это имя контейнера и префикс для внутреннего DNS.
• Netdata Web Port: порт веб-интерфейса, по умолчанию 19999. Если порт занят другим сервисом, укажите свободный, например 19998.
• Host Network: включите этот параметр. Он даёт контейнеру прямой доступ к сетевому стеку хоста, что необходимо для мониторинга сетевых интерфейсов и корректного определения IP для алертов.
• Extra Host Path Mounts: добавьте два маунта:
  • Host Path: /mnt/ваш_пул/netdata-config → Mount Path: /etc/netdata
  • Host Path: /mnt/ваш_пул/netdata-cache → Mount Path: /var/cache/netdata
• Extra Environment Variables: добавьте переменную NETDATA_CLAIM_TOKEN со значением токена, если планируете подключить агента к Netdata Cloud. Для локального использования это необязательно.

Критичный момент - проброс устройств для мониторинга S.M.A.R.T. В разделе Resources нажмите Add Device и добавьте каждый диск, который нужно отслеживать: /dev/sda, /dev/sdb и так далее. Список устройств можно получить через SSH-команду lsblk -d.

Первый запуск и проверка работоспособности

После нажатия Install TrueNAS скачает образ и запустит контейнер. Процесс занимает 30-60 секунд. Статус отслеживается в разделе Apps → Installed Applications - контейнер должен перейти в состояние Running.

Откройте веб-интерфейс по адресу http://IP_вашего_TrueNAS:19999. Вы увидите дефолтный дашборд с графиками загрузки CPU, памяти, дискового I/O и сетевого трафика. Проверьте наличие секции Disks - если диски не отображаются, вернитесь к пробросу устройств в настройках приложения.

Для проверки статуса контейнера через SSH выполните:

sudo k3s kubectl get pods -n ix-netdata
sudo k3s kubectl logs -n ix-netdata deployment/netdata

В логах не должно быть ошибок вида Cannot open /dev/sda. Если они есть, проверьте права на устройства в хостовой системе.

Настройка дашбордов для ключевых метрик TrueNAS

Дефолтный дашборд Netdata информативен, но избыточен для повседневного мониторинга NAS. Создайте кастомный дашборд, сфокусированный на четырёх зонах: диски, ZFS, ARC и сеть.

Для создания кастомного дашборда откройте веб-интерфейс, нажмите на иконку Dashboards в левом меню, затем New Dashboard. Назовите его, например, TrueNAS Overview. Дашборд наполняется виджетами через кнопку Add Chart - каждый виджет ссылается на конкретную метрику.

Мониторинг состояния дисков: S.M.A.R.T. и температура

Коллектор smartd_log считывает атрибуты S.M.A.R.T. напрямую с устройств. Для его активации создайте файл /mnt/ваш_пул/netdata-config/python.d/smartd_log.conf с содержимым:

update_every: 60

jobs:
  - name: all_disks
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/sdc

Перечислите все диски, проброшенные в контейнер. После сохранения файла перезапустите Netdata через интерфейс TrueNAS (кнопка Restart в карточке приложения) или командой:

sudo k3s kubectl rollout restart deployment/netdata -n ix-netdata

Ключевые S.M.A.R.T.-атрибуты для добавления на дашборд:

• Reallocated_Sector_Ct (ID 5) - число переназначенных секторов. Ненулевое значение указывает на деградацию поверхности.
• Current_Pending_Sector (ID 197) - сектора, ожидающие переназначения. Рост этого счётчика означает, что диск не может прочитать данные.
• Temperature_Celsius (ID 194) - температура диска. Для HDD критический порог 50°C, для SSD - 70°C.

На дашборд выведите временные ряды по температуре всех дисков одним составным графиком и отдельный виджет с текущими значениями Reallocated_Sector_Ct. Это даст мгновенную картину теплового режима и состояния поверхности.

Мониторинг ZFS: пулы, производительность и ошибки

Netdata автоматически обнаруживает ZFS-пулы через коллектор zfs. Метрики доступны в секции ZFS Pools дефолтного дашборда. Для кастомного дашборда выберите следующие виджеты:

• Pool Capacity - заполнение пула в процентах. Критично для ZFS: при заполнении выше 80% производительность падает из-за фрагментации, выше 90% возможна деградация.
• Pool Health - состояние пула: ONLINE, DEGRADED, FAULTED. Этот виджет должен быть самым заметным на дашборде.
• Pool IOPS - операции ввода-вывода в секунду, разделённые на чтение и запись. Позволяет оценить нагрузку и выявить аномальные всплески.
• Pool Bandwidth - пропускная способность в байтах/с.

Для отслеживания ошибок ZFS добавьте метрики zfs.checksum_errors, zfs.read_errors и zfs.write_errors. Ненулевые значения этих счётчиков - прямой сигнал к немедленной диагностике: от проблем с кабелями до повреждения данных.

Кэш ARC: анализ эффективности и hit ratio

ARC (Adaptive Replacement Cache) - ключевой механизм ускорения чтения в ZFS. Netdata предоставляет детальные метрики через коллектор zfs_arc.

На кастомный дашборд выведите:

• ARC Size - текущий размер кэша относительно максимального (параметр zfs_arc_max). Позволяет оценить, достаточно ли памяти выделено.
• ARC Hit Ratio - процент попаданий в кэш. Значение ниже 90% для рабочих нагрузок с повторяющимися чтениями указывает на нехватку ARC.
• ARC Misses - количество промахов в секунду. В сочетании с Hit Ratio показывает, насколько часто система вынуждена обращаться к дискам.

Интерпретация: если Hit Ratio стабильно ниже 80%, а объём ARC упирается в максимум, добавьте RAM или проверьте, не вытесняют ли кэш другие приложения. Более детальный анализ ZFS-подсистемы и тюнинг параметров выходит за рамки этой статьи, но базовые метрики ARC - индикатор, который сигнализирует о необходимости такого анализа.

Настройка алертов и уведомлений в Telegram и Slack

Система алертов Netdata базируется на конфигурационных файлах в формате .conf и скриптах-обработчиках. Каждый алерт имеет порог срабатывания, задержку (чтобы избежать ложных срабатываний при кратковременных всплесках) и действие - отправку уведомления.

Создание кастомных алертов для TrueNAS

Создайте файл /mnt/ваш_пул/netdata-config/health.d/truenas.conf. Пример содержимого:

# Алерт на температуру диска
alarm: disk_temp_high
on: smart_log.temperature
lookup: max -1m unaligned of all_disks
every: 1m
warn: $this > 45
crit: $this > 50
info: Температура диска превышает безопасный порог
to: sysadmin

# Алерт на заполнение пула
alarm: zfs_pool_capacity
on: zfspool.state
lookup: average -1m unaligned percentage of capacity
every: 1m
warn: $this > 80
crit: $this > 90
info: Заполнение ZFS-пула приближается к критическому
to: sysadmin

# Алерт на ошибки ZFS
alarm: zfs_errors
on: zfspool.checksum_errors
lookup: sum -10m unaligned
every: 1m
warn: $this > 0
crit: $this > 10
info: Обнаружены ошибки контрольных сумм ZFS
to: sysadmin

Пояснение параметров:

• on - метрика, на которую нацелен алерт.
• lookup - метод агрегации. max -1m берёт максимум за последнюю минуту, average -1m - среднее, sum -10m - сумму за 10 минут.
• warn и crit - пороги предупреждения и критического состояния.
• to - роль получателя. Роль sysadmin нужно определить в конфигурации уведомлений.

После сохранения файла перезапустите Netdata. Проверить загрузку алертов можно через веб-интерфейс: раздел Alarms → вкладка Active покажет все сконфигурированные алерты и их текущий статус.

Интеграция с Telegram: пошаговая инструкция

1. Создайте бота через @BotFather в Telegram. Команда /newbot, следуйте инструкциям. Сохраните полученный токен.
2. Получите chat_id. Добавьте бота в группу или начните с ним диалог, затем выполните запрос: https://api.telegram.org/botВАШ_ТОКЕН/getUpdates. В ответе найдите "chat":{"id":ЧИСЛО}.
3. Отредактируйте файл /mnt/ваш_пул/netdata-config/health_alarm_notify.conf:

   SEND_TELEGRAM="YES"
   TELEGRAM_BOT_TOKEN="ВАШ_ТОКЕН"
   DEFAULT_RECIPIENT_TELEGRAM="ВАШ_CHAT_ID"

4. Перезапустите Netdata.
5. Для теста выполните команду внутри контейнера:

   sudo k3s kubectl exec -n ix-netdata deployment/netdata -- /usr/libexec/netdata/plugins.d/alarm-notify.sh test

   В Telegram должно прийти тестовое сообщение.

Если вы ранее настраивали оповещения штатными средствами TrueNAS, обратитесь к руководству по настройке оповещений о заполнении диска - там разобран альтернативный подход с Webhook, который можно комбинировать с Netdata для дублирования критических алертов.

Интеграция со Slack: пошаговая инструкция

1. Перейдите в Slack API → Your Apps → Create New App → From Scratch.
2. Назовите приложение, выберите рабочее пространство.
3. В разделе Incoming Webhooks активируйте переключатель и нажмите Add New Webhook to Workspace.
4. Выберите канал и скопируйте URL вида https://hooks.slack.com/services/T.../B.../xxxx.
5. В файле health_alarm_notify.conf укажите:

   SEND_SLACK="YES"
   SLACK_WEBHOOK_URL="https://hooks.slack.com/services/T.../B.../xxxx"
   DEFAULT_RECIPIENT_SLACK="#ваш_канал"

6. Перезапустите Netdata и выполните тестовую отправку.

Оба мессенджера можно использовать одновременно - укажите SEND_TELEGRAM="YES" и SEND_SLACK="YES" в одном конфигурационном файле. Алерты будут дублироваться в оба канала.

Тестирование мониторинга и алертов

После настройки проверьте, что система работает как единое целое. Не ждите реального инцидента - симулируйте его.

Проверка алерта на заполнение пула. Создайте временный датасет и заполните его файлами до порога 80%:

dd if=/dev/zero of=/mnt/ваш_пул/test/fillfile bs=1G count=XX

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

Проверка алерта на ошибки ZFS. Этот тест требует осторожности. Создайте тестовый пул на файловых образах (loopback), намеренно повредите один из образов с помощью dd и выполните scrub. Netdata зафиксирует ошибки контрольных сумм и отправит алерт.

Проверка канала уведомлений. Используйте встроенный тестовый механизм:

sudo k3s kubectl exec -n ix-netdata deployment/netdata -- /usr/libexec/netdata/plugins.d/alarm-notify.sh test

Сообщение должно прийти в Telegram и/или Slack в течение 5-10 секунд. Если нет - проверьте логи контейнера на предмет сетевых ошибок и корректность токенов.

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

Netdata не видит диски. Причина - устройства не проброшены в контейнер или права на них ограничены. Проверьте список устройств в настройках приложения TrueNAS и убедитесь, что контейнер запущен с привилегированным режимом (включён по умолчанию для Netdata из каталога). Команда ls -l /dev/sd* внутри контейнера покажет доступные устройства и их права.

Не приходят алерты в Telegram/Slack. Типичные причины: неверный токен, сетевые ограничения на уровне TrueNAS или контейнера, неправильный chat_id. Проверьте конфигурацию health_alarm_notify.conf на опечатки. Выполните тестовую отправку вручную и смотрите логи контейнера - ошибки вида curl: (6) Could not resolve host указывают на проблемы с DNS, curl: (7) Failed to connect - на блокировку исходящих соединений.

Высокая нагрузка на CPU. Netdata по умолчанию собирает метрики каждую секунду. Для NAS с ограниченными ресурсами увеличьте интервал до 3-5 секунд. Создайте файл /mnt/ваш_пул/netdata-config/netdata.conf с содержимым:

[global]
  update every = 3

Это снизит нагрузку на CPU примерно на 40-50% при незначительной потере детализации.

База метрик разрастается. Netdata хранит метрики в /var/cache/netdata. При интенсивном сборе база может занимать десятки гигабайт. Ограничьте размер через параметр dbengine multihost disk space в netdata.conf:

[db]
  dbengine multihost disk space = 2048

Значение в мегабайтах, здесь - 2 ГБ. Старые данные автоматически удаляются при превышении лимита.

Заключение: дальнейшие шаги и ресурсы

Вы развернули Netdata на TrueNAS Scale, настроили дашборд с ключевыми метриками дисков, ZFS и ARC, сконфигурировали алерты с доставкой в Telegram и Slack. Система мониторинга работает в пассивном режиме и ждёт инцидентов.

Дальнейшие шаги для усиления наблюдаемости:

• Подключите агента к Netdata Cloud для централизованного мониторинга нескольких узлов и долгосрочного хранения метрик.
• Расширьте алерты на сетевые аномалии, утилизацию CPU конкретными сервисами TrueNAS (SMB, NFS) и статус задач репликации. Материал по настройке алертинга в TrueNAS поможет интегрировать оповещения о задачах бэкапа.
• Изучите руководство по мониторингу дисков и inode с Netdata - там разобран продвинутый сценарий с Prometheus и Grafana для прогнозирования заполнения.

Официальная документация Netdata доступна на learn.netdata.cloud. Репозиторий с примерами конфигураций для TrueNAS-специфичных алертов поддерживается сообществом на GitHub - ищите по ключевым словам «netdata truenas alarms».

Если вы ещё не знакомы с основами работы TrueNAS, начните с руководства по настройке сетевого доступа к файлам, где разобраны SMB, NFS и FTP с акцентом на безопасность.