Monitorowanie kondycji dysku na VPS: co można sprawdzić?

Co faktycznie można monitorować w zakresie kondycji dysku na VPS

Monitorowanie kondycji dysku na VPS zaczyna się od faktu, który większość poradników pomija: dysk nie należy do użytkownika. System gościa widzi wirtualne urządzenie blokowe. Fizyczny nośnik oraz wszystkie liczniki na nim zapisane należą do hosta. smartctl /dev/vda nie kończy się niepowodzeniem z powodu błędnego wpisania polecenia. Kończy się niepowodzeniem, ponieważ żaden element za tym urządzeniem nie może odpowiedzieć na zapytanie.

SMART (self-monitoring, analysis and reporting technology) to tabela liczników przechowywana na samym dysku: realokowane sektory, sektory oczekujące, czas pracy, błędy nośnika. Odczyt tej tabeli wymaga ścieżki, przez którą polecenia ATA lub NVMe (non-volatile memory express) dotrą do rzeczywistego sprzętu. Dysk parawirtualny jej nie udostępnia, więc gość otrzymuje pamięć masową z usuniętą telemetrią.

Najemca monitoruje skutki, a nie sprzęt. Z wnętrza gościa widoczne są cztery sygnały: błędy I/O (input/output) w dzienniku jądra, system plików montowany w trybie tylko do odczytu, dryfująca w górę latencja oraz brak wolnego miejsca. Wszystkie cztery można monitorować, a każdy z nich pojawia się, zanim użytkownik zgłosi problem. Należy je skonfigurować w pierwszej kolejności. Podział odpowiedzialności następuje na końcu, ponieważ zmienia on obszar, w który należy inwestować wysiłek.

Weryfikacja ekspozycji własnego serwera

Nie należy zakładać z góry, z jakim przypadkiem mamy do czynienia. Należy sprawdzić stan, a następnie zapoznać się z odpowiednią sekcją.

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

virtio-blk, standardowy dysk KVM (kernel-based virtual machine). Urządzenie to /dev/vda, a polecenie smartctl kończy działanie przed wysłaniem jakichkolwiek danych:

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

virtio-blk to transport parawirtualny, który nie obsługuje zestawu komend ATA ani SCSI, dlatego nie istnieje kanał do przesyłania żądań SMART. -d sat oraz -d scsi kończą się niepowodzeniem z tego samego powodu; problemem jest transport, a nie użyta flaga.

Emulowany dysk SATA lub SCSI. Urządzenie to /dev/sda, a smartctl uzyskuje wystarczająco dużo informacji, aby je zidentyfikować. Linia modelu zawiera QEMU HARDDISK. Ten ciąg znaków sam w sobie stanowi odpowiedź: odczytywane jest urządzenie wygenerowane przez emulator, które nie zgłasza żadnych użytecznych funkcji SMART.

Przestrzeń nazw NVMe. sudo nvme smart-log /dev/nvme0n1 zwraca pełny dziennik, co często wprowadza użytkowników w błąd. Należy najpierw sprawdzić identyfikator kontrolera za pomocą sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Numer modelu wskazujący na produkt pamięci masowej sieciowej oznacza, że kontroler jest rozwiązaniem programowym, więc percentage_used oraz media_errors opisują tę emulację, a nie fizyczną pamięć flash, na której zapisane są dane. Aby poznać rzeczywisty typ nośnika, należy zweryfikować dysk NVMe w systemie Linux zamiast polegać na opisie planu.

Kontener, taki jak LXC (Linux containers) lub OpenVZ. Użytkownik nie posiada własnego urządzenia blokowego. lsblk pokazuje urządzenia hosta lub nie zwraca żadnych informacji, a działanie smartctl jest odrzucane, ponieważ kontener nie posiada uprawnień do CAP_SYS_RAWIO:

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

Ostrzeżenie dotyczące sytuacji, w której narzędzie działa poprawnie. Jeśli smartctl na serwerze VPS zwraca pełną tabelę atrybutów, przed podjęciem jakichkolwiek działań należy sprawdzić numer seryjny. Niektórzy dostawcy udostępniają węzeł urządzenia przez passthrough, a liczniki te dotyczą sprzętu współdzielonego przez wszystkich użytkowników na danej maszynie. Wzrost wartości Reallocated_Sector_Ct w takim przypadku jest podstawą do zgłoszenia ticketu do wsparcia technicznego. Nie jest to informacja dotycząca stanu danych użytkownika.

Sygnał 1: błędy I/O w dzienniku jądra

Jest to najważniejszy sygnał dostępny dla najemcy, który nie wymaga instalacji żadnego agenta.

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'

Nieudane żądanie z dysku wirtualnego wygląda następująco:

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

Warstwa blokowa wysłała do hosta żądanie zapisu, a host zwrócił błąd. Na serwerze VPS rzadko oznacza to uszkodzenie komórki pamięci flash. Zazwyczaj jest to problem warstwy pamięci masowej hosta lub ścieżki sieciowej do pamięci masowej typu network attached storage, co stanowi zdarzenie po stronie dostawcy. Należy skopiować znacznik czasu, nazwę urządzenia oraz sektor do zgłoszenia serwisowego, ponieważ są to dane, które zespół ds. pamięci masowej może porównać z własnymi dziennikami.

Sekwencja ext4, która ma największe znaczenie, to poniższa para:

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

Druga linia jest najbardziej krytyczna, ponieważ maszyna pozostaje uruchomiona. Odpowiada na ping, odpowiada na SSH, a każdy zapis kończy się niepowodzeniem. Zwykła kontrola HTTP przechodzi pomyślnie, podczas gdy aplikacja zgłasza błąd przy każdym żądaniu.

XFS zamiast tego wyłącza system plików:

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 odczytuje tylko bieżące uruchomienie, chyba że dziennik jest przechowywany na dysku, a wiele obrazów dostarczanych jest z ulotnym dziennikiem znajdującym się w pamięci RAM. Należy włączyć trwałość, w przeciwnym razie dowody znikną dokładnie w momencie restartu, który zostanie wykonany podczas rozwiązywania problemów.

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

Po kolejnym restarcie journalctl --list-boots powinno wyświetlić więcej niż jedno uruchomienie. Nawet przy włączonej trwałości, system plików, który przeszedł w tryb tylko do odczytu, nie jest w stanie zapisać tego, co wydarzyło się później, co stanowi kluczowy argument za przesyłaniem dzienników poza serwer.

Sygnał 2: wykrywanie ponownego montowania w trybie tylko do odczytu

Zgłoś awarię w sposób wyraźny, zanim spróbujesz ją wykryć.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Wyszukaj errors=remount-ro w opcjach montowania. Obrazy chmurowe Ubuntu i Debian ustawiają tę opcję w /etc/fstab, dzięki czemu błąd metadanych przełącza system plików w tryb tylko do odczytu, zamiast kontynuować pracę mimo uszkodzeń. Jeśli opcja jest nieobecna, dodaj ją do wpisu root w /etc/fstab lub ustaw ją w superbloku za pomocą sudo tune2fs -e remount-ro /dev/vda1. Głośne zatrzymanie systemu jest lepsze niż cicha korupcja danych.

Flaga montowania nie jest dowodem. Sprawdź stan poprzez zapis:

touch /var/tmp/.disk-probe

W systemie plików root zamontowanym tylko do odczytu polecenie to zwróci dokładnie:

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

Użyj /var/tmp, a nie /tmp. W większości obrazów /tmp to tmpfs utrzymywany w pamięci RAM, więc udany zapis w tym miejscu nie dowodzi sprawności dysku.

Połącz test zapisu ze sprawdzeniem wolnego miejsca i wysyłaj sygnał heartbeat tylko wtedy, gdy wszystkie testy zakończą się powodzeniem:

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 w ostatniej linii oznacza, że cały łańcuch działa poprawnie. set -eu sprawia, że każdy nieudany test kończy działanie skryptu z kodem błędu przed wykonaniem linii curl, więc sygnał heartbeat nie zostaje wysłany. Ta inwersja jest kluczowa: monitor zmienia stan na alarmowy, ponieważ sygnał nie dotarł, a serwer, który nie może pisać, nie jest wiarygodnym źródłem informacji o własnych problemach. Operacje odczytu nadal działają na systemie plików w trybie tylko do odczytu, więc sam skrypt uruchamia się poprawnie.

Uruchamiaj go za pomocą timera 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 powinno pokazać jednostkę z czasem NEXT krótszym niż pięć minut. Nieudane uruchomienie pojawi się w journalctl -u disk-probe.service wraz z treścią błędu powłoki, dzięki czemu można odróżnić system plików w trybie tylko do odczytu od systemu zapełnionego bez konieczności logowania się.

Podany adres URL to monitor typu Push w Uptime Kuma. Utwórz monitor typu Push, skopiuj jego token do skryptu i ustaw interwał monitora nieco dłuższy niż interwał timera, aby pojedyncze wolne uruchomienie nie wywoływało alertu o 03:00. Jeśli nie masz jeszcze strony statusu, samodzielnie hostowana instancja Uptime Kuma jest najtańszym miejscem na umieszczenie tego sprawdzenia.

Dwa uczciwe ograniczenia. Sonda potwierdza, że zapis został zaakceptowany, a nie że bajty dotarły do trwałego nośnika, ponieważ odczyt może zostać obsłużony z pamięci podręcznej strony (page cache). Ponadto skrypt działa na maszynie, którą monitoruje, więc całkowicie zawieszony serwer zamilknie, zamiast zgłosić diagnozę.

Sygnał 3: trendy opóźnień i przepustowości

sudo apt install -y sysstat
iostat -xdz 5 3

Najpierw należy zapoznać się z r_await oraz w_await. Są to średnie wartości w milisekundach, jakie zajęła operacja odczytu lub zapisu, wliczając czas oczekiwania w kolejce. Następnie należy sprawdzić aqu-sz, czyli średnią liczbę żądań w trakcie przetwarzania. W przypadku dysku wirtualnego należy zignorować %util: oznacza ono jedynie, że kolejka nie była pusta, a urządzenie obsługujące wiele żądań równolegle osiąga blisko 100 procent wykorzystania, nawet jeśli nie zbliża się do swojego limitu. await to wskaźnik odzwierciedlający odczucia użytkowników.

Wartości bezwzględne mają mniejsze znaczenie niż własna baza odniesienia, dlatego należy zarejestrować parametry w czasie niskiego obciążenia i zachować te dane. /proc/diskstats stanowi surowe źródło informacji, jeśli zbieranie liczników ma odbywać się samodzielnie.

W celu przeprowadzenia celowego pomiaru:

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

Należy odczytać blok clat percentiles, w szczególności 99. percentyl. --direct=1 pomija pamięć podręczną stron (page cache). Nie pomija jednak pamięci podręcznej hosta, więc wynik opisuje pełną ścieżkę od procesu aż do pamięci masowej platformy. Test należy uruchomić, gdy serwer jest w stanie spoczynku, ponieważ konkuruje on z własnym obciążeniem.

Wzrost await przy braku błędów w dzienniku jądra zazwyczaj nie oznacza awarii dysku. Jest to rywalizacja o zasoby na hoście, czyli odpowiednik czasu kradzieży procesora (CPU steal time) od głośnego sąsiada w kontekście pamięci masowej. Jeśli problem powraca o tej samej porze każdego dnia, a zgłoszenie techniczne nie wykazuje błędów, rozwiązaniem jest plan, w którym operacje I/O nie są współdzielone w ten sam sposób, co ma miejsce w przypadku serwera VPS z dedykowaną pamięcią masową w porównaniu do zwykłego VPS, gdy obciążenie jest ograniczone wydajnością dysku.

Sygnał 4: sprawdzanie systemu plików w trybie zamontowanym

System ext4 przechowuje licznik błędów w superbloku, który jest zachowywany po restarcie, nawet jeśli dzienniki systemowe zostały wyczyszczone.

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

Poprawnie działający system plików zwraca Filesystem state: clean oraz FS Error count: 0. Wartości clean with errors oraz licznik różny od zera oznaczają, że jądro napotkało błąd metadanych, nawet jeśli nikt go nie zauważył, a wpis w dzienniku został nadpisany. To polecenie powinno być elementem cotygodniowych przeglądów.

Nie można uruchomić fsck na zamontowanym głównym systemie plików (root), a e2fsck -n na działającym systemie zgłasza problemy wynikające jedynie z ciągłych zmian danych. Aby wymusić rzeczywistą weryfikację, należy dodać fsck.mode=force fsck.repair=yes do linii poleceń jądra (kernel command line) przy jednym uruchomieniu z poziomu konsoli dostawcy. Wówczas systemd-fsck przeprowadzi sprawdzanie, zanim system plików zostanie zamontowany w trybie odczytu i zapisu.

XFS nie posiada funkcji sprawdzania w trybie online. Polecenie xfs_repair -n /dev/vda1 odmawia pracy na zamontowanym systemie plików, dlatego należy je uruchamiać w trybie ratunkowym (rescue mode). XFS rekompensuje to wysoką reaktywnością: w przypadku błędu metadanych system plików jest wyłączany, zamiast kontynuować pracę w stanie potencjalnie uszkodzonym.

W systemie Btrfs liczniki są wbudowane i trwałe.

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

Wartości write_io_errs lub corruption_errs większe od zera oznaczają wystąpienie rzeczywistego zdarzenia, a liczniki zachowują swoje wartości po restarcie, dopóki nie zostaną wyzerowane. Polecenie scrub ponownie odczytuje każdy blok i weryfikuje jego sumę kontrolną, co jest odpowiednikiem testu nośnika dostępnym dla dysków wirtualnych. Operacja ta generuje duże obciążenie wejścia/wyjścia (I/O), dlatego należy ją zaplanować na godziny o niskim natężeniu ruchu.

Sygnał 5: wolne miejsce, w tym obszary ukryte przez df

Brak wolnego miejsca powoduje awarię serwera w taki sam sposób jak uszkodzenie dysku, a zdarza się to znacznie częściej.

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

No space left on device, podczas gdy df -h pokazuje wolne miejsce, oznacza wyczerpanie liczby i-węzłów (inodes), a nie bajtów, natomiast df -i wskazuje IUse% na poziomie 100 procent. Przyczyną są miliony małych plików w katalogu pamięci podręcznej lub kolejce pocztowej, a usuwanie dużych plików nie rozwiązuje problemu.

Miejsce, które nie wraca po usunięciu plików, jest zazwyczaj zajmowane przez usunięty plik, który nadal jest otwarty przez działający proces. sudo lsof +L1 wyświetla listę plików, których licznik dowiązań osiągnął zero. Zrestartowanie procesu, który przetrzymuje taki plik, zwolni miejsce.

Dziennik systemd jest częstym, cichym konsumentem przestrzeni. journalctl --disk-usage raportuje zajmowane przez niego miejsce. Należy ograniczyć jego rozmiar za pomocą SystemMaxUse=200M w pliku /etc/systemd/journald.conf, a następnie wykonać sudo systemctl restart systemd-journald i odzyskać miejsce poleceniem sudo journalctl --vacuum-size=200M.

Jeden przypadek wygląda na błąd, choć nim nie jest. W przypadku pamięci masowej typu thin provisioned, pula hosta może się zapełnić, podczas gdy system gościa df nadal pokazuje wolne gigabajty. Operacje zapisu kończą się wtedy błędami wejścia/wyjścia (I/O) w dzienniku jądra, bez żadnego ostrzeżenia o braku miejsca wewnątrz systemu gościa. Błędy przy niepełnym systemie plików to sytuacja wymagająca natychmiastowego zgłoszenia.

Podłączanie sygnałów do agenta metryk

Sonda typu push odpowiada twierdząco lub przecząco. Trendy wymagają agenta metryk, a Prometheus node_exporter eksportuje już wszystkie powyższe dane bez dodatkowej konfiguracji. Nazwy metryk, na których można się oprzeć:

• node_filesystem_readonly przyjmuje wartość 1, gdy punkt montowania jest w trybie tylko do odczytu, co stanowi sygnał do ponownego montowania.
• node_filesystem_avail_bytes oraz node_filesystem_files_free obejmują odpowiednio bajty i inody.
• node_disk_io_time_seconds_total oraz node_disk_read_time_seconds_total dostarczają czas zajętości i opóźnienia jako liczniki, które można przedstawić na wykresie.

Dwie reguły wyłapują przypadki, które faktycznie generują powiadomienia:

- 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

Druga reguła aktywuje się, gdy bieżący trend osiągnie zero w ciągu czterech dni. Dzięki temu ostrzeżenie pojawia się z wyprzedzeniem, zamiast przy 95 procentach zapełnienia, kiedy na reakcję pozostają tylko minuty.

Podział odpowiedzialności

Dostawca odpowiada za fizyczne nośniki danych. Monitoruje on parametry SMART, zarządza macierzą i wymienia dyski wykazujące rosnącą liczbę realokowanych sektorów, zazwyczaj bez powiadamiania użytkownika, ponieważ macierz kompensuje awarię. Do tego służy RAID 10 w ramach VPS: uszkodzony dysk powoduje proces odbudowy zamiast przerwy w działaniu usługi. Użytkownik nie ma wglądu w te procesy, a opłacanie tej abstrakcji stanowi główny cel wynajmu serwera wirtualnego.

Użytkownik odpowiada za własne dane, a telemetria dysków i tak nie zapewniłaby ich ochrony. Zdarzenia, które faktycznie prowadzą do utraty danych najemcy, to omyłkowe wykonanie rm, błędne wdrożenie, intruz dysponujący kluczem SSH oraz awaria platformy, która niszczy całą macierz. Atrybuty SMART nie przewidują żadnego z tych scenariuszy.

Zatem realną ochroną dla najemcy jest kopia zapasowa przechowywana poza serwerem oraz procedura przywracania danych, którą użytkownik samodzielnie przetestował. Migawki (snapshots) oferowane przez dostawcę są wygodne, lecz znajdują się na tej samej platformie co chronione zasoby, dlatego migawki i kopie zapasowe stanowią odmienne zabezpieczenia. Należy zaplanować regularne ćwiczenia: raz na kwartał należy przywrócić najnowszą kopię zapasową na świeży serwer VPS, uruchomić aplikację i odnotować czas trwania tego procesu. Ta wartość stanowi rzeczywisty czas odzyskiwania danych. Pierwsza próba zawsze trwa dłużej, niż zakładano.

Kiedy SMART ma zastosowanie

Poradniki dotyczące smartctl są poprawne i mają zastosowanie w momencie, gdy sprzęt faktycznie należy do użytkownika:

• Dedykowany serwer lub serwer typu bare metal, gdzie sudo smartctl -a /dev/sda zwraca pełną tabelę atrybutów, a smartd może wysłać powiadomienie e-mail w przypadku zmiany atrybutu.
• Plany pamięci masowej, które przekazują fizyczny dysk bezpośrednio do systemu gościa. Dostawcy dokumentują to wyraźnie, ponieważ jest to atut sprzedażowy.
• Sprzęt stanowiący własność użytkownika, znajdujący się w domu lub w wynajętej przestrzeni szafy rack.
• Dysk za kontrolerem RAID, dostępny za pomocą sudo smartctl -a -d megaraid,0 /dev/sda, lub obudowa USB obsługująca -d sat.

W przypadku rzeczywistych dysków NVMe, sudo smartctl -a -d nvme /dev/nvme0 oraz sudo nvme smart-log /dev/nvme0n1 raportują critical_warning i percentage_used bezpośrednio z napędu. W przypadku rzeczywistych dysków SATA, atrybuty prognozujące awarię to Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) oraz Reported_Uncorrect (187). Zmiana wartości któregokolwiek z nich z zera oznacza konieczność zaplanowania wymiany. Szeroko zakrojone badania nad dyskami wskazują stale na tę samą krótką listę, a większość pozostałych atrybutów to szum informacyjny.

Należy uruchomić demona zamiast sprawdzać stan ręcznie.

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

Dziennik autotestów powinien wykazywać Completed without error dla właśnie uruchomionego testu. Systemy Ubuntu i Debian dostarczają /etc/smartd.conf z linią DEVICESCAN, aktualną na sierpień 2026, dzięki czemu demon wykrywa każdy widoczny dysk i wysyła powiadomienie do root w przypadku zmiany. Nic z tego nie działa w przypadku dysku wirtualnego, dlatego istnieje reszta tego poradnika.

FAQ

Dlaczego smartctl nie działa na moim VPS?

Ponieważ dysk jest wirtualny. W przypadku gościa KVM korzystającego z virtio-blk, smartctl -a /dev/vda wyświetla /dev/vda: Unable to detect device type, ponieważ dysk parawirtualny nie posiada kanału poleceń ATA ani SCSI, przez który mogłoby zostać przesłane żądanie SMART. Na dysku emulowanym użytkownik uzyskuje dostęp do urządzenia, którego model to QEMU HARDDISK, bez użytecznych danych SMART. Wewnątrz kontenera narzędzie smartctl jest blokowane ze względu na brak CAP_SYS_RAWIO. Żaden z tych przypadków nie jest błędem konfiguracji i żadna flaga -d ich nie naprawi.

Skąd mam wiedzieć, czy dysk mojego VPS ulega awarii?

Należy obserwować skutki, a nie sprzęt. Należy sprawdzać sudo journalctl -k -p err -b pod kątem linii blk_update_request: I/O error oraz Remounting filesystem read-only. Należy uruchomić sudo dumpe2fs -h /dev/vda1 | grep -i 'error count', aby znaleźć błędy, których nie ma już w dziennikach. Należy śledzić r_await z iostat -xdz 5 w odniesieniu do wartości bazowych zarejestrowanych w czasie poprawnego działania systemu. Na VPS błąd I/O zazwyczaj oznacza problem z pamięcią masową hosta, a nie awarię fizycznego dysku, dlatego należy zgłosić go w tickecie do pomocy technicznej, dołączając znacznik czasu i sektor.

O czym powinienem otrzymywać powiadomienia w kontekście kondycji dysku VPS?

Wystarczą cztery rodzaje powiadomień. Montowanie w trybie tylko do odczytu, wykryte przez node_filesystem_readonly == 1 lub nieudany test zapisu. Wolne miejsce i wolne inody zbliżające się do zera. Każdy błąd jądra I/O error w ostatnim interwale. Sygnał heartbeat z serwera, aby brak odpowiedzi wyzwolił powiadomienie, gdy maszyna przestanie odpowiadać. Należy pominąć wszystko, co pochodzi z SMART, ponieważ na dysku wirtualnym wartości te albo nie istnieją, albo opisują emulację hypervisora.

Dlaczego mój system plików został ponownie zamontowany w trybie tylko do odczytu?

System ext4 zamontowany z errors=remount-ro wykonuje to celowo po napotkaniu błędu metadanych: zatrzymuje zapis, zamiast kontynuować pracę mimo uszkodzeń. Przyczyna znajduje się w dzienniku jądra tuż nad linią o ponownym montowaniu, zazwyczaj jest to EXT4-fs error o przerwanej kronice (journal) po tym, jak urządzenie bazowe zwróciło błąd I/O. Ponowne montowanie w trybie odczytu i zapisu bez sprawdzenia systemu plików ukrywa objaw, ale nie usuwa przyczyny. Należy zabezpieczyć dziennik, a następnie sprawdzić system plików po odmontowaniu w trybie ratunkowym za pomocą e2fsck -fy /dev/vda1.

Czy kiedykolwiek mogę odczytać dane SMART na serwerze wirtualnym?

W określonych przypadkach tak. Serwery dedykowane i typu bare metal udostępniają rzeczywiste atrybuty. Podobnie jest w przypadku planów pamięci masowej, które przekazują fizyczny dysk bezpośrednio do gościa, oraz każdego hosta, którego jest się właścicielem. Niektóre platformy prezentują gościowi kontroler NVMe i nvme smart-log zwraca dziennik, więc najpierw należy uruchomić sudo nvme id-ctrl /dev/nvme0: numer modelu wskazujący na sieciową usługę przechowywania danych oznacza, że liczniki pochodzą z kontrolera programowego. Tam, gdzie węzeł z przekazywaniem bezpośrednim (passthrough) udostępnia rzeczywiste liczniki na maszynie współdzielonej, opisują one sprzęt współdzielony z innymi użytkownikami, więc jedynym użytecznym działaniem jest zgłoszenie do pomocy technicznej.