ZFS zpool events: журнал, який ви ігноруєте, поки він не врятує вас

Що таке zpool events насправді (і чого вони не є)

zpool events — це фід подій ZFS. Він показує хронологію значущих подій, пов’язаних з пулом:
помилки дискового вводу/виводу, проблеми з контрольними сумами, зміни стану vdev, початок і завершення scrub, resilver, та різні звіти з управління помилками («ereports»).
Це те, що ви хотіли б зберегти, коли хтось питає: «Коли це почалося?»

Це не заміна для zpool status. Уявіть це так:

• zpool status каже вам про поточний стан та стислу історію (недавні помилки, поточний resilver/scrub тощо).
• zpool events розповідає послідовність подій, що привели до цього стану, часто з більшим контекстом і точною міткою часу.
• Системні логи (повідомлення ядра, journalctl) показують оточуючі симптоми на рівні ОС: ресети, тайм-аути, флапи лінків.

Під капотом на багатьох платформах ZFS інтегрується в конвеєр управління помилками. На illumos/Solaris ви побачите
словник Fault Management Architecture (FMA) більш явно. На Linux, ZED (ZFS Event Daemon) і реалії, схожі на udev,
забезпечують міст «щось сталося» до скриптів, email та систем тикетів. Слова різняться; операційний намір той самий: перетворити низькорівневе дивне явище на оповіщення перш ніж дані опиняться під загрозою.

Ваша задача — не вивчити напам’ять усі класи подій. Ваша задача — виробити звичку зіставляти:
event → device → симптом навантаження → ризик → дія. Робіть це — і zpool events перестане бути тривіальністю і стане важелем.

Перший сухий жарт, як і обіцяно: ZFS має чудове почуття гумору — кожна «checksum error» це жарт, де ваш постачальник зберігання є підводкою.

Цікаві факти та трохи історії

Це не ностальгія. Це підказки, чому інструменти виглядають так, як вони виглядають, і чому деякі поведінки дивують людей.

1. ZFS народився у Sun Microsystems і спроєктований так, щоб цілісність даних була першокласною характеристикою, а не опціональною.
2. End-to-end checksumming означає, що ZFS перевіряє дані від диска до пам’яті до шляху читання додатка; він може виявити приховану корупцію, яку RAID-контролери охоче «завершують».
3. Мова «ereport» походить з FMA (Fault Management Architecture), де відбувається структуроване описання несправностей та діагнозів, а не вільноформатні лог-повідомлення.
4. zpool scrub — це проактивна верифікація; це не «дефраг» і не «театр обслуговування». Це контрольований спосіб знайти латентні помилки до того, як диск відмовить.
5. Resilvering є інкрементним в сучасному OpenZFS: він може копіювати лише те, що використовується (особливо з функціями типу sequential resilver), скорочуючи час відновлення порівняно зі старими RAID.
6. ZFS свідомо віддає перевагу коректності над оптимізмом; воно деградує пул, ніж продовжувати вдавати, що все гаразд, якщо не можна довіряти читанню з пристрою.
7. Існує демон ZED, бо події потребують дій; вивід команд корисний, але операційно вам потрібні хуки: оповіщення, робочі процеси заміни та автоматичний експорт при подіях видалення.
8. Історично стек зберігання ховав помилки за «повторними спробами» та кешами контролерів; ZFS зробив помилки видимими, що чудово — поки ви не ігноруєте цю видимість.
9. OpenZFS став мультиплатформенним (Linux, FreeBSD, illumos), і «труби» подій різняться в залежності від ОС, тому поради мають вказувати припущення про платформу.

Одне реальне оперативне наслідок: люди, що мігрують з апаратного RAID, часто припускають, що контролер «позбавить від проблем».
ZFS припускає протилежне: стек недовірливий, доки не доведено зворотнє. Це не параноїдальність. Це досвід.

Практична ментальна модель: від симптомів до подій і рішень

1) Події — це сигнали; status — це діагноз у стислій формі

Коли vdev переходить у DEGRADED, zpool status каже вам, що зараз. Але zpool events може пояснити, чи це було:
шторм ресетів лінку, один поганий кабель, тайм-аути прошивки, проблема з живленням або справжній вихід накопичувача. Для кожного з цих випадків — різні виправлення.

2) Не всі помилки однаково важливі

Операційно важливі три категорії:

• Транзитні помилки транспорту (тайм-аути, ресети): часто кабелі/HBA/backplane/живлення. Замінити диски — і проблема залишиться.
• Постійні помилки читання: ймовірно, відмова медіа. Замініть пристрій; перевірте резервність і почніть resilver.
• Помилки контрольних сум: можуть бути викликані диском, кабелем, контролером, оперативною пам’яттю (рідше з ECC), або прошивкою. Потрібна кореляція, а не здогадки.

3) «Scrub found errors» означає «ви щойно дізналися» — не «панікуйте»

Помилки, знайдені scrub, — це телеметрія раннього попередження. Ваша реакція має бути спокійною й методичною:
ідентифікуйте який(і) пристрій(и), типовість помилок, чи повторюються вони, і чи резервність покрила пошкодження.
Хронологія подій допоможе визначити, чи це поодинокий інцидент або тренд.

4) Операційно ви гнатеся за двома питаннями

• Чи дані зараз під загрозою? (pool faulted, немає резервності, помилки під час scrub/resilver)
• Чи платформа бреше? (нестабільність транспорту, переривчасті ресети, «випадкові» checksum помилки на кількох дисках)

Перше питання визначає терміновість. Друге вирішує, чи ваше виправлення справді вирішить проблему.

Одна цитата, яка має бути в кожному on-call: «Hope is not a strategy.» — Gene Kranz

План швидкої діагностики (що перевіряти 1-ше/2-ге/3-тє)

Це послідовність, яку я використовую, коли пул виглядає хворим, продуктивність падає, або хтось постить скриншот DEGRADED в чат
без іншого контексту. Вона побудована для швидкості і щоб уникнути класичної помилки: заміни дисків до того, як ви знаєте, що вийшло з ладу.

Перше: встановіть поточний ризик і чи ви вже в режимі «зупинити кровотечу»

• Перевірте стан пулу (zpool status -x, zpool status): чи ви degraded, faulted, suspended, resilvering або scrubbing?
• Перевірте, чи резервність збережена: скільки vdev, який рівень парності, чи є відсутні пристрої?
• Перевірте, чи помилки все ще ростуть: повторювані лічильники read/write/cksum що збільшуються вказують на активну проблему.

Друге: витягніть хронологію подій і визначте клас відмови

• Подивіться недавні події (zpool events -v): чи бачите тайм-аути, видалення, checksum ereports, scrub finish з помилками?
• Корелюйте мітки часу з логами ядра: ресети лінків і SCSI-помилки часто розкажуть історію транспорту.
• Шукайте розповсюдження: один диск проти кількох дисків на тому самому HBA/backplane. Багато дисків, що відмовляють одночасно, зазвичай не «невдача».

Третє: оберіть напрям — заміна апаратури, стабілізація транспорту або обмеження навантаження

• Один пристрій із постійними помилками читання: готуйте заміну, виведіть з лінії/замініть, спостерігайте за resilver.
• Кілька пристроїв з переривчастими проблемами: перевірте кабелі, прошивку/драйвер HBA, backplane, живлення; уникайте каскадних відмов під час важкого відновлення.
• Scrub/resilver повільний: перевірте I/O насичення, невідповідність recordsize/workload, особливості vdev, поведінку SMR або хворий пристрій, що гальмує vdev.

Якщо запам’ятати лише одне: найшвидший спосіб прогавити день — замінити апарат до класифікації відмови.
Події допоможуть вам класифікувати.

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

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

Завдання 1: «Чи щось взагалі не так?» швидка перевірка

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

Значення: ZFS зараз не бачить відомих несправностей.
Рішення: Якщо користувачі скаржаться на повільну роботу, перейдіть до триажу продуктивності (iostat, latency, queue depth). Все одно перевірте events на предмет недавніх транзитних проблем.

Завдання 2: Отримати повну картину здоров’я (не будьте лінивими)

cr0x@server:~$ zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:12:11 with 2 errors on Sun Dec 21 01:10:44 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     2

errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/guest42.img

Значення: Scrub виявив незаписувану корупцію, що зачіпає принаймні один файл; помилки контрольних сум вказують на конкретний шлях диска.
Рішення: Розглядайте це як інцидент цілісності даних. Визначте, чи корупція обмежена цим файлом, відновіть з бекапу/снапшоту та негайно розслідуйте диск/транспорт.

Завдання 3: Витягти недавні події з докладними деталями

cr0x@server:~$ zpool events -v | tail -n 40
time: 2025-12-21.01:10:44
eid: 1876
class: scrub_finish
pool: tank
pool_guid: 1234567890123456789
scrub_errors: 2
scrub_repaired: 0
scrub_time_secs: 11531

time: 2025-12-21.00:58:19
eid: 1869
class: ereport.fs.zfs.checksum
pool: tank
vdev_guid: 9876543210987654321
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 52
zio_objset: 54
zio_object: 102938
zio_level: 0

Значення: У вас є checksum ereport прив’язаний до конкретного vdev path перед завершенням scrub з помилками.
Рішення: Корелюйте цю мітку часу з логами ядра; вирішіть, чи диск поганий, чи транспорт нестабільний. Почніть з перевірки транспорту, якщо подібні події є для кількох дисків.

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

cr0x@server:~$ zpool events -f
time: 2025-12-25.09:14:03
eid: 2101
class: resilver_start
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1

time: 2025-12-25.09:16:27
eid: 2104
class: ereport.fs.zfs.io
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 5

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

Завдання 5: Підтвердити властивості пулу, що впливають на поведінку під час інцидентів

cr0x@server:~$ zpool get -o name,property,value,source autoreplace,failmode,autotrim tank
NAME  PROPERTY     VALUE     SOURCE
tank  autoreplace  off       default
tank  failmode     wait      default
tank  autotrim     on        local

Значення: failmode=wait може затримувати I/O, коли пул не може безпечно продовжувати; autoreplace=off означає, що ви маєте явно замінювати пристрій.
Рішення: Для флоту стандартизувати ці значення. Під час інциденту знання failmode пояснить «чому все зависло» і підкаже, чи варто експортувати/імпортувати або переключати.

Завдання 6: Визначити точний диск за vdev path

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80...-part1
lrwxrwxrwx 1 root root 10 Dec 25 08:59 /dev/disk/by-id/ata-WDC_WD80...-part1 -> ../../sdc1

Значення: «Дружній» шлях by-id зараз відповідає /dev/sdc1.
Рішення: Використовуйте by-id шляхи в конфігурації ZFS, щоб зменшити «рулетку sdX» після перезавантажень. Для заміни підтвердіть фізичний слот за допомогою інструментів enclosure, якщо вони доступні.

Завдання 7: Корелювати події ZFS з скидами/тайм-аутами на рівні ОС (Linux)

cr0x@server:~$ journalctl -k --since "2025-12-21 00:50" --until "2025-12-21 01:05" | egrep -i "sd[cde]|ata|sas|reset|timeout|I/O error" | tail -n 20
Dec 21 00:58:11 server kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 21 00:58:12 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 21 00:58:12 server kernel: ata7: hard resetting link
Dec 21 00:58:17 server kernel: sd 7:0:0:0: [sdc] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 21 00:58:17 server kernel: sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
Dec 21 00:58:17 server kernel: blk_update_request: I/O error, dev sdc, sector 771920896 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Значення: Це виглядає як реальна проблема медіа (Medium Error) плюс ресети. Це не просто «тимчасове хитання кабелю».
Рішення: Замініть диск. Водночас перевірте кабелі/backplane, якщо бачите ресети на декількох портах.

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

cr0x@server:~$ zpool status tank | sed -n '1,20p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:44:09 with 0 errors on Sun Dec 14 03:12:33 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Значення: Недавній scrub завершився чисто; добрий базовий рівень.
Рішення: Якщо сьогоднішній інцидент «раптовий», порівняйте з часами подій. Чистий scrub минулого тижня робить «місяці прихованої корупції» менш імовірними.

Завдання 9: Запустити scrub свідомо (і спостерігати за проблемами)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -i "scan|scrub"
  scan: scrub in progress since Thu Dec 25 09:22:10 2025
        312G scanned at 1.12G/s, 74.2G issued at 273M/s, 4.21T total
        0B repaired, 1.72% done, no estimated completion time

Значення: Scrub запущено; «issued» показує фактичні запити на читання. Якщо він повзе — щось обмежує.
Рішення: Якщо швидкість scrub падає, перевірте на хворий диск, SMR-диски або перевантажену систему. Розгляньте планування scrub у непіковий час або тимчасове зменшення навантаження.

Завдання 10: З’ясувати, чи помилки сконцентровані на одному vdev (швидкий погляд по vdev)

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            /dev/disk/by-id/ata-ST4000...  ONLINE       0     0     0
            /dev/disk/by-id/ata-ST4000...  DEGRADED     0     0    34

errors: No known data errors

Значення: Багато checksum помилок на одній стороні mirror, але ZFS зміг виправити їх з іншої сторони (немає постійних помилок).
Рішення: Це все одно дефект апаратури/транспорту. Плануйте заміну; не вітаєте себе за те, що резервність цього разу врятувала.

Завдання 11: Безпечно замінити відмовивший диск (приклад для mirror)

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-ST4000...bad
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-ST4000...bad /dev/disk/by-id/ata-ST4000...new
cr0x@server:~$ zpool status tank | egrep -i "state|scan|resilver"
 state: DEGRADED
  scan: resilver in progress since Thu Dec 25 09:31:02 2025
        98.4G scanned at 1.02G/s, 21.7G issued at 231M/s, 98.4G total
        21.7G resilvered, 22.06% done, 0:05:09 to go

Значення: Ініційовано заміну; resilver рухається.
Рішення: Слідкуйте за новими подіями під час resilver. Якщо інші пристрої почнуть помилятися, зупиніться і переосмисліть платформу (HBA/backplane/живлення) перш ніж перетворити одну відмову на три.

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

cr0x@server:~$ systemctl status zfs-zed.service --no-pager
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-25 07:12:09 UTC; 2h 19min ago
       Docs: man:zed(8)
   Main PID: 1124 (zed)
      Tasks: 2 (limit: 38454)
     Memory: 4.3M
        CPU: 1.221s

Значення: ZED працює, отже події можуть тригерити сповіщення та скрипти.
Рішення: Якщо ZED не працює, ви покладаєтесь на людей, щоб помічали zpool status. Виправте це — сьогодні, не «після закриття кварталу».

Завдання 13: Переглянути недавню активність ZED на предмет пропущених оповіщень

cr0x@server:~$ journalctl -u zfs-zed.service --since "2025-12-21 00:00" | tail -n 25
Dec 21 00:58:20 server zed[1124]: eid=1869 class=ereport.fs.zfs.checksum pool=tank
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/zed.rc
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/all-syslog.sh
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/zed.email
Dec 21 00:58:20 server zed[1124]: email: to=storage-oncall@example.internal subject="ZFS checksum error on tank"

Значення: ZED помітив checksum ereport і запустив alert хуки.
Рішення: Якщо on-call каже «жодного оповіщення», розслідуйте маршрутизацію пошти/інтеграцію моніторингу. ZFS виконав свою частину; ланцюг сповіщень може бути слабким місцем.

Завдання 14: Перевірити симптоми suspend пулу (інцидент «все зависло»)

cr0x@server:~$ zpool status tank | egrep -i "state|suspend|status"
 state: ONLINE
status: One or more devices has been removed by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a degraded state.
action: Online the device using 'zpool online' or replace the device with 'zpool replace'.

Значення: Тут не suspended, але це місце, де ви побачите це. Якщо пул suspended, додатки часто зависають на I/O.
Рішення: Якщо suspended — припиніть навантажувати його повторами. Стабілізуйте апарат, розгляньте експорт/імпорт і пріоритезуйте евакуацію даних або failover.

Завдання 15: Отримати чистий список «що змінилося останнім часом» з events

cr0x@server:~$ zpool events | egrep "vdev_(add|remove)|config_sync|scrub_start|scrub_finish|resilver_(start|finish)" | tail -n 20
time: 2025-12-25.09:14:03 class: resilver_start
time: 2025-12-25.09:20:11 class: config_sync
time: 2025-12-25.09:37:18 class: resilver_finish
time: 2025-12-25.09:40:00 class: scrub_start

Значення: Ви бачите життєвий цикл операцій: початок/завершення resilver, config sync, початок scrub.
Рішення: Використовуйте це для пояснення причини/наслідку в нотатках інциденту і щоб помітити «хтось запустив scrub у пікові години» без здогадок.

Завдання 16: Витягнути події з відомого поганого часу для хроніки інциденту

cr0x@server:~$ zpool events -v | awk '/time: 2025-12-21/{p=1} p{print}'
time: 2025-12-21.00:58:19
eid: 1869
class: ereport.fs.zfs.checksum
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 52

Значення: Швидкий спосіб витягти релевантні блоки подій для постмортему або тикета.
Рішення: Зберігайте цей вивід під час інцидентів. Події можуть прокручуватися або бути ефемерними залежно від платформи та інструментів; ваш тикет не повинен покладатися на «ми відтворимо це пізніше».

Три корпоративні міні-історії (помилки, яких можна уникнути)

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

Компанія керувала середнім кластером віртуалізації на ZFS mirror. Хороший вибір: прості, швидкі відновлення, чіткі домени відмов.
Runbook on-call казав: «Якщо диск показує checksum errors — замініть його.» Це не погана порада. Вона також неповна.

Одного вівторка checksum errors почали з’являтися на двох хостах — різні пули, різні диски, такий самий тип HBA. On-call замінив диск на хості A.
Розпочався resilver, потім на хості A з’явилися ще checksum errors, потім тайм-аути, потім пул зависнув настільки, що тригернули watchdog гостя.
«Погана партія дисків», — сказали деякі, бо це та історія, яку всі чули раніше.

Слід подій — який ігнорували до кінця — показав більш специфічну картину: сплески I/O помилок і ресети лінків, що збіглися з певним оновленням модуля ядра.
Диски не відмовляли незалежно; транспорт флапав під навантаженням. Заміна диска підсилювала навантаження (читання/записи resilver), що робило флапи гіршими.

Виправлення було не в «більше дисків». Воно полягало в зафіксуванні версії драйвера HBA, налаштуванні параметрів черги та запуску resilver тільки після підтвердження стабільності транспорту.
Один диск все ж таки замінили — бо він мав реальні медіа-помилки — але не до того, як зупинили системну відмову.

Неправильне припущення: «Checksum errors означають диск.» Іноді так. Іноді це означає «весь ваш I/O шлях під сумнівом». Події підкажуть, у якій ви історії.

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

Інша команда любила дашборди. Вони хотіли менше пейджів, менше «фальшивих спрацювань» і спокійніший on-call. Повага до цілей.
Вони вирішили оповіщати лише при змінах стану zpool status: ONLINE→DEGRADED, DEGRADED→FAULTED. Ніяких оповіщень для подій, як тайм-аути чи одиночні checksum ereports.

Оточення працювало місяцями. Потім backplane почав періодично скидати один диск на кілька секунд під важкими записами.
ZFS тимчасово позначав його як недоступний, повторював спроби і відновлював. Пул ніколи не залишався в degraded досить довго, щоб згенерувати оповіщення про «зміну стану».
Тим часом zpool events фактично кричало в порожнечу з повторюваним паттерном: I/O errors, device removal, device return, config sync.

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

Після інциденту вони знову ввели оповіщення для конкретних класів подій (removals, I/O ereports, checksum bursts) з обмеженням частоти та кореляцією.
Менше пейджів? Так. Але не через сліпоту. Через розумніші правила.

Другий сухий жарт: Найспокійніша система моніторингу також найдешевша — поки ви не включите вартість простою.

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

Фінансова організація працювала на ZFS на парі нод зберігання. Нічого екзотичного: RAIDZ2 для масивних датасетів, дзеркальний SLOG для sync-навантажень, регулярні scrubs, і ZED інтегрований в тикети.
Налаштування було настільки нудним, що ніхто про нього не говорив, і це саме те, чого ви хочете від збереження даних.

Під час рутинного щотижневого scrub ZFS зафіксував кілька checksum помилок на одному диску. Постійних помилок даних не було. Пул залишився ONLINE.
ZED згенерував тикет з шляхом пристрою by-id, хостом і контекстом scrub. Тикет не був терміновим, але ігнорувати його не стали.

Інженер збереження подивився zpool events -v і побачив, що checksum ereports були згруповані в п’ятихвилинному вікні.
Логи ядра у тому вікні показали один ресет лінії на одній SAS-lane — класичний «транспортувальний гик». Вони перемонтували кабель у вікні техобслуговування, потім прогнали scrub знову.
Помилок немає.

Через два місяці та сама backplane почала гірше працювати в іншому слоті. Цього разу, оскільки була історія,
вони одразу впізнали паттерн. Попередньо перемістили диски з підозрілого енклоужера до того, як він спричинив інцидент з кількома дисками.

Практика, що врятувала день, не була героїкою. Вона була: планові scrubs, подієво-орієнтовані тикети і фактичне читання хронології.
Нудно — це перевага.

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

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

1) «Пул degraded, але продуктивність нормальна» → самозаспокоєння → несподіваний простій

• Симптом: стан DEGRADED декілька днів; користувачі не скаржаться.
• Корінь: Ви працюєте без резервного запасу. Наступна відмова призведе до простою або втрати даних.
• Виправлення: Швидко відновіть/замініть резервність. Використовуйте zpool events -v, щоб підтвердити, що відмова локалізована, а не по всьому транспорту, перш ніж замінювати.

2) «Випадкові checksum помилки на кількох дисках» → неправильно діагностовано як «погані диски» → марні заміни

• Симптом: checksum errors з’являються на різних дисках, іноді після ребутів або сплесків навантаження.
• Корінь: прошивка/драйвер HBA, поганий SAS expander/backplane, поганий кабель, нестабільне живлення.
• Виправлення: Корелюйте події за мітками часу з логами ядра; шукайте ресети/тайм-аути на тому самому шині. Спочатку стабілізуйте транспорт, потім замінюйте диски, що все ще мають постійні медіа-помилки.

3) «Scrub повільний, має бути нормально» → прихована хвороба пристрою → resilver тягнеться вічно

• Симптом: Scrub/resilver працює з фракцією очікуваної швидкості; іноді «без ETA».
• Корінь: Один диск багато разів повторює читання, SMR-диски при тривалому випадковому I/O, або система насичена конкурентним навантаженням.
• Виправлення: Спостерігайте zpool events -f під час scrub на предмет I/O помилок; перевірте логи ОС на повто

  рні читання/тайм-аути; розгляньте переміщення важких навантажень або заміну повільного/відмовного пристрою.

4) «Немає оповіщень, отже проблем немає» → ZED не працює → тихе деградування

• Симптом: Хтось виявляє проблеми вручну; жодних тикетів/пейджів не створено.
• Корінь: ZED вимкнено, неправильно налаштовано email/handler, або моніторинг перевіряє zpool status раз на день.
• Виправлення: Увімкніть і перевірте ZED; протестуйте контрольований випадок (скільки-небудь scrub start/finish) і впевніться, що оповіщення доходять до людей.

5) «Заміни диск негайно» → стрес від rebuild викликає латентні проблеми транспорту → каскадні відмови

• Симптом: Як тільки починається resilver, інші диски починають помилятися, або той самий диск «відмовляє сильніше».
• Корінь: Відновлення збільшує I/O і виявляє ненадійний HBA/backplane/кабелі.
• Виправлення: Перед заміною перевірте патерни на кількох дисках у zpool events. Якщо підозрюється нестабільність транспорту, стабілізуйте її, потім виконайте rebuild.

6) «Виявлено Permanent errors» → панічне видалення → ускладнення відновлення

• Симптом: errors: Permanent errors have been detected... перераховує файли.
• Корінь: ZFS не зміг відновити деякі блоки з резервних копій. Видалення файлу може знищити судові докази або ускладнити відновлення на рівні додатка.
• Виправлення: Зробіть снапшот поточного стану (якщо можливо), ідентифікуйте уражені об’єкти, відновіть з бекапу/снапшоту де потрібно і збережіть події/логи для аналізу причин.

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

Чекліст A: Налаштувати моніторинг «я не буду здивований» для zpool events

1. Увімкніть ZED і підтвердіть, що він працює: systemctl status zfs-zed.service.
2. Переконайтеся, що є хоча б один шлях доставки: syslog, email або хук у тикет-систему через zedlets.
3. Оповіщайте про ці класи подій (з обмеженням частоти): device removal, I/O ereports, checksum ereports, scrub finish з помилками, resilver finish з помилками.
4. Включайте vdev by-id path в оповіщення. Не оповіщайте лише з /dev/sdX.
5. Зберігайте коротку обертальну історію виводу zpool events -v в системі інцидентів під час пейджів (копіювання/вставка підходить; ідеальність вторинна, коли ви втрачаєте диск).

Чекліст B: Коли пул переходить у DEGRADED

1. Запустіть zpool status і зафіксуйте весь вивід у тикеті.
2. Запустіть zpool events -v | tail -n 200 і зафіксуйте його.
3. Визначте, чи проблема одно- або багатопристрійна.
4. Корелюйте з логами ядра щодо ресетів/тайм-аутів навколо першої мітки часу з проблемою.
5. Якщо постійні медіа-помилки на окремому пристрої: offline/replace; спостерігайте за resilver в реальному часі.
6. Якщо патерн транспорту: призупиніть ризикові операції; перевірте кабелі/HBA/backplane/живлення; потім переходьте до замін.
7. Після resilver запустіть scrub і переконайтеся, що scrub_finish має scrub_errors: 0.

Чекліст C: Після безпомилкового виправлення (те, що люди пропускають)

1. Підтвердіть, що пул ONLINE і zpool status -x чистий.
2. Перегляньте події з початку інциденту; впевніться, що немає повторюваних I/O або checksum ereports.
3. Зробіть одну стійку зміну: фіксація прошивки, запис заміни кабелю, коригування розкладу scrub або виправлення маршрутизації оповіщень.
4. Задокументуйте «першу погану мітку часу» і «останню погану мітку часу». Це важливо для масштабу інциденту.

Чекліст D: Швидкий пошук вузького місця, коли resilver/scrub повільні

1. Перевірте, чи під час операції відбуваються помилки: zpool events -f 5–10 хвилин.
2. Перевірте логи ОС на повторні читання/тайм-аути в той самий проміжок.
3. Перевірте, чи один пристрій не обмежує vdev (висока затримка): якщо один диск хворий, його заміна швидша, ніж «чекати».
4. Тимчасово зменшіть конкуренцію навантаження. Відновлення — це тест на стрес; не запускайте бенчмарки під час нього.

FAQ

1) У чому різниця між zpool events і zpool status?

zpool status — це поточне знімок плюс короткий підсумок недавньої активності. zpool events — це хронологія: що сталося, коли і часто який шлях пристрою та клас помилки.
В інцидентах хронологія важить більше за відчуття.

2) Якщо я бачу checksum помилки, чи завжди я замінюю диск?

Ні. Якщо checksum помилки ізольовані на одному диску і повторюються — заміна зазвичай доречна. Якщо вони з’являються на кількох дисках — спочатку підозрюйте транспорт (HBA/backplane/кабелі) або прошивку.
Події разом із логами ядра вирішують, з чим ви маєте справу.

3) Чому ZFS повідомляє про помилки, коли додаток здається в порядку?

Тому що ZFS агресивно перевіряє цілісність даних і часто може виправляти пошкоджені читання з резервності, не повідомляючи додаток.
Оце й суть. Розглядайте виправлені помилки як сигнал попередження, а не як тріумф.

4) Чи серйозні події ereport.fs.zfs.*?

Це структуровані звіти про несправності. Деякі інформативні; багато вказують на реальні проблеми I/O. Важлива частота, чи повторюються вони на тому самому vdev і чи збігаються з scrub/resilver або змінами стану.

5) Чи можна очищати події або скинути історію подій?

Збереження подій залежить від платформи/інструментів. Не покладайтеся на можливість «очистити» їх як на лічильники дашборду.
Операційно зберігайте релевантний вивід у записі інциденту і зосереджуйтеся на припиненні виникнення нових подій.

6) Як зрозуміти, чи це проблема кабелю/backplane, а не диск?

Шукайте патерни: кілька дисків на тій самій HBA-лінії показують тайм-аути/ресети в один і той же час; пристрої зникають і повертаються; помилки під час навантажень (resilver/scrub) і зникають пізніше.
Логи на один диск із «Medium Error» більш ймовірно вказують на відмову медіа.

7) Чому продуктивність впала, коли диск вийшов з ладу, хоча пул залишився онлайн?

Деградування резервності змінює поведінку читання/запису і збільшує роботу (більше відновлення парності, більше повторних спроб, більше scrub/resilver).
Також відмовний диск може бути «online», але відповідати вічно, тягнучи вниз весь vdev.

8) Запускати scrubs щотижня чи щомісяця?

Це залежить від місткості, навантаження і терпимості до ризику. Великі пули виграють від частіших перевірок, бо латентні помилки накопичуються.
Непохитна частина — послідовність: виберіть інтервал, який ви зможете підтримувати, і оповіщайте про scrub finish з помилками.

9) Як використовувати події, щоб уникнути фальшивих спрацювань в оповіщенні?

Обмежуйте частоту і корелюйте. Оповіщайте при першому випадку, потім приглушуйте повтори на вікно, якщо стан пулу не змінився і помилки не зростають.
Не оповіщайте лише про зміни стану; так ви пропустите тижні флапу.

10) Чи допомагають події при скаргах «ZFS повільний»?

Так, опосередковано. Події можуть сказати, що система повторює I/O, має видалення пристроїв або виконує scrub/resilver — саме такі фонові навантаження роблять латентність жахливою.
Для чистого тюнінгу продуктивності вам все ще потрібні статистики I/O, але події часто виявляють «чому саме зараз».

Висновок: наступні кроки, що справді знижують ризик

zpool events — це не команда для краси. Це наратив, який ваш стек зберігання пише, поки ви дивитеся на дашборди, що усереднюють правду.
Читайте його, автоматизуйте його і використовуйте, щоб вирішити, чи маєте справу з помираючим диском чи з брехливим транспортом.

Зробіть це наступне, у такому порядку:

1. Переконайтеся, що ZED запущений і доставляє інформацію людям (тикети/пейджі), а не лише в syslog.
2. Додайте крок у runbook: коли zpool status показує проблему, захопіть zpool events -v і логи ядра навколо першої поганої мітки часу.
3. Оповіщайте про класи подій, що вказують на ризик (I/O, removals, scrub/resilver errors), з обмеженням частоти замість мовчання.
4. Плануйте scrubs і розглядайте «repaired errors» як сигнал до дії, а не як довідку.
5. Під час заміни диска спостерігайте події в реальному часі. Якщо помилки поширюються — припиніть міняти деталі і виправляйте транспорт.

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