Як моніторити стан диска на VPS без SMART

Що насправді може бачити моніторинг стану диска на VPS

Моніторинг стану диска на VPS починається з факту, якого уникає більшість інструкцій: диск вам не належить. Гостьова система бачить віртуальний блоковий пристрій. Фізичний накопичувач і всі лічильники, що зберігаються на ньому, належать хосту. smartctl /dev/vda не завершується помилкою через неправильне введення команди. Команда завершується помилкою, тому що за цим пристроєм немає нічого, що могло б відповісти на запит.

SMART (технологія самоконтролю, аналізу та звітності) — це таблиця лічильників, яку накопичувач зберігає безпосередньо на собі: переназначені сектори, сектори в очікуванні, час роботи після ввімкнення, помилки носія. Щоб прочитати цю таблицю, потрібен шлях для передавання команд ATA або NVMe (non-volatile memory express) до фізичного обладнання. Паравіртуальний диск такого шляху не надає, тому гостьова система отримує сховище без телеметрії.

Орендар може моніторити наслідки, а не обладнання. Усередині гостьової системи видно чотири сигнали: помилки I/O (введення-виведення) у журналі ядра, файлову систему, повторно змонтовану в режимі лише читання, зростання затримки та вичерпання вільного місця. На всі чотири сигнали можна налаштувати сповіщення вже сьогодні, і всі чотири з’являються до того, як користувач поскаржиться. Спочатку налаштуйте саме їх. Розподіл відповідальності розглянемо наприкінці, оскільки він визначає, куди варто спрямувати зусилля.

Що насправді доступно на вашому сервері

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

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk — типовий диск KVM (kernel-based virtual machine). Пристрій має назву /dev/vda, і smartctl завершує роботу ще до надсилання будь-якого запиту:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk — це паравіртуалізований транспорт без набору команд ATA або SCSI, тому через нього неможливо передати запит SMART. -d sat і -d scsi завершуються так само, оскільки проблема в транспорті, а не у прапорці.

Емульований диск SATA або SCSI. Пристрій має назву /dev/sda, і smartctl встигає його ідентифікувати. Рядок моделі має значення QEMU HARDDISK. Цього рядка достатньо, щоб зробити висновок: ви працюєте з пристроєм, який створив емулятор, і він не повідомляє про придатну для використання підтримку SMART.

Простір імен NVMe. sudo nvme smart-log /dev/nvme0n1 повертає повний журнал, через що легко зробити неправильний висновок. Спочатку перевірте ідентифікацію контролера за допомогою sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Якщо номер моделі вказує на мережевий пристрій зберігання даних, контролер є програмним, тому percentage_used і media_errors описують цю емуляцію, а не flash-пам’ять, у якій зберігаються ваші дані. Щоб з’ясувати, яке сховище використовується насправді, перевірте диск NVMe у Linux, а не покладайтеся на опис тарифного плану.

Контейнер, наприклад LXC (Linux containers) або OpenVZ. У вас немає власного блочного пристрою. lsblk показує пристрої хоста або не показує нічого, а smartctl відмовляється виконувати операцію, оскільки контейнер не має CAP_SYS_RAWIO:

Smartctl open device: /dev/sda failed: Permission denied

Окреме застереження щодо випадку, коли команда все ж працює. Якщо smartctl на VPS повертає повну таблицю атрибутів, перш ніж діяти, перевірте серійний номер. Деякі хости надають вузол пристрою через passthrough, і ці лічильники стосуються обладнання, спільного для всіх клієнтів на цій машині. Зростання значення Reallocated_Sector_Ct у такому разі є підставою звернутися до служби підтримки. Це не свідчить про стан ваших даних.

Сигнал 1: помилки введення-виведення в журналі ядра

Це найцінніший сигнал, який може отримати орендар, і для нього не потрібен агент.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

Невдалий запит від віртуального диска має такий вигляд:

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

Блоковий рівень запросив у хоста операцію запису, а хост повернув помилку. На VPS це рідко означає вихід із ладу комірки flash-пам’яті. Зазвичай проблема виникає на рівні сховища хоста або в мережевому шляху до мережевого сховища, тобто це подія на стороні провайдера. Додайте до заявки мітку часу, назву пристрою та сектор. За цими даними команда сховища зможе знайти відповідний запис у власних журналах.

Найважливіша послідовність повідомлень ext4 — це така пара:

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

Проблемною є друга стрічка, оскільки машина продовжує працювати. Вона відповідає на ping, приймає SSH-з’єднання, але кожна операція запису завершується помилкою. Звичайна перевірка HTTP продовжує проходити, хоча застосунок повертає помилку на кожен запит.

XFS натомість вимикає файлову систему:

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k читає лише поточне завантаження, якщо журнал не зберігається на диску, а багато образів постачаються з volatile-журналом, який зберігається в RAM. Увімкніть постійне зберігання журналу, інакше докази зникнуть саме після перезавантаження, яке ви виконаєте під час діагностики.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

Після наступного перезавантаження journalctl --list-boots має показати більше одного завантаження. Навіть за ввімкненого постійного зберігання файлова система, яка перейшла в режим лише читання, не зможе записати подальші події. Тому журнали слід передавати на зовнішню систему.

Сигнал 2: виявлення перемонтування в режимі лише для читання

Зробіть збій явним, перш ніж намагатися його виявити.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Перевірте наявність errors=remount-ro серед параметрів. Хмарні образи Ubuntu і Debian задають його в /etc/fstab, тому помилка метаданих переводить файлову систему в режим лише для читання, а не дозволяє продовжувати роботу з пошкодженнями. Якщо параметра немає, додайте його до запису root у /etc/fstab або задайте його в суперблоці за допомогою sudo tune2fs -e remount-ro /dev/vda1. Явна зупинка краща за непомітне пошкодження даних.

Прапорець монтування не є доказом. Перевірте це записом:

touch /var/tmp/.disk-probe

У кореневій файловій системі, змонтованій лише для читання, команда виведе саме:

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

Використовуйте /var/tmp, а не /tmp. У більшості образів /tmp — це tmpfs, що зберігається в пам’яті, тому успішний запис туди нічого не доводить щодо вашого диска.

Об’єднайте перевірку запису з перевіркою вільного місця та надсилайте heartbeat лише тоді, коли всі перевірки пройдено:

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

probe-ok в останньому рядку означає, що весь ланцюжок працює. set -eu завершує роботу з ненульовим кодом, якщо будь-яка перевірка не пройдена, ще до виконання рядка curl, тому heartbeat не надсилається. У цьому і полягає принцип: монітор переходить у червоний стан, бо нічого не надійшло, а сервер, який не може виконати запис, не може достовірно повідомити про власну проблему. Читання на файловій системі лише для читання все ще працює, тому сам скрипт запускається.

Запускайте його за таймером systemd.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers має показати unit із часом NEXT, до якого залишається менше п’яти хвилин. Невдалий запуск з’явиться в journalctl -u disk-probe.service із власним текстом помилки shell, тому ви зможете відрізнити файлову систему лише для читання від заповненої файлової системи без входу на сервер.

Ця push URL належить push-монітору Uptime Kuma. Створіть монітор типу Push, скопіюйте його token у скрипт і задайте для heartbeat монітора інтервал трохи довший за інтервал таймера, щоб один повільний запуск не надсилав сповіщення о 03:00. Якщо у вас ще немає status page, self-hosted інстанс Uptime Kuma — найдешевше місце для розміщення цієї перевірки.

Є два важливі обмеження. Перевірка підтверджує, що запис прийнято, але не те, що байти потрапили на надійне сховище, оскільки повторне читання може обслуговуватися з page cache. Крім того, вона виконується на машині, яку контролює, тому повністю завислий сервер замовкає, а не повідомляє діагноз.

Тренди latency і throughput

sudo apt install -y sysstat
iostat -xdz 5 3

Спочатку перегляньте r_await і w_await. Це середній час у мілісекундах, потрібний для виконання операції читання або запису, з урахуванням часу очікування в черзі. Потім перегляньте aqu-sz — середню кількість запитів у роботі. На віртуальному диску не зважайте на %util: це лише означає, що черга не була порожньою. Пристрій, який обробляє багато запитів паралельно, може бути завантажений майже на 100 відсотків і водночас бути далеким від межі продуктивності. await — це показник, який відображає те, що відчувають користувачі.

Абсолютні значення менш важливі за ваш власний базовий рівень. Тому зафіксуйте показники протягом спокійної години та збережіть їх. /proc/diskstats — це джерело необроблених даних, якщо ви хочете збирати лічильники самостійно.

Для цілеспрямованого вимірювання:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

Перегляньте блок clat percentiles, зокрема значення 99-го перцентиля. --direct=1 оминає кеш сторінок. Але кеш хоста він не оминає, тому результат описує весь шлях від вашого процесу до сховища платформи. Запускайте вимірювання, коли сервер не завантажений, оскільки воно конкурує з вашим робочим навантаженням.

Зростання await за відсутності помилок у журналі ядра зазвичай не означає несправність диска. Це конкуренція за ресурси на хості, тобто варіант проблеми зі сховищем, аналогічний CPU steal time від надмірно активного сусіда. Якщо це повторюється щодня в один і той самий час, а перевірка диска не виявляє проблем, рішенням зазвичай є тарифний план зі сховищем, I/O якого не розподіляється таким самим способом. Саме так працює storage VPS порівняно зі звичайним VPS, коли робоче навантаження залежить від диска.

Сигнал 4: перевірки файлової системи, які можна виконувати під час монтування

ext4 зберігає лічильник помилок у суперблоці. Цей лічильник переживає перезавантаження, навіть якщо журнали вже недоступні.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

Здорова файлова система виводить Filesystem state: clean і FS Error count: 0. clean with errors і ненульове значення лічильника означають, що ядро раніше виявило помилку метаданих, навіть якщо ніхто цього не помітив, а відповідний запис у журналі вже видалено під час ротації. Цю команду слід включити до щотижневої перевірки.

Не можна запускати fsck для змонтованої кореневої файлової системи. e2fsck -n на файловій системі, яка використовується, повідомляє про проблеми, спричинені змінами даних під час перевірки. Щоб виконати повну перевірку, додайте fsck.mode=force fsck.repair=yes до командного рядка ядра для одного завантаження через консоль провайдера. Після цього systemd-fsck виконає перевірку до перемонтування кореневої файлової системи в режимі read-write.

XFS не підтримує онлайн-перевірку. xfs_repair -n /dev/vda1 відмовляється працювати зі змонтованою файловою системою, тому його слід запускати в rescue mode. Натомість XFS чітко реагує на помилки: у разі помилки метаданих файлова система переходить у неробочий стан, а не продовжує роботу.

У Btrfs лічильники вбудовані та зберігаються постійно.

sudo btrfs device stats /
sudo btrfs scrub start -B /

Значення write_io_errs або corruption_errs більше за нуль означає реальну подію. Лічильники зберігають свої значення після перезавантажень, доки їх не буде скинуто. scrub повторно читає кожен блок і перевіряє його контрольну суму. Це найближчий аналог перевірки носія, доступний на віртуальному диску. Команда створює значне навантаження на введення-виведення, тому заплануйте її на період низької активності.

Сигнал 5: вільне місце, зокрема те, яке приховує df

Нестача місця виводить сервер з ладу так само, як несправний диск. Вона трапляється значно частіше.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device, тоді як df -h показує вільне місце, означає, що вичерпано inode, а не байти. df -i показує IUse% на рівні 100 відсотків. Це спричиняє мільйони малих файлів у каталозі кешу або поштовій черзі. Видалення великих файлів не допоможе.

Місце, яке не звільняється після видалення файлу, зазвичай зайняте видаленим файлом, який досі відкритий запущеним процесом. sudo lsof +L1 виводить файли, кількість жорстких посилань для яких дорівнює нулю. Перезапуск процесу, який утримує такий файл, звільняє місце.

Журнал часто непомітно споживає значний обсяг місця. journalctl --disk-usage показує, який обсяг він займає. Обмежте його за допомогою SystemMaxUse=200M у /etc/systemd/journald.conf, а потім виконайте sudo systemctl restart systemd-journald. Щоб звільнити місце негайно, використайте sudo journalctl --vacuum-size=200M.

Одна ситуація схожа на помилку, але нею не є. У сховищі хоста з thin provisioning пул хоста може заповнитися, тоді як df у вашій системі все ще показує вільні гігабайти. Після цього операції запису завершуються помилками I/O у журналі ядра, а всередині гостьової системи немає повідомлення про нестачу місця. Помилки без заповненої файлової системи — це поєднання, щодо якого потрібно створити ticket того самого дня.

Підключення сигналів до агента метрик

Push probe повертає відповідь «так» або «ні». Для аналізу тенденцій потрібен агент метрик, а Prometheus node_exporter уже експортує всі наведені вище показники без додаткової конфігурації. Основні назви метрик:

• node_filesystem_readonly набуває значення 1, коли монтування доступне лише для читання. Це сигнал тривоги про повторне монтування.
• node_filesystem_avail_bytes і node_filesystem_files_free окремо показують кількість байтів та inode.
• node_disk_io_time_seconds_total і node_disk_read_time_seconds_total показують зайнятий час і затримку як лічильники, які можна візуалізувати на графіку.

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

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

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

Відповідальність сторін

Ваш провайдер відповідає за фізичні диски. Він читає SMART, керує масивом і зазвичай без повідомлення замінює диск зі зростаючою кількістю перепризначених секторів, оскільки масив поглинає відмову. Саме для цього потрібен RAID 10 у вашому VPS: відмова диска призводить до відновлення масиву, а не до простою. Ви не бачите жодного з цих процесів. Оплата цієї абстракції є однією з головних причин оренди віртуального сервера.

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

Тому реальний захист орендаря — це резервна копія, яка зберігається поза сервером, і відновлення, яке ви самостійно перевірили. Знімки провайдера зручні, але вони зберігаються на тій самій платформі, що й захищуваний об’єкт. Саме тому знімки та резервні копії забезпечують різний захист. Заплануйте перевірку в календарі: раз на квартал відновлюйте найновішу резервну копію в новому VPS, запускайте застосунок і записуйте, скільки часу це зайняло. Це число є вашим фактичним часом відновлення. Перша перевірка завжди триває довше, ніж очікують.

Коли SMART справді застосовується

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

• Виділений або bare metal-сервер, де sudo smartctl -a /dev/sda повертає повну таблицю атрибутів, а smartd може надіслати вам електронного листа, коли атрибут зміниться.
• Тарифні плани сховища, у яких фізичний диск безпосередньо передається гостьовій системі. Провайдери прямо зазначають це в документації, оскільки це є перевагою послуги.
• Обладнання, яким ви володієте, удома або в орендованому rack space.
• Диск за RAID-контролером, доступний через sudo smartctl -a -d megaraid,0 /dev/sda, або USB-корпус із підтримкою -d sat.

На фізичному NVMe sudo smartctl -a -d nvme /dev/nvme0 і sudo nvme smart-log /dev/nvme0n1 отримують із самого накопичувача critical_warning і percentage_used. На фізичному SATA атрибути, які прогнозують відмову, — це Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) і Reported_Uncorrect (187). Якщо будь-який із них змінюється з нульового значення, плануйте заміну диска. Масштабні дослідження накопичувачів постійно підтверджують цей короткий список. Більшість інших атрибутів не містить корисної інформації.

Запускайте daemon, а не перевіряйте диски вручну.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

У журналі самотестування для щойно запущеної перевірки має бути показано Completed without error. Ubuntu і Debian постачають /etc/smartd.conf із рядком DEVICESCAN, актуальним станом на August 2026, тому daemon охоплює кожен доступний йому диск і надсилає root електронного листа про зміни. На віртуальному диску це не працює. Саме тому існує решта цього посібника.

FAQ

Чому smartctl не працює на моєму VPS?

Тому що диск віртуальний. У KVM-гостя з virtio-blk команда smartctl -a /dev/vda виводить /dev/vda: Unable to detect device type, оскільки паравіртуальний диск не має каналу команд ATA або SCSI, через який можна передати SMART-запит. На емуляції диска ви звертаєтеся до пристрою, модель якого має значення QEMU HARDDISK, а доступних даних SMART за ним немає. У контейнері smartctl повністю відхиляється через відсутність CAP_SYS_RAWIO. Жоден із цих випадків не є помилкою конфігурації, і жоден прапорець -d їх не виправить.

Як дізнатися, що диск VPS виходить із ладу?

Відстежуйте наслідки, а не апаратне забезпечення. Перевірте sudo journalctl -k -p err -b на наявність рядків blk_update_request: I/O error і Remounting filesystem read-only. Виконайте sudo dumpe2fs -h /dev/vda1 | grep -i 'error count', щоб знайти помилки, які вже зникли з журналів. Відстежуйте r_await з iostat -xdz 5 і порівнюйте його з базовим значенням, зафіксованим під час нормальної роботи. На VPS помилка введення-виведення зазвичай означає проблему зі сховищем хоста, а не несправність диска, тому додайте її до звернення в службу підтримки разом із часовою міткою та сектором.

На які події слід налаштувати сповіщення для контролю диска VPS?

Достатньо чотирьох сповіщень. Монтування лише для читання, виявлене через node_filesystem_readonly == 1, або невдала проба запису. Вільний простір і кількість вільних inode, що наближаються до нуля. Будь-який запис ядра I/O error за останній інтервал. Сигнал доступності від сервера, щоб відсутність відповіді створювала сповіщення, коли сервер перестає відповідати. Не використовуйте дані, отримані зі SMART, оскільки на віртуальному диску вони або відсутні, або описують емуляцію гіпервізора.

Чому моя файлова система була перемонтована лише для читання?

ext4, змонтована з errors=remount-ro, навмисно робить це після помилки метаданих: файлова система припиняє запис, щоб не продовжувати роботу з пошкодженими даними. Причина зазначена в журналі ядра безпосередньо перед рядком про перемонтування. Зазвичай це EXT4-fs error про перерваний журнал після того, як базовий пристрій повернув помилку введення-виведення. Перемонтування в режимі читання-запису без перевірки файлової системи приховує симптом, але залишає причину. Збережіть журнал, а потім перевірте файлову систему в режимі rescue, коли вона відмонтована, за допомогою e2fsck -fy /dev/vda1.

Чи можна коли-небудь прочитати дані SMART на віртуальному сервері?

У певних випадках — так. Виділені сервери та bare metal надають реальні атрибути. Те саме стосується тарифів зі сховищем, які передають фізичний диск безпосередньо гостю, а також будь-якого хоста, яким ви керуєте самостійно. Деякі платформи надають гостю контролер NVMe, і nvme smart-log повертає журнал. Тому спочатку виконайте sudo nvme id-ctrl /dev/nvme0: номер моделі, у якому згадується мережевий сервіс зберігання, означає, що ці лічильники надходять від програмного контролера. Якщо passthrough-вузол на спільному сервері справді надає реальні лічильники, вони описують апаратне забезпечення, спільне з іншими орендарями. У такому разі єдиною корисною дією буде звернення до служби підтримки.