~/dilshod
--:--:--

—Заметки

Мониторинг Synology в Zabbix 7.0: диски, RAID, SSD-кэш и износ NVMe

Два шаблона и небольшой скрипт: SNMP для «железа», DSM Web API для SSD-кэша и износа NVMe. Проверено на Synology RS1619xs+ и Zabbix 7.0.3.

Зачем два способа

По SNMP Synology отдаёт состояние системы, питания, вентиляторов, дисков и RAID. Но состояния SSD-кэша и износа NVMe в SNMP нет. А именно они ломаются первыми и сильнее всего бьют по задержкам: кэш уходит в защитный режим, и запись идёт прямо на HDD. Поэтому кэш и износ SSD мы берём из DSM Web API небольшим скриптом.

Synology DSM диски, RAID, питание SSD-кэш, SMART SNMPv3 UDP 161 DSM Web API HTTPS 5001 synology_ssd.py Zabbix 2 шаблона, триггеры High и выше Оповещения SNMP видит железо, кэш и износ SSD берём из API

Что получите

Что Откуда Когда сработает триггер
Статус системы, питание, вентиляторы SNMP не Normal → High
Диски: статус, температура SNMP (автообнаружение) статус ≥ 3 → High, температура 50 и 55 °C
RAID и тома: статус, свободное место, % занято SNMP Degrade или Crashed → High, заполнение 80 и 90%
Число дисков SNMP меньше ожидаемого → High
SSD-кэш: статус, режим, число устройств, hit rate DSM API кэш не normal, устройств меньше, есть сбойные → High
SSD: износ, записано ТБ, ошибки, critical warning, spare, температура DSM API (SMART) износ больше 80% → Warning, больше 90% → High, ошибки или warning больше 0 → High

Что скачать

Шаблоны в формате Zabbix 7.0 и лежат в группе My_Temp: эта группа должна уже существовать в Zabbix, либо замените её на свою перед импортом.

Шаг 1. Включить SNMP на Synology

В DSM: Панель управления → Терминал и SNMP → вкладка SNMP.

  1. Включите службу SNMP.
  2. Включите SNMPv3, задайте имя пользователя, протоколы SHA (аутентификация) и AES (шифрование) и два разных пароля.
  3. SNMPv1 и v2c с community public не включайте (а если включены, отключите): это открытый доступ к информации о системе.
  4. Проверка с сервера Zabbix:
snmpwalk -v3 -l authPriv -u <пользователь> -a SHA -A '<пароль_аутентификации>' -x AES -X '<пароль_шифрования>' <IP_Synology> 1.3.6.1.4.1.6574.1

Если вернулись значения из ветки 6574 (это SYNOLOGY-MIB), SNMP работает.

Шаг 2. Импортировать SNMP-шаблон

  1. Data collection → Templates → Import, выберите zabbix_template_synology_dsm_snmp.yaml.
  2. Создайте хост для Synology и назначьте ему два шаблона: Synology RS DSM by SNMP и стандартный Linux by SNMP (процессор, память, сеть, файловые системы).
  3. В интерфейсе хоста выберите SNMP и укажите версию SNMPv3, уровень безопасности authPriv, протоколы SHA1 и AES128, имя пользователя и два пароля из шага 1.
  4. Проверьте макросы хоста: - {$SYNO.DISK.COUNT} — сколько дисков должно быть в системе (HDD плюс SSD-кэш). По умолчанию 6; поставьте ваше число, иначе будет ложное срабатывание. - {$SYNO.DISK.TEMP.WARN} и {$SYNO.DISK.TEMP.HIGH} — пороги температуры дисков (50 и 55 °C). - {$SYNO.SYS.TEMP.WARN} и {$SYNO.SYS.TEMP.HIGH} — пороги температуры системы (60 и 70 °C). - {$SYNO.VOL.USED.WARN} и {$SYNO.VOL.USED.HIGH} — заполнение тома (80 и 90%).

Толстый iSCSI-LUN. Если том целиком занят толстым LUN (например, под датастор VMware), он занят на 100% по замыслу, и триггеры заполнения будут срабатывать постоянно. Задайте макросы с контекстом по имени тома, чтобы отключить их для него:

{$SYNO.VOL.USED.WARN:"Volume 3"} = 101
{$SYNO.VOL.USED.HIGH:"Volume 3"} = 101

Шаг 3. Пользователь DSM для API

Скрипт ходит в DSM Web API под отдельной учётной записью. Права давайте минимальные:

  1. Панель управления → Пользователь → Создать: имя, например zbx_monitor, длинный пароль (храните в менеджере паролей). Включите «Запретить пользователю менять пароль», двухфакторную защиту для этой учётки не включайте.
  2. Группы: оставьте users. Если скрипт получит ошибку прав (код 105 или пустой ответ), добавьте пользователя в administrators.
  3. Права на общие папки: «Нет доступа» везде.
  4. Разрешения к приложениям: разрешите только DSM, остальные запретите (File Station, FTP, WebDAV, Drive и т. п.).
  5. Безопасность → Брандмауэр: разрешите порт DSM (5001) только с IP сервера Zabbix.

Шаг 4. Скрипт

На сервере (или прокси) Zabbix:

cp synology_ssd.py /usr/lib/zabbix/externalscripts/
chmod +x /usr/lib/zabbix/externalscripts/synology_ssd.py
chown zabbix: /usr/lib/zabbix/externalscripts/synology_ssd.py

Логин и пароль скрипт берёт из файла /etc/zabbix/synology_api.conf, а не из аргументов (иначе пароль попадёт в списки процессов и логи):

[default]
user = zbx_monitor
password = ...
https = 1
verify = 0
timeout = 20

chown zabbix: /etc/zabbix/synology_api.conf
chmod 600 /etc/zabbix/synology_api.conf

В пароле не нужны кавычки. verify = 0 отключает проверку сертификата DSM; если у DSM нормальный сертификат, поставьте 1.

Проверка:

sudo -u zabbix /usr/lib/zabbix/externalscripts/synology_ssd.py <IP_Synology> 5001

Скрипт печатает один JSON с кэшем и SSD:

{"cache": [{"id": "ssd_1", "status": "degrade", "mode": "write", "ok": 0,
            "members": 1, "designed": 2, "failed": 1,
            "hit_rate": 86.0, "hit_rate_write": 97.0}],
 "ssd":   [{"name": "nvme1n1", "model": "Samsung SSD 980 PRO 500GB", "status": "normal",
            "temp": 29.0, "wear": 99.0, "spare": 100.0, "written_tb": 173.6,
            "media_errors": 0, "critical_warning": 0, "poweron_hours": 21668}],
 "ssd_count": 1, "cache_count": 1}

Если нужно увидеть сырой ответ DSM, добавьте --dump. Для любых других вызовов API есть режим --api, --method, --param, например:

./synology_ssd.py <IP_Synology> 5001 --api SYNO.Storage.CGI.Smart --method get_health_info --param device=/dev/nvme1n1

Шаг 5. Шаблон SSD-кэша

  1. Импортируйте zabbix_template_synology_ssd_cache.yaml и назначьте шаблон Synology SSD cache by Web API тому же хосту.
  2. Макросы: - {$SYNO.API.PORT} — порт DSM (5001 для HTTPS). - {$SYNO.SSD.COUNT} — сколько SSD-кэшей должно быть в системе (по умолчанию 2). - {$SYNO.CACHE.COUNT} — сколько кэшей (по умолчанию 1). - {$SYNO.SSD.WEAR.WARN} и {$SYNO.SSD.WEAR.HIGH} — пороги износа SSD (80 и 90%).
  3. Через 5 минут в Latest data появятся данные: статус и режим кэша, число устройств, износ и записанный объём по каждому SSD.

Что покажут триггеры

Триггер Важность Что делать
Кэш не healthy High Кэш в защитном режиме, запись идёт на HDD. Проверить SSD в DSM
В кэше устройств меньше, чем должно быть High Один из SSD выпал. Проверить слот и адаптер
Износ SSD больше 80% / 90% Warning / High Планировать замену, на 90% менять
Media errors или critical warning больше 0 High SSD сбоит, заменить
Меньше SSD или кэшей, чем ожидалось High Устройство пропало из системы
Нет данных от DSM API 15 минут Average Скрипт не работает: пароль, порт, 2FA на учётке или Synology недоступна

Не забудьте настроить оповещения: Alerts → Actions → Trigger actions, условие «Severity ≥ High».

Подвохи

Итог

SNMP закрывает «железо», DSM API закрывает то, чего в SNMP нет: состояние SSD-кэша и износ NVMe. Износ накапливается незаметно, а кэш в защитном режиме не выдаёт ошибок, он просто делает хранилище медленнее. Именно поэтому на такие вещи полезно поставить отдельные триггеры, а не искать причину по задержкам уже постфактум.

← ко всем записям