ZFS ZED: оповіщення, що повідомляють про відмову перш ніж це помітять користувачі

Що насправді робить ZED (і чого не робить)

ZFS — це файловий простір і менеджер томів з вбудованим відчуттям самозбереження. Він перевіряє контрольні суми, валідує читання,
виявляє корупцію і записує детальну інформацію про збої. Але ZFS не піде у ваш офіс і не покашляє.
ZED — це кур’єр.

На високому рівні ZED слухає події ZFS (які походять із ZFS ядра та утиліт у userland) і запускає невеликі обробні скрипти,
звані zedlet. Ці скрипти можуть надсилати листи, писати в syslog/journald, запускати гарячий spare, записувати історію
або інтегруватися з тією системою оповіщень, якій ви довіряєте о 3 ранку.

Лінія розмежування

• ZFS виявляє та записує: помилки, стан degraded, початок/завершення resilver, початок/завершення scrub, збої пристроїв тощо.
• ZED реагує й повідомляє: «щось сталося, ось деталі, зробіть це далі».
• Ваша система моніторингу корелює та ескалює: повідомляє людей, відкриває тикети, відстежує MTTR і робить це чиєюсь проблемою.

ZED — не повноцінна система моніторингу. Це рушій тригерів і контексту. Він не буде дедуплікувати оповіщення між флотами або давати SLO-дашборди.
Але він дасть ранні, специфічні, дієві сигнали — ті, що дозволяють замінити диск у вівторок вдень замість операції під час збою клієнтів вночі суботи.

Один оперативний вислів, який варто тримати поруч із рукописами:
Надія — не стратегія. — Ген. Гордон Р. Салліван

Жарт №1: Відмови зберігання як стоматологи — якщо ви бачите їх тільки коли болить, ви вже переплачуєте.

Факти та історія, що важливі в опсах

ZED — це не просто «якийсь демон». Це операційна поверхня ZFS. Декілька фактів і контекст полегшать розуміння того,
що ви розгортаєте і чому воно поводиться так, як поводиться:

1. ZFS виник у Sun Microsystems в середині 2000-х з філософією «сховище як система»: контрольні суми, pooling, snapshots, самовідновлення.
2. ZFS спроектовано так, щоб не довіряти дискам за замовчуванням. end-to-end контрольні суми — це не фіча; це припущення.
3. OpenZFS з’явився як кросплатформена ініціатива після фрагментації оригінальної лінії Solaris ZFS; сьогодні Linux, FreeBSD та інші слідкують за OpenZFS.
4. ZED виник із потреби операціоналізувати події про збої. Виявити збій марно, якщо ніхто про це не дізнається.
5. ZFS має внутрішній потік подій (думайте: «зміни станів і звіти про збої»), і ZED — споживач, що перетворює події на дії.
6. Scrub — це первинний інструмент обслуговування у ZFS: періодичне повне читання для виявлення і виправлення прихованої корупції поки є надмірність.
7. «Degraded» не означає «впав» у ZFS, саме тому це небезпечно: сервіс працює, але ваш запас надійності вичерпано.
8. Resilver і scrub — різні речі: resilver — цільовий ремонт/реконструкція після заміни або приєднання пристрою; scrub — перевірка цілого пулу.
9. Багато «помилок» ZFS — це насправді попередження, а не інцидент: checksum-помилки часто означають, що система виявила погані дані і успішно їх відновила.

Операційний висновок: ZFS балакучий у потрібних місцях. ZED — як його слухати, не живучи в zpool status як у соціальній мережі.

Як ZED бачить світ: події, zedlet та стан

Завдання ZED просте: коли трапляється подія ZFS — запустити обробники. Складність — у деталях: які події, які обробники,
як обмежувати їх, і як передати достатньо контексту в оповіщення, щоб діяти не занурюючись у логі.

Джерела подій і форма даних

ZFS випромінює події про зміни стану пулу, помилки пристрою, активність scrub/resilver та дії з управління збоями. ZED отримує їх
і передає поля події в zedlet-скрипти як змінні середовища. Точний набір залежить від платформи й версії OpenZFS, але ви побачите
сталу структуру: ім’я пулу, GUID vdev, шлях пристрою, переходи станів і лічильники помилок.

Zedlet: маленькі скрипти з гострими лезами

Zedlet — це виконавчі скрипти, розміщені в директорії zedlet (звично під /usr/lib/zfs/zed.d на Linux-дистрибутивах,
з симлінками або увімкненими наборами під /etc/zfs/zed.d). Вони навмисно невеликі. У них має бути одне завдання:
сформувати лист, записати в syslog, ініціювати spare, записати рядок історії або викликати локальний інтеграційний скрипт.

Дисципліна: тримайте zedlet детермінованими і швидкими. Якщо потрібна «реальна логіка», хай zedlet поставляє роботу в чергу
(запише файл, відправить на локальний сокет, викличе легкий wrapper) і хай інший сервіс виконає важку роботу. ZED — частина вашого шляху відмов.
Не робіть його громіздким.

Стан і дедуплікація

ZED може генерувати повторювані події при флапінгу пристроїв або постійних помилках. Якщо ви бездумно будете сповіщати при кожному викиді,
навчите людей ігнорувати оповіщення, і тоді отримаєте те, що заслужили. Хороші налаштування ZED зазвичай роблять принаймні одне з цього:

• Тротлінг повідомлень (на пул/вдев і в межах вікна часу).
• Надсилання оповіщень про зміни стану (ONLINE→DEGRADED, DEGRADED→ONLINE), а не про кожне зростання лічильника.
• Надсилання scrub як підсумкових подій (початок, завершення, знайдені помилки) з контекстом.
• Збереження невеликого файлу стану, який відстежує, що вже було відправлено.

На що варто оповіщувати

Не оповіщайте про все. Оповіщення — це контракт із сонними людьми. Ось розумний мінімум:

• Зміни стану пулу: ONLINE→DEGRADED, DEGRADED→FAULTED, видалений пристрій.
• Результати scrub: завершився з помилками, відновлені байти або «занадто багато помилок».
• Checksum/read/write помилки понад поріг або при зростаючій швидкості.
• Події збоїв пристроїв: тайм-аути, I/O збої, «device removed», зміни шляху.
• Завершення resilver: успіх/помилка, тривалість, чи повернувся пул в ONLINE.

Оповіщення, які вам мають бути важливі (і що з ними робити)

Оповіщення ZED має відповідати на три питання: що сталося, що під загрозою і що робити далі.
Якщо ваші оповіщення не містять ім’я пулу, постраждалого vdev і копію zpool status -x або релевантний фрагмент,
ви пишете детективи, а не оповіщення.

DEGRADED пул

«DEGRADED» означає, що ви працюєте із зменшеною надмірністю. Сервіс ще працює, але ще одна відмова може призвести до втрати даних
(залежно від RAIDZ-рівня і розташування vdev). Правильна реакція має часові рамки: дослідіть негайно; замініть оперативно;
не чекайте наступного вікна обслуговування, якщо вам подобається азарт.

Checksum-помилки

Checksum-помилки — це ZFS, що каже «я спіймав погані дані». Це і хороша, і погана новина. Хороша: детекція працює. Погана:
щось ушкоджує дані в стеку — диск, кабель, HBA, прошивка, RAM (якщо немає ECC) або навіть нестабільність живлення.
Рішення залежить від того, чи є помилки ізольованими (один диск, один шлях) чи системними (по всіх vdev).

Read/write помилки

Read-помилки вказують, що пристрій не зміг повернути дані. ZFS може реконструювати з паритету/дзеркал; якщо ні — бачите постійні помилки.
Write-помилки часто вказують на проблеми зі зв’язком, скидання контролера або відмову записів диском. У будь-якому випадку,
зростаючі лічильники — це «замініть або виправте шлях».

Scrub завершився з помилками

Scrub, який відновив дані — це попередження, що надмірність вас врятувала цього разу. Якщо не вжити заходів, наступного разу може не пощастити.
Scrub, що знайшов невідновлені помилки — це інцидент цілісності даних; ваше завдання — оцінити збитки та побудувати стратегію відновлення.

Пристрій видалено / UNAVAIL

Часто це не «диск помер», а «шлях помер». Розхитаний SAS-кабель, негідний expander, баг прошивки HBA, ненадійна бекплейн-плата.
Найшвидший спосіб прожарити вихідні вихідні дні — замінити абсолютно справний диск, коли реальний злочинець — бекплейн.

Практичні завдання: команди, виводи та рішення (12+)

Це кроки, які ви робитимете в реальному житті: перевірити, що ZED працює, підтвердити, що він може надсилати пошту, викликати тестові події,
інтерпретувати стан пулу і виконати виправні дії. Кожне завдання нижче містить: команду, що означає вивід, і рішення, яке ви приймаєте.

Завдання 1: Підтвердити, що сервіс ZED запущено (systemd)

cr0x@server:~$ systemctl status zfs-zed.service
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 09:14:31 UTC; 2 days ago
   Main PID: 1189 (zed)
      Tasks: 3 (limit: 18982)
     Memory: 7.4M
        CPU: 1min 12s
     CGroup: /system.slice/zfs-zed.service
             └─1189 /usr/sbin/zed -F

Що це означає: «active (running)» — це базова необхідність. Якщо він inactive, події ZFS все одно відбуваються; ви їх просто не чуєте.

Рішення: Якщо не працює, виправте ZED перш ніж довіряти будь-якому «моніторингу», який нібито стежить за ZFS.

Завдання 2: Перевірити останні логи ZED у journald

cr0x@server:~$ journalctl -u zfs-zed.service -n 50 --no-pager
Dec 24 08:03:11 server zed[1189]: ZED: eid=402 class=sysevent.fs.zfs.scrub_finish pool=tank
Dec 24 08:03:11 server zed[1189]: ZED: executing zedlet: /usr/lib/zfs/zed.d/scrub.finish
Dec 24 08:03:11 server zed[1189]: ZED: eid=403 class=sysevent.fs.zfs.vdev_check pool=tank

Що це означає: Ви хочете бачити події та рядки виконання zedlet. Тиша під час відомих подій вказує на помилкову конфігурацію або відсутність подій.

Рішення: Якщо ви бачите події, але немає сповіщень — зосередьтесь на конфігурації zedlet (пошта, дозволи, PATH), а не на самому ZFS.

Завдання 3: Перевірити файл конфігурації ZED

cr0x@server:~$ sudo egrep -v '^\s*(#|$)' /etc/zfs/zed.d/zed.rc
ZED_DEBUG_LOG="/var/log/zed.log"
ZED_EMAIL_ADDR="storage-alerts@example.com"
ZED_EMAIL_PROG="mail"
ZED_NOTIFY_INTERVAL_SECS=3600
ZED_NOTIFY_VERBOSE=1

Що це означає: ZED налаштовано логувати, надсилати пошту і тротлити оповіщення. Відсутність налаштувань пошти — поширена причина «ми думали, що маємо оповіщення».

Рішення: Якщо у вашій організації немає пошти, налаштуйте ZED на виклик wrapper-скрипта, який говорить з вашим alert-менеджером, але зберігайте тротлінг.

Завдання 4: Переконатися, що поштовик існує і працює з хоста

cr0x@server:~$ command -v mail
/usr/bin/mail

cr0x@server:~$ echo "zed test message" | mail -s "zed smoke test" storage-alerts@example.com
...output...

Що це означає: Перша команда доказує, що налаштована поштовая програма існує. Друга — що хост може фактично доставити пошту (через локальну чергу або relay).

Рішення: Якщо пошта не працює — виправте вихідну пошту перш ніж звинувачувати ZED. ZED не може повідомляти через неіснуючий канал.

Завдання 5: Перелічити увімкнені zedlet (які дії ви справді виконуєте)

cr0x@server:~$ ls -l /etc/zfs/zed.d
total 0
lrwxrwxrwx 1 root root 30 Dec 10 10:12 all-syslog.sh -> /usr/lib/zfs/zed.d/all-syslog.sh
lrwxrwxrwx 1 root root 31 Dec 10 10:12 checksum-email.sh -> /usr/lib/zfs/zed.d/checksum-email.sh
lrwxrwxrwx 1 root root 29 Dec 10 10:12 scrub.finish -> /usr/lib/zfs/zed.d/scrub.finish

Що це означає: Багато дистрибутивів розміщують zedlet у /usr/lib і вмикають підмножину через симлінки в /etc.

Рішення: Якщо нічого не увімкнено — ви нічого не отримаєте. Увімкніть лише те, на що зможете реагувати; відключіть шумні, поки не будете готові.

Завдання 6: Швидка перевірка здоров’я пулу (команда «на чи ми вогні»)

cr0x@server:~$ zpool status -x
all pools are healthy

Що це означає: ZFS милосердно лаконічний. Якщо він виводить щось інше — у вас є робота.

Рішення: «Healthy» не означає «без ризику», але означає, що ви наразі не в degraded/faulted стані.

Завдання 7: Глибинний статус коли щось не так

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:18 with 0 errors on Tue Dec 24 08:03:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1      ONLINE       0     0     0
            ata-WDC_WD80EFAX-2      ONLINE       0     0     0
            ata-WDC_WD80EFAX-3      UNAVAIL      0     0     0  cannot open

errors: No known data errors

Що це означає: Пул degraded, бо один пристрій недоступний. «No known data errors» — добре; надмірність ще тримає.

Рішення: Розглядайте UNAVAIL як термінове. Дослідіть шлях проти диска, потім замініть або відновіть підключення перш ніж трапиться друга відмова.

Завдання 8: Скоординувати імена пристроїв ZFS з реальним обладнанням

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD80EFAX-3
lrwxrwxrwx 1 root root  9 Dec 25 01:12 ata-WDC_WD80EFAX-3 -> ../../sde

Що це означає: Ви можете співвіднести стабільний шлях by-id від ZFS з вузлом ядра (/dev/sde), що допомагає зі SMART і мапінгом фізичного слоту.

Рішення: Використовуйте /dev/disk/by-id у пулах, коли можливо; це зменшить випадки «замінили неправильний диск».

Завдання 9: Перевірити SMART-стан підозрілого диска

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2

Що це означає: «PASSED» — не картка «звільнення від відповідальності». Pending та uncorrectable сектори — поганий знак, навіть якщо диск впевнено стверджує про себе.

Рішення: Якщо pending/uncorrectable не нуль і ростуть — замініть диск. Якщо ZFS уже помітив UNAVAIL, дискусії закінчено.

Завдання 10: Переглянути останні повідомлення ядра на предмет скидань лінку або помилок транспорту

cr0x@server:~$ dmesg -T | tail -n 20
[Wed Dec 25 01:10:22 2025] ata9.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
[Wed Dec 25 01:10:22 2025] ata9.00: irq_stat 0x08000000, interface fatal error
[Wed Dec 25 01:10:23 2025] ata9: hard resetting link
[Wed Dec 25 01:10:28 2025] ata9: link is slow to respond, please be patient (ready=0)
[Wed Dec 25 01:10:31 2025] ata9: COMRESET failed (errno=-16)
[Wed Dec 25 01:10:31 2025] ata9.00: disabled

Що це означає: Це кричить «проблема шляху». Може бути диск, а може кабель/бекплейн/контролер.

Рішення: Перед масовою заміною дисків пересадіть кабель/змініть слот, якщо можете. Якщо помилки йдуть за слотом — ви знайшли справжню домену відмови.

Завдання 11: Показати лічильники помилок ZFS і спостерігати за зростанням

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1      ONLINE       0     0     0
            ata-WDC_WD80EFAX-2      ONLINE       0     0     0
            ata-WDC_WD80EFAX-3      UNAVAIL      3     1     0  cannot open

errors: No known data errors

Що це означає: Лічильники (READ/WRITE/CKSUM) — це докази. Кілька історичних помилок не завжди катастрофа, але зростаючі значення — тренд.

Рішення: Якщо лічильники зростають після переміщення кабелів або перезавантаження — припиніть «пробувати все» і замініть компонент у домені збоїв.

Завдання 12: Правильно замінити відмовлений диск

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-3 /dev/disk/by-id/ata-WDC_WD80EFAX-NEW
...output...

Що це означає: ZFS починає resilver на новий диск, таргетований на виділені блоки (зазвичай швидше, ніж класичні RAID-перебудови).

Рішення: Моніторьте прогрес resilver. Якщо пул залишається degraded після завершення, маються додаткові проблеми (неправильний пристрій, множинні відмови або нестабільність шляху).

Завдання 13: Стежити за прогресом resilver/scrub

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Wed Dec 25 01:22:10 2025
        312G scanned at 1.12G/s, 44.8G issued at 164M/s, 3.21T total
        44.8G resilvered, 1.36% done, 05:20:11 to go
config:

        NAME                             STATE     READ WRITE CKSUM
        tank                             DEGRADED     0     0     0
          raidz1-0                       DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1           ONLINE       0     0     0
            ata-WDC_WD80EFAX-2           ONLINE       0     0     0
            ata-WDC_WD80EFAX-NEW         ONLINE       0     0     0  (resilvering)

Що це означає: «issued at» відображає фактичну швидкість запису. «scanned at» може бути вищим через метадані та read-ahead.

Рішення: Якщо resilver повзає, не вгадуйте. Перевірте I/O-банки, помилки на інших дисках або проблеми контролера.

Завдання 14: Перевірити розклад scrub і останні результати

cr0x@server:~$ zpool status -s tank
  pool: tank
 state: ONLINE
scan: scrub repaired 0B in 03:21:18 with 0 errors on Tue Dec 24 08:03:11 2025

Що це означає: Ви маєте запис про останнє завершення scrub. Якщо цього не було місяцями, ви їдете без фар.

Рішення: Якщо у вас немає періодичних scrub — заплануйте їх. Якщо вони є, але ви не оповіщаєте про помилки, підключіть ZED зараз.

Завдання 15: Підтвердити доставку подій ZFS до ZED (перевірка)

cr0x@server:~$ sudo zpool scrub tank
...output...

cr0x@server:~$ journalctl -u zfs-zed.service -n 20 --no-pager
Dec 25 01:30:02 server zed[1189]: ZED: eid=510 class=sysevent.fs.zfs.scrub_start pool=tank
Dec 25 01:30:02 server zed[1189]: ZED: executing zedlet: /usr/lib/zfs/zed.d/scrub.start

Що це означає: Запуск scrub породжує подію. Побачити її в логах ZED означає, що потік подій працює.

Рішення: Якщо не бачите подію — усувайте неполадки ZED-сервісу, дозволів або інфраструктури подій ZFS на тій платформі.

Завдання 16: Перевірити, що ZED не блокується через дозволи або відсутні директорії

cr0x@server:~$ sudo -u root test -w /var/log && echo "log dir writable"
log dir writable

cr0x@server:~$ sudo -u root test -x /usr/lib/zfs/zed.d/scrub.finish && echo "zedlet executable"
zedlet executable

Що це означає: Неможливість ZED писати логи або виконувати zedlet — нудна, поширена і руйнівна проблема для оповіщень.

Рішення: Виправте дозволи та цілісність пакунків. Не вирішуйте «chmod 777»; тримайте мінімальні та аудитуємні права.

Жарт №2: ZED як пожежна сигналізація — люди скаржаться, що вона голосна, поки одного дня не збереже їх вихідні.

Плейбук швидкої діагностики

Це послідовність «вибратися швидко». Не ідеально. Не елегантно. Оптимізовано для: що перевірити першим, другим, третім, щоб знайти вузьке місце
і вирішити, чи це диск, шлях, проблема на рівні пулу чи неправильна настройка оповіщень.

Перше: це справжня проблема пулу чи просто відсутні оповіщення?

1. Перевірте стан пулу: zpool status -x. Якщо він healthy, можливо, ви налагоджуєте ZED, а не ZFS.
2. Перевірте, що ZED живий: systemctl status zfs-zed.service і journalctl -u zfs-zed.service.
3. Спровокуйте нешкідливу подію: запустіть scrub на тестовому пулі або зробіть цикл start/stop scrub (якщо можете це терпіти). Підтвердіть, що ZED записав подію.

Друге: якщо пул degraded/faulted — локалізуйте домен відмов

1. Визначіть vdev і пристрій: zpool status POOL і зафіксуйте READ/WRITE/CKSUM лічильники.
2. Знесіть by-id до реального пристрою: ls -l /dev/disk/by-id/ щоб отримати вузол ядра.
3. Перегляньте логи ядра: dmesg -T на предмет скидань, тайм-аутів, помилок транспорту. Проблеми шляху часто видно тут першими.
4. Перевірте SMART: smartctl -a на предмет pending/uncorrectable секторів і логів помилок.

Третє: вирішіть, чи можна стабілізувати без заміни

1. Якщо це схоже на проблему шляху: пересадіть/замініть кабель, переставте диск в інший відсік, оновіть прошивку HBA (ретельно), перевірте живлення.
2. Якщо це проблема медіа диска: замініть диск. Не домовляйтесь із pending секторами.
3. Після зміни: слідкуйте за resilver і знову перевірте лічильники. Якщо лічильники продовжують рости — зупиніться і розширте діагностику до контролера/бекплейну.

Четверте: перевірте якість оповіщень

1. Переконайтесь, що оповіщення дієві: включайте ім’я пулу, ідентифікатор пристрою, поточний zpool status і останні результати scrub.
2. Тротлінг і дедуплікація: повідомляйте при переходах стану; надсилайте email/тикет при повторюваних м’яких помилках.
3. Проводьте щоквартальні відпрацювання: симулюйте подію (scrub start/finish, тестовий zedlet) і підтвердіть, що потрібна команда її отримує.

Три корпоративні міні-історії зі сховищ

Міні-історія 1: Інцидент через невірне припущення

Середня SaaS-компанія запускала ZFS на Linux для кількох «дружніх до даних» нод. Вони перейшли з старого RAID-контролера і
відчували впевненість: контрольні суми, scrub, snapshots — все як треба. Також у них було моніторинг. А принаймні так вважали.

Неправильне припущення було тонким: «оповіщення ZFS — частина пакунка ZFS». Хтось встановив OpenZFS, створив пули, запланував scrub
і забув. ZED був встановлений, але не увімкнений. Ніхто не помітив, бо в буденності ZFS тихий, коли все добре.

Через кілька місяців диск почав логувати інтермітентні тайм-аути. ZFS повторно запитував, відновлював з паритету і продовжував сервіс.
Пул коротко перейшов у DEGRADED, потім повернувся в ONLINE, коли диск повернувся. Немає оповіщення, немає тикета, ніхто не замінив.
Лічильники помилок повзли, як повільна течія за стіною.

Реальний інцидент настав при другій відмові диска під час інтенсивного читання. Пул пішов у жорсткий DEGRADED і додаток побачив латентність.
Користувачі повідомляли «повільні завантаження». Оператори почали з неправильного кінця (налаштування додатка, балансування навантаження),
бо не мали раннього сигналу.

Постмортем попункти були нудні і правильні: увімкнути ZED, підключити оповіщення до ротації on-call, надсилати page при деградації пулу,
і включити by-id імена пристроїв, щоб хтось міг витягти правильний диск без сеансів.

Міні-історія 2: Оптимізація, що відвернула

Команда інженерії даних хотіла менше листів. Вони втомилися від «scrub started» і «scrub finished», що засмічували пошту, і мали рацію:
оповіщення не були пріоритизовані й ніхто їх не читав уважно.

«Оптимізація» полягала у повному відключенні zedlet, пов’язаних зі scrub. Їхня логіка: «ми вже запускаємо scrubs щомісяця; якщо щось не так, пул перейде в degraded».
Остання частина — мінне поле. Результати scrub можуть виявити корупцію, яку ZFS відновив тихо. Це не degraded пул. Це попереджувальний постріл.

Через кілька місяців scrub міг би виявити і відновити checksum-помилки на одному vdev, вказуючи на поганий SAS-кабель. Замість цього ніхто не побачив сигнал.
Кабель погіршився. Згодом диск впав під час resilver, спричиненого іншим обслуговуванням, і resilver затягнувся, підвищивши ризики.
Команда «замовчала систему», яка врешті провалилася голосно.

Вони виправили це, знову увімкнувши оповіщення scrub, але змінили політику: події scrub start йшли у логи низького пріоритету; scrub finish з відновленнями або помилками
створював тикет і вимагав людської перевірки. Шум зменшився. Сигнал відновлено. Це правильний компроміс.

Міні-історія 3: Нудна практика, що врятувала день

Корпоративна IT-група керувала флотом VM-хостів на ZFS. Їхня платформа зберігання не була захопливою; вона була навмисно прісною.
Вони мали суворий стандарт: by-id іменування пристроїв, щоквартальна перевірка scrub і on-call runbook з заміни диска на одній сторінці.

Одного четверга ZED прислав page «pool DEGRADED» з вказаним vdev і фізичним мапінгом слоту. Хост все ще обслуговував VM.
Спокуса в корпоративному середовищі — відкласти роботу, бо «нема відмови». Вони не стали цього робити.

On-call дотримався runbook: підтвердив статус, перевірив SMART, логи ядра і замінив диск. Resilver завершився, пул повернувся в ONLINE,
і вони закрили цикл, перевіривши наступний scrub. Ніяких ескалацій керівництва, ніякого впливу на клієнтів, ніякої драматичної war room.

Через два дні ще один хост у тому ж стояку мав подію живлення, що спричинила скидання контролера. Якби перший хост залишався degraded,
друга подія могла б перетворити рутинну заміну апаратури на складне відновлення. Нудна практика дала їм маневр.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «Ми ніколи не отримуємо оповіщення ZFS»

Корінь: Сервіс ZED не увімкнений/не запущений, або zedlet не ввімкнені через /etc/zfs/zed.d.

Виправлення: Увімкніть і запустіть ZED; перевірте потік подій командою scrub start і дивіться journald на рядки виконання.

2) Симптом: «ZED логуює події, але листи не доходять»

Корінь: Відсутня поштовая програма, заблокований вихідний SMTP або неправильно налаштовані ZED_EMAIL_ADDR/ZED_EMAIL_PROG.

Виправлення: Запустіть ту саму поштову команду вручну з хоста; виправте relay/firewall/DNS; потім повторно протестуйте ZED.

3) Симптом: «Шторм пейджів під час флапінгу диска»

Корінь: Відсутність тротлінгу/дедуплікації; оповіщення при кожному інкременті помилок замість переходу стану.

Виправлення: Налаштуйте інтервал повідомлень; пейджіть при переходах стану пулу; відкривайте тикети при повторюваних м’яких помилках з порогами за швидкістю.

4) Симптом: «Пул показує checksum-помилки на кількох дисках одночасно»

Корінь: Спільна домена відмови (HBA, бекплейн, expander, кабель, живлення) або корупція пам’яті на системах без ECC.

Виправлення: Припиніть безладну заміну дисків. Перегляньте dmesg на предмет скидань транспорту, перевірте прошивку/драйвер HBA, поміняйте кабелі і оцініть стан пам’яті/ECC.

5) Симптом: «Scrub завершився, відновлено байти, але всі проігнорували це»

Корінь: Політика оповіщень трактує результати scrub як шум; немає робочого процесу для розслідування відновленої корупції.

Виправлення: Направляйте «scrub finished з відновленнями/помилками» у тикет, який вимагає перегляду і подальших перевірок (SMART, кабелі, лічильники).

6) Симптом: «Resilver тягнеться вічно і пул залишається крихким»

Корінь: Підлеглий I/O-боттлнек, додаткові сумнівні диски або проблеми контролера, що викликають повторні спроби.

Виправлення: Перевірте лічильники помилок інших vdev, dmesg на предмет скидань, і SMART на предмет повільних секторів. Якщо кілька дисків хворі — стабілізуйте апарат перед інтенсивним resilver.

7) Симптом: «ZED запускає zedlet, але вони мовчки падають»

Корінь: Дозволи, відсутній біт виконуваності, відсутні залежності в PATH або скрипти, що чекають інтерактивної оболонки.

Виправлення: Робіть zedlet самодостатніми: абсолютні шляхи, явне середовище, суворе оброблення помилок, логування збоїв у journald/syslog.

8) Симптом: «Оператори замінили неправильний диск»

Корінь: Пули побудовано на іменах /dev/sdX; оповіщення не містить стабільних ідентифікаторів; немає процесу мапінгу слотів.

Виправлення: Використовуйте /dev/disk/by-id у пулах, включайте by-id у оповіщення і ведіть мапінг з bay/WWN до інвентарю хостів.

Чеклісти / покроковий план

Чекліст A: Мінімально життєздатні оповіщення ZED (зробіть цього тижня)

1. Підтвердьте, що ZED встановлено і працює: systemctl status zfs-zed.service.
2. Увімкніть ZED при завантаженні: systemctl enable zfs-zed.service.
3. Виберіть місце доставки повідомлень (пошта або локальний інтеграційний скрипт).
4. Встановіть ZED_EMAIL_ADDR (або wrapper) і ZED_NOTIFY_INTERVAL_SECS у /etc/zfs/zed.d/zed.rc.
5. Увімкніть лише ті zedlet, на які ви зможете реагувати (scrub finish, зміни стану пулу, checksum-помилки).
6. Запустіть scrub на некритичному пулі і перевірте, що бачите події ZED у journald.
7. Переконайтесь, що on-call отримує оповіщення і може ідентифікувати диск за стабільним іменем.

Чекліст B: Коли ви отримали оповіщення «pool DEGRADED»

1. Запустіть zpool status POOL. Зафіксуйте його в тикеті.
2. Визначте постраждалий vdev і пристрій by-id; зіставте з вузлом ядра.
3. Перегляньте dmesg -T на предмет transport-помилок і скидань.
4. Запустіть smartctl -a на пристрої; дивіться pending/uncorrectable сектори і лог помилок.
5. Прийміть рішення: виправлення шляху (кабель/бекплейн/HBA) чи заміна диска.
6. Виконайте зміну, потім слідкуйте за resilver і перевірте лічильники.
7. Після повернення в ONLINE, заплануйте/перевірте scrub і слідкуйте за новими відновленнями.

Чекліст C: Щоквартальне відпрацювання оповіщень (щоб довіряти їм)

1. Виберіть один хост на клас сховища (NVMe mirror, RAIDZ тощо).
2. Запустіть scrub і підтвердіть, що ZED бачить scrub_start.
3. Переконайтесь, що оповіщення про завершення scrub містять відновлені байти і підсумок помилок.
4. Перевірте, що політика пейджингу спрацьовує на симульованому degraded стані (якщо можливо — на тестовому пулі).
5. Перегляньте тротлінг: упевніться, що немає штормів пейджів для повторюваних м’яких помилок.
6. Оновіть runbook з новими полями подій, які видає ваша версія ZED.

FAQ

1) Що таке ZED?

ZED — це ZFS Event Daemon. Він слухає події ZFS і запускає обробники (zedlet), щоб повідомити людей або ініціювати автоматичні дії.

2) Чи потрібен ZED, щоб ZFS працював безпечно?

ZFS може виявляти і виправляти багато проблем без ZED. ZED потрібен для того, щоб ви працювали безпечно: він перетворює тихий ризик на видиме завдання.

3) Які події мають пейджити людей, а які створювати тикети?

Пейджте при переходах стану, що зменшують надмірність (DEGRADED/FAULTED, видалення пристрою, невідновлені помилки). Створюйте тикети для результатів scrub з відновленнями і повторюваних м’яких помилок.

4) Чому я бачу checksum-помилки, якщо ZFS «самовідновлюється»?

Тому що ZFS виявив погані дані і відновив їх з надмірності. Checksum-помилка — це слід, що щось у стеку поводиться неправильно.
Сприймайте це як попередження і розслідуйте, особливо якщо кількість помилок зростає.

5) Як часто слід запускати scrub?

Загальна практика — щомісячно для великих пулів, іноді щотижня для менших або ризикованіших флотів. Правильна частота залежить від часу ребілду,
розміру дисків і терпимості до ризику. Що б ви не вибрали — оповіщайте про помилки і відновлення.

6) Чи може ZED надсилати оповіщення напряму в Slack/PagerDuty?

Зазвичай це роблять через wrapper-скрипт, який викликає zedlet (або додають/змінюють zedlet) і шлють у ваш внутрішній pipeline оповіщень.
Зробіть логіку на боці ZED мінімальною і стійкою.

7) Чому мій пул перейшов у DEGRADED, а потім повернувся в ONLINE?

Пристрої можуть флапати: короткі відключення, скидання контролера або тайм-аут-шторм. ZFS може помітити пристрій як UNAVAIL, а потім реінтегрувати його.
Це не «гаразд». Це проблема надійності шляху або пристрою.

8) Чи можна покладатися на SMART «PASSED», щоб не замінювати диск?

Ні. SMART overall health — грубий евристичний показник. Pending сектори, uncorrectable і логи помилок важливіші. Лічильники помилок ZFS теж мають значення.

9) У чому різниця між scrub і resilver для оповіщень?

Scrub — це планове сканування цілісності; оповіщайте про завершення і про те, чи були відновлення/помилки. Resilver — це відновлення/реконструкція після змін пристрою;
оповіщайте про початок, аномалії прогресу і завершення.

10) Що робити, якщо ZED занадто шумний?

Не відключайте його глобально. Налаштуйте: тротлінг, пейджинг лише при переходах стану і направляйте інформаційні події в логи.
Шум — це проблема політики, а не причина сліпнути.

Практичні наступні кроки

Якщо ви зробите лише три речі після прочитання цього, зробіть ці:

1. Переконайтесь, що ZED працює скрізь, де ви використовуєте ZFS, запускається при завантаженні і логгує у місце, яке ви реально перевіряєте.
2. Зробіть результати scrub дієвими: оповіщайте про завершення scrub з відновленнями/помилками і створіть робочий процес для розслідування і закриття циклу.
3. Пейджте при втраті надмірності: DEGRADED/FAULTED — це не порада. Це ZFS, що каже вам, що ваш запас безпеки зник.

Потім зробіть дорослий варіант: проводьте щоквартальні відпрацювання оповіщень, тримайте zedlet маленькими і прісними, і створюйте оповіщення з достатнім контекстом,
щоб людина за одну хвилину вирішила, замінювати диск, кабель чи контролер.

ZFS уже виконує роботу з детекції. ZED — це те, як ви не дозволите цій роботі тихо померти всередині машини.