Scrutiny - мониторинг SMART дисков с уведомлениями

Столкнулся со следующими неудобствами/проблемами

  1. Имеется несколько серверов с дисками, просматривать значения мониторинга в одном месте не очень удобно
  2. Некоторые USB адаптеры не показывают smart в автоматическом режиме, но если указать тип, то работают
  3. Хочется наглядности и централизованности
  4. вTrueNAS пока что у меня пробрасываются диски, а не контроллеры, мониторинг в нем не работает

Нашел один из нескольких проектов: scrutiny

Проект состоит их 3 частей

  1. База данных для исторических данных и графиков
  2. Веб интерфейс, который отображает информацию
  3. Коллектор, который собирает информацию, он может быть в одном docker образе или же отдельно под разные платформы

Что я сделал

  1. Поднял LXC/Docker сервис с базой данных и веб интерфейсом
  2. Установил бинарник коллектора на PVE ноды
  3. Опубликовал веб интерфейс с proxy-auth

Пошагово
Прописал doc1ker-compose на сервере

services:
  influxdb:
    volumes:
      - ./db:/var/lib/influxdb2
    image: influxdb:2.2
    restart: unless-stopped

  scrutiny:
    ports:
      - 80:8080
    volumes:
      - ./scrutiny:/opt/scrutiny/config
    image: ghcr.io/analogj/scrutiny:master-web
    restart: unless-stopped

Создал конфиг scrutiny/scrutiny.yaml на основе шаблона, но задал адрес influxdb базы

  influxdb:
#    scheme: 'http'
    host: influxdb

После запуска на 80 порту получил пустой дашборд + базу данных

Далее, пока в ручном режиме на PVE нодах

wget https://github.com/AnalogJ/scrutiny/releases/download/v0.8.1/scrutiny-collector-metrics-linux-amd64 -O /usr/local/bin/scrutiny-collector-metrics
mkdir /etc/scrutiny
vim /etc/scrutiny/collector.yaml

и вставил следующий файл (шаблон)

version: 1
host:
  id: "PVE-05"
devices:
  - device: /dev/sda
    type: `sat`
api:
  endpoint: http://scrutiny.lan

Соответственно, прописываем название хоста, переопределение типа диска и хост веб интерфейса, который развернули ранее

vim /etc/cron.d/sсrutiny

Вставляем

# scrutiny SMART collector
PATH="/usr/sbin:/usr/bin:/sbin:/bin"
*/10 * * * * root if [ -f /etc/scrutiny/collector.yaml ] ;then /usr/local/bin/scrutiny-collector-metrics run --config=/etc/scrutiny/collector.yaml --log-file /var/log/scrutiny-collector.log > /dev/null 2>&1; fi

Тут прописываем расписание запуска и пути

Коллектор запускается, собирает информацию всю, отправляет ее на сервер и завершает свою работу

Скриншоты



Уведомления есть в шаблоне scrutiny

#notify:
#  urls:
#    - "discord://token@webhookid"
#    - "telegram://token@telegram?channels=channel-1[,channel-2,...]"
#    - "pushover://shoutrrr:apiToken@userKey/?priority=1&devices=device1[,device2, ...]"
#    - "slack://[botname@]token-a/token-b/token-c"
#    - "smtp://username:password@host:port/?fromAddress=fromAddress&toAddresses=recipient1[,recipient2,...]"
#    - "teams://token-a/token-b/token-c"
#    - "gotify://gotify-host/token"
#    - "pushbullet://api-token[/device/#channel/email]"
#    - "ifttt://key/?events=event1[,event2,...]&value1=value1&value2=value2&value3=value3"
#    - "mattermost://[username@]mattermost-host/token[/channel]"
#    - "ntfy://username:password@host:port/topic"
#    - "hangouts://chat.googleapis.com/v1/spaces/FOO/messages?key=bar&token=baz"
#    - "zulip://bot-mail:bot-key@zulip-domain/?stream=name-or-id&topic=name"
#    - "join://shoutrrr:api-key@join/?devices=device1[,device2, ...][&icon=icon][&title=title]"
#    - "script:///file/path/on/disk"
#    - "https://www.example.com/path"

Что понравилось

  1. Вроде даже есть какя-то хронология, а не просто показ данных
  2. Можно переопределять тип диска, что полезно очень т.к. proxmox показывает, что нет smart у диска, а по факту он есть
  3. Я так понял, что диски по серийникам создаются, при переезде диска в другой сервер он переезжает с сохранением данных, но у меня iscsi диск один выводился т.е. он есть на всех серверах, но выводится последний привязаный
  4. Можно скрыывать диски
  5. Написан на go, очень быстрый
  6. Современный дизайн и темная тема

Что не понравилось

  1. Похоже, что проект мертвый: написано, что бета, но последняя сборка была в апреле 24 года, куча ишьюсов и пулреквестов
  2. Тип диска определяется по букве, соответственно, при смене оной конфигурация поплывет
  3. Никакой безопасности: ни аутентификации веб интерфейса, ни коллекторов
  4. Проект сырой, графиков маловато, функционал базовый
  5. Были заготовки под самотесты дисков, но данный функционал так и не был реализован

Что недоделал

  1. DEB пакет и/или Ansible плейбук для быстрого деплоя
  2. Закрытие фаерволом
  3. Форк и допиливание проекта
6 лайков

Добавил ansible роль, скачать можно тут
Из особенностей:

  1. Запускается под рутом, т.к. коллектор не умеет sudo, а иначе я пока не решил эту проблему
  2. Дефолтный конфиг задается с указанием хоста на основе хоста в inventory, например, если там указано pve-01.lan, то в конфиг запишется PVE-01
  3. Не делал проверку на версию программы и скачивания новой, сомневаюсь, что разработчик будет выпускать новые версии, а если и будет, то тогда уже проще собрать свой .deb пакет и закинуть в свою репу
  4. В cron таску добавил вывод лога в случае ошибки, это позволит отправить уведомление штатными средствами PVE (у меня это бот в телеге)
2 лайка

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

Теоретически, можно показать остальные данные, но просто вывести как есть неинтересно, надо их проанализировать и вывести только ошибки или предупреждения.

Как вариант, форкнуть оригинальный проект и добавить отправку результатов анализа самого scrutiny в influxdb, откуда их уже можно забирать и визуализировать.

Вообще странно, что TrueNAS рекомендует этот проект, автор запросил его, а новый майнтейнер так и не нашелся

1 лайк

Роман, привет. Не совсем понял для чего создается база данных? Поднял сейчас без базы, по стандартным скриптам, в контейнере, коллектор на хосте proxmox. Данные в дашборде получаю.

Там в режиме all-in-one он все равно influxdb внутри себя запускает

-v `pwd`/scrutiny:/opt/scrutiny/config \
-v `pwd`/influxdb2:/opt/scrutiny/influxdb \

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

Я изначаьно разворачивал с отдельной СУБД для большего контроля, а потом еще подключил к графане для визуализации графиков там

1 лайк

а что-нить еще придумано для мониторинга дисков -не охота опять копаться в yaml

Ну есть zabbix еще
Можно просто купить qnap/terramaster/synology и не заморачиваться вообще ни по поводу чего

а так

Если бы было что-то хоть близко лежащее рядом по удобству и функционалу, то и я бы и truenas это бы подсказали

ИИ Анализ обсуждения Not accepted – Bring back SMART scheduling to UI На форуме TrueNAS

Вот краткий разбор обсуждения в теме
TrueNAS Community Forums
Not accepted – Bring back SMART scheduling to UI.


Суть проблемы

В версии TrueNAS 25.10 из веб-интерфейса убрали планирование SMART-тестов дисков.

Раньше в UI можно было:

  • задать расписание SMART short/long тестов
  • смотреть результаты тестов
  • управлять этим без CLI.

После изменения:

  • тесты можно запускать только вручную или через cron
  • GUI-интерфейс для планирования и просмотра результатов удалён.

SMART как механизм не удалён — он продолжает работать через smartd, но автоматическое тестирование больше не настраивается в GUI.


Что предлагали пользователи

Основные предложения из обсуждения:

1. Вернуть планирование SMART в GUI

Аргументы:

  • это базовая функция NAS
  • она существовала много лет
  • cron — неудобен для большинства пользователей.

2. Улучшить интерфейс SMART вместо удаления

Пользователи предлагали:

  • показывать историю тестов
  • выделять изменения между тестами
  • улучшить парсинг результатов.

3. Не заставлять ставить сторонние инструменты

Некоторые предлагали использовать:

  • Scrutiny
  • сторонние скрипты

Но многие возражали — мониторинг дисков должен быть частью NAS, а не сторонним приложением.


Аргументы TrueNAS (iXsystems)

Представители TrueNAS объяснили удаление несколькими причинами.

1. SMART-тесты считаются ненадёжными

По их словам:

  • SMART часто даёт ложные срабатывания
  • результаты не всегда полезны для диагностики.

2. Основной источник истины — ZFS

Они заявили, что для отказов дисков важнее:

  • ошибки ZFS
  • поведение пула
  • фактические I/O ошибки

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

3. Старый scheduler SMART был проблемным

Официальный аргумент:

  • scheduler имел баги и сложность поддержки
  • тесты иногда давали false positives
  • сложно было диагностировать проблемы.

4. Упрощение интерфейса

Часть логики:

  • убрать «ещё одну настройку»
  • сократить сложность GUI.

Итог решения

Фича-запрос был официально отклонён (Not accepted).

Причина:

  • команда считает текущую архитектуру (smartd + ZFS мониторинг + cron) достаточной.

Но при этом:

  • разработчики признали, что решение контроверсионное и следят за отзывами.

Что важно: частичный откат

Интересный момент: в связанных обсуждениях позже появилось сообщение, что некоторые SMART-опции могут вернуть в GUI (частично), но не обязательно прежний scheduler.

То есть позиция сейчас примерно такая:

  • полный возврат старого интерфейса не планируется
  • возможна частичная реинтеграция функций.

:white_check_mark: Коротко

Вопрос Ответ
Что произошло из UI убрали планирование SMART
Что хотят пользователи вернуть scheduler и просмотр результатов
Позиция TrueNAS SMART тесты ненадёжны, ZFS важнее
Решение feature request отклонён
Возможный компромисс частичный возврат функций

Если хочешь, могу ещё объяснить реальную техническую причину, почему iXsystems убирает такие функции — там есть довольно типичная архитектурная проблема TrueNAS SCALE (она неочевидна из обсуждения, но хорошо просматривается по их релизам).

да

Есть более глубокая техническая причина, которую разработчики напрямую почти не формулируют, но она просматривается по архитектуре TrueNAS SCALE и изменениям последних релизов.

Ниже — реальная инженерная логика, почему iXsystems убирает такие функции.


1. Архитектурная проблема: три источника правды

Исторически в TrueNAS CORE и ранних версиях SCALE SMART-логика выглядела так:

smartd (daemon)

TrueNAS middleware

UI scheduler

Но реально существовало три независимых механизма:

  1. smartd.conf
    настоящий механизм запуска тестов
  2. scheduler в middleware
    который генерировал smartd конфиг
  3. UI state
    который хранил расписание в базе TrueNAS

Из-за этого возникали рассинхронизации:

  • UI показывает одно
  • smartd работает по другому
  • cron может запускать третье

Это создаёт configuration drift.


2. SCALE движется к “appliance model”

В последних релизах TrueNAS SCALE iXsystems системно убирает функции, которые:

  • дублируют системные механизмы Linux
  • создают дополнительный state в middleware.

Их стратегия:

OS отвечает за сервис
TrueNAS UI только отображает

Поэтому:

Раньше Сейчас
TrueNAS управляет smartd smartd работает сам
UI планирует тесты пользователь может использовать cron
middleware генерирует конфиги конфиги ближе к системным

3. Реальная причина — поддержка

SMART scheduler был дорог в поддержке.

Типичные баги:

RAID / HBA passthrough

SMART тесты зависают на:

  • SAS expander
  • RAID HBA
  • USB-SATA bridge
  • NVMe behind PCIe switch

UI должен был понимать:

какие тесты поддерживаются
на каком типе диска
какой тип транспорта

Это огромная матрица.


4. ZFS реально обнаруживает большинство проблем

iXsystems делает ставку на OpenZFS.

ZFS обнаруживает:

  • checksum mismatch
  • read failure
  • write failure
  • degraded latency

Это фактические ошибки I/O, а не SMART предикторы.

SMART же часто:

  • даёт ложные тревоги
  • или наоборот не предупреждает.

Пример:

диск может умереть без изменения SMART attributes.


5. SMART long test плохо сочетается с NAS

SMART long test:

  • читает весь диск
  • создаёт I/O нагрузку
  • может длиться 10–20 часов на больших HDD

На NAS это может:

  • мешать scrub
  • мешать replication
  • создавать latency spikes.

Поэтому многие enterprise системы вообще не планируют long tests автоматически.


6. Ещё одна причина — переход на NVMe

SMART тесты исторически проектировались для SATA.

Для NVMe:

  • другой механизм health check
  • другие self tests
  • другое API.

Поддержка в старом scheduler была неполной.


7. Почему пользователи так возмутились

Для NAS-администраторов SMART тесты — привычная практика.

Типичный график:

short test → ежедневно
long test → раз в месяц

Многие считают это базовой функцией NAS, поэтому удаление вызвало сильную реакцию.


8. Итоговая позиция iXsystems

Фактически они говорят:

SMART остаётся, но управление им — не задача UI.

Рекомендуемая модель:

smartd → мониторинг
ZFS → обнаружение реальных ошибок
cron → если нужны тесты


9. Ирония ситуации

При этом сам TrueNAS всё равно использует smartd.

То есть они:

  • не убрали SMART
  • убрали только UI управления.

:light_bulb: Мой инженерный вывод

Настоящая причина удаления:

  1. уменьшить сложность middleware
  2. сократить баги
  3. упростить поддержку разных типов дисков
  4. двигаться к более “тонкому” UI

а аргумент про «SMART ненадёжен» — скорее частичное оправдание, чем основная причина.

А так, в основном все на баше и co пишут свою обертку, которая делает разборответа от smartctl и отправляют уведомления. Либо, что-то на уровне RAID контроллеров

Смотря на это со стороны обычного пользователя: Linux. в том контексте который рассказывают и показывают на форуме и канале, очень функциональный и тонкий в настройке, это чрезвычайно интересно для развития. НО как обычному пользователю мне бы не хотелось на столько сильно заморачиваться мониторингом диска в своем ПК (в нашем случае “сервере”). От SMART мониторинга ожидается только простейшая информация состояния диска (время работы, переназначенные/нестабильные сектора, на SSD дисках в CrystalDisk нравиться очень относительный показатель жизни SSD в %). Очень жаль что в Linux нет аналогов данного ПО, хотя при этом на Mac OS аналоги данного ПО вполне жизнеспособны, а основа данной системы вроде бы “выходец” из Linux. Нашел аналог CDisk для Linux, но для запуска требуется графическая оболочка, а городить виртуалку для мониторинга SMART, и тем более разбираться как потом дать ей доступ к дискам хоста, который по-любому потребуется, не особо хочется. Из выше изложенного делаю свое сугубо личное мнение)) Linux на более глубоком уровне все еще менее ”friendly” чем Win

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

в принципе это не сложно я думаю. если в экселе вы работали

там такой же принцип. надо соблюдать отступы))

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

Как я написал выше: synology показывает smart в красивом виде и умеет многое из коробки

Есть вывод smart в самом PVE, кстати

К сожалению, нет нормального smart мониторинга с веб интерфейсом, из того, что я находил scrutiny оказался самым живым + поддерживает агентов, а для меня это важно

Каждый диск не обязательно прописывать в нем, у меня такой шаблон для ansible

version: 1
host:
  id: "{{ host }}"
devices:
api:
  endpoint: http://scrutiny.lan

Если диск не хочет корректно определяться, тогда можно прописать его в конфиге, обычно sat помогает

Роман, можно вас попросить список необходимых файлов, (коллектор), конфигурация - куда их класть (папки) - и содержание .ямл. всё

Ну это зависит от конкретной задачи.
У меня scrutiny развернут в LXC контейнере и не имеет доступа к дискам
коллекторы устанавливаются ансиблом на PVE ноды, а для truenas я уже выкладывал рецепт на форуме

Сам плейбук

Сам плейбук тут
---
- name: Ensure smartmontools is installed
  package:
    name: smartmontools
    state: present

- name: Download scrutiny-collector-metrics if missing
  get_url:
    url: https://github.com/AnalogJ/scrutiny/releases/download/v0.8.1/scrutiny-collector-metrics-linux-amd64
    dest: /usr/local/bin/scrutiny-collector-metrics
    owner: root
    group: root
    mode: '0755'
    force: no

- name: Ensure /etc/scrutiny directory exists
  file:
    path: /etc/scrutiny
    state: directory
    owner: root
    group: root
    mode: '0755'

- name: Generate Scrutiny config if missing
  template:
    src: config.j2
    dest: /etc/scrutiny/collector.yaml
    owner: root
    group: root
    mode: '0644'
    force: false
  vars:
    host: "{{ inventory_hostname.split('.')[0] | upper }}"

- name: Copy collector.example.yaml 
  copy:
    src: collector.example.yaml
    dest: /etc/scrutiny/collector.example.yaml
    owner: root
    group: root
    mode: '0600'

- name: Copy cron job file
  copy:
    src: cron
    dest: /etc/cron.d/scrutiny
    owner: root
    group: root
    mode: '0600'
  1. Конфиг выше с заменой {{ host }} копируется в /etc/scrutiny/collector.yaml
  2. коллектор качается примерно так wget https://github.com/AnalogJ/scrutiny/releases/download/v0.8.1/scrutiny-collector-metrics-linux-amd64 -O /usr/local/bin/scrutiny-collector-metrics && chmod a+x /usr/local/bin/scrutiny-collector-metrics
  3. Прописать cron файл /etc/cron.d/scrutiny
# scrutiny SMART collector
PATH="/usr/sbin:/usr/bin:/sbin:/bin"
*/10 * * * * root if [ -f /etc/scrutiny/collector.yaml ] ; then /usr/local/bin/scrutiny-collector-metrics run --config=/etc/scrutiny/collector.yaml --log-file /var/log/scrutiny-collector.log > /dev/null 2>&1 || cat /var/log/scrutiny-collector.log >&2 ; fi

После этого scrutiny будет показывать информацию по дискам

Интересная температура диска в минус 48 градусов))) как он выживает 69дней))

Уточняющий вопрос,scrunity развернута в lxc контейнере,и на сколько я помню в этом же контейнере БД? И по поводу других нод,как организован опрос агентов с других нод?С той же ноды где lxc понятно,а с других машин/сетей?

Пока держится, но жидкого азота у меня уже практически не осталось

Так я же скинул выше конфиги. Агент по крону раз в 10 минут, запускается, собирает данные и отправляет их на сервер. И сам scrutiny и его БД хранятся вместе в одном контейнере.

Не сочтите за наглость, но тыкнете носом пожалуйста где во всем этом часть кода по определению хостов с агентом, предположим есть хост PVE с адресом 192.168.111.22 тут же LXC контейнер с ПО, и другой ПК выведенный в другую подсеть с адресом 192.168.88.15. На роутере маршрут чтобы ПК видели друг друга. PVE и ПК друг друга видят, как научить программу в LXC видеть агента на ПК? Агента на PVE она отлично видит. У Вас же скорее всего тоже не все ноды в одной и той же сети.

Так scrutiny не обращается к агентам напрямую, это в агенте указывается адрес scrutiny сервера


Соответственно, надо открыть доступ с PVE нод к scrutiny серверу

2 лайка