Schijfmonitoring op een VPS: wat kunt u echt meten?

Wat schijfmonitoring op een VPS daadwerkelijk kan zien

Schijfmonitoring op een VPS begint met een feit dat de meeste handleidingen negeren: de schijf is niet van u. Uw guest ziet een virtueel block device. De fysieke schijf, en elke teller die daarop wordt bijgehouden, is eigendom van de host. smartctl /dev/vda faalt niet omdat u het commando verkeerd heeft getypt. Het faalt omdat er achter dat apparaat niets is dat de vraag kan beantwoorden.

SMART (self-monitoring, analysis and reporting technology) is een tabel met tellers die op de schijf zelf wordt bijgehouden: reallocated sectors, pending sectors, power-on hours, media errors. Het uitlezen van die tabel vereist een pad voor ATA- of NVMe (non-volatile memory express)-commando's om de echte hardware te bereiken. Een paravirtual disk biedt dit niet, waardoor de guest opslag krijgt waarbij de telemetrie is verwijderd.

Een huurder monitort de effecten, niet de hardware. Vanuit de guest zijn vier signalen zichtbaar: I/O (input/output)-fouten in het kernel-logboek, een bestandssysteem dat opnieuw wordt aangekoppeld als read-only, latentie die oploopt en schijfruimte die opraakt. Voor alle vier deze punten kunnen vandaag nog waarschuwingen worden ingesteld, en alle vier worden zichtbaar voordat een gebruiker klaagt. Richt deze als eerste in. De verdeling van verantwoordelijkheid komt aan het einde, omdat dit bepaalt waar u uw inspanningen op moet richten.

Controleer wat uw eigen server blootstelt

Ga er niet vanuit in welke situatie u zich bevindt. Kijk eerst, en lees daarna het gedeelte dat overeenkomt.

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

virtio-blk, de gebruikelijke KVM (kernel-based virtual machine) schijf. Het apparaat is /dev/vda en smartctl stopt voordat er gegevens worden verzonden:

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

virtio-blk is een paravirtual transport zonder onderliggende ATA- of SCSI-commandoset, waardoor er geen kanaal is om een SMART-verzoek te versturen. -d sat en -d scsi falen op dezelfde manier, omdat het transport het probleem is en niet de vlag.

Een geëmuleerde SATA- of SCSI-schijf. Het apparaat is /dev/sda en smartctl komt ver genoeg om het te identificeren. De modelregel bevat QEMU HARDDISK. Die tekenreeks beantwoordt de vraag al: u leest een apparaat dat door de emulator is verzonnen en het rapporteert geen bruikbare SMART-functionaliteit.

Een NVMe-namespace. sudo nvme smart-log /dev/nvme0n1 geeft een volledig logboek terug, en dat is waar mensen zich laten misleiden. Controleer eerst de controller-identiteit met sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Een modelnummer dat verwijst naar een netwerkopslagproduct betekent dat de controller softwarematig is, dus percentage_used en media_errors beschrijven die emulatie in plaats van het flashgeheugen onder uw data. Als u wilt weten wat uw opslag werkelijk is, controleer de NVMe-schijf op Linux in plaats van te vertrouwen op de beschrijving van het abonnement.

Een container, zoals LXC (Linux containers) of OpenVZ. U beschikt niet over een eigen block device. lsblk toont de apparaten van de host of helemaal niets, en smartctl wordt geweigerd omdat de container geen CAP_SYS_RAWIO bevat:

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

Eén waarschuwing voor het geval dat het wel werkt. Als smartctl op een VPS een volledige attributentabel teruggeeft, lees dan het serienummer voordat u actie onderneemt. Sommige hosts stellen een passthrough-device node bloot, en die tellers behoren toe aan hardware die wordt gedeeld door elke huurder op die machine. Een stijgende Reallocated_Sector_Ct is in dat geval een supportticket. Het is geen uitspraak over uw data.

Signaal 1: I/O-fouten in het kernel-logboek

Dit is het meest waardevolle signaal waarover een tenant beschikt en hiervoor is geen agent vereist.

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'

Een mislukt verzoek van de virtuele schijf ziet er als volgt uit:

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

De block layer vroeg de host om een schrijfactie en de host gaf een foutmelding terug. Op een VPS is dit zelden een defecte flash-cel. Meestal betreft het de opslaglaag van de host of het netwerkpad naar de netwerkopslag (NAS), en is het dus een gebeurtenis aan de kant van de provider. Kopieer de tijdstempel, de apparaatnaam en de sector naar uw ticket; dit zijn de gegevens die een opslagteam kan matchen met hun eigen logs.

De ext4-reeks die het belangrijkst is, is dit paar:

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

De tweede regel is de schadelijke, omdat de machine actief blijft. Deze reageert op ping, reageert op SSH, maar elke schrijfactie mislukt. Een eenvoudige HTTP-controle blijft slagen terwijl uw applicatie bij elk verzoek een foutmelding geeft.

XFS schakelt het bestandssysteem in plaats daarvan uit:

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 leest alleen de huidige boot, tenzij het logboek op schijf is opgeslagen. Veel images leveren een vluchtig logboek dat in het RAM-geheugen leeft. Schakel persistentie in, anders verdwijnt het bewijsmateriaal precies op het moment van de herstart die u uitvoert tijdens het troubleshooten.

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

Na uw volgende herstart zou journalctl --list-boots meer dan één boot moeten weergeven. Zelfs met ingeschakelde persistentie kan een bestandssysteem dat op alleen-lezen is overgeschakeld niet vastleggen wat er daarna is gebeurd. Dit is het valide argument voor het extern opslaan van logs.

Signaal 2: een read-only remount opvangen

Maak de foutmelding duidelijk voordat u deze probeert te detecteren.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Zoek naar errors=remount-ro in de opties. Ubuntu- en Debian-cloudimages stellen dit in via /etc/fstab, zodat een metadatafout het bestandssysteem op read-only zet in plaats van door te gaan bij schade. Als dit ontbreekt, voeg het dan toe aan de root-entry in /etc/fstab, of stel het in het superblock in met sudo tune2fs -e remount-ro /dev/vda1. Een duidelijke stop is beter dan stille corruptie.

Een mount-vlag is geen bewijs. Test dit door te schrijven:

touch /var/tmp/.disk-probe

Op een read-only root geeft dit exact het volgende weer:

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

Gebruik /var/tmp, niet /tmp. Op de meeste images is /tmp een tmpfs in het geheugen, dus een succesvolle schrijfactie daar bewijst niets over uw schijf.

Combineer de schrijftest met een schijfruimtecontrole en verstuur alleen een heartbeat als alle controles slagen:

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 op de laatste regel betekent dat de hele keten werkt. set -eu zorgt ervoor dat elke mislukte controle een non-zero exitcode geeft voordat de curl-regel wordt uitgevoerd, waardoor er geen heartbeat wordt verstuurd. Die inversie is het doel: de monitor kleurt rood omdat er niets is binnengekomen, en een server die niet kan schrijven kan niet worden vertrouwd om zijn eigen probleem te beschrijven. Lezen werkt nog wel op een read-only bestandssysteem, dus het script zelf start nog steeds.

Voer het uit via een systemd-timer.

# /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 zou de unit moeten tonen met een NEXT-tijd van minder dan vijf minuten geleden. Een mislukte uitvoering verschijnt in journalctl -u disk-probe.service met de foutmelding van de shell zelf, zodat u een read-only bestandssysteem kunt onderscheiden van een vol bestandssysteem zonder in te loggen.

Die push-URL is een Uptime Kuma push-monitor. Maak een monitor van het type Push aan, kopieer het token in het script en stel het heartbeat-interval van de monitor iets langer in dan het timer-interval, zodat een trage uitvoering u niet om 03:00 uur wakker maakt. Als u nog geen statuspagina heeft, is een zelfgehoste Uptime Kuma-instantie de goedkoopste plek om deze controle onder te brengen.

Twee eerlijke beperkingen. De probe bevestigt dat een schrijfactie is geaccepteerd, niet dat de bytes de duurzame opslag hebben bereikt, omdat het teruglezen vanuit de page cache kan gebeuren. Bovendien draait het op de machine die het bewaakt, dus een volledig vastgelopen server wordt stil in plaats van een diagnose te rapporteren.

Signaal 3: trends in latentie en doorvoer

sudo apt install -y sysstat
iostat -xdz 5 3

Lees eerst r_await en w_await. Dit zijn de gemiddelde milliseconden die een lees- of schrijfactie in beslag nam, inclusief de tijd die in de wachtrij werd doorgebracht. Bekijk daarna aqu-sz, het gemiddelde aantal actieve verzoeken. Negeer %util op een virtuele schijf: dit betekent enkel dat de wachtrij niet leeg was. Een apparaat dat veel verzoeken parallel verwerkt, zit nabij 100 procent terwijl het nog lang niet zijn limiet heeft bereikt. await is het getal dat bijhoudt wat gebruikers ervaren.

Absolute waarden zijn minder belangrijk dan uw eigen nulmeting; leg daarom een rustig uur vast en bewaar deze gegevens. /proc/diskstats is de ruwe bron als u de tellers liever zelf verzamelt.

Voor een gerichte meting:

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

Lees het clat percentiles-blok, in het bijzonder het 99e percentiel. --direct=1 slaat uw page cache over. Het slaat de cache van de host niet over, dus het resultaat beschrijft het volledige pad van uw proces tot aan de opslag van het platform. Voer dit uit terwijl de server inactief is, aangezien het concurreert met uw eigen werklast.

Een stijgende await zonder fouten in het kernel-logboek wijst meestal niet op een defecte schijf. Het is strijd om middelen op de host, de opslagvariant van CPU steal time door een luidruchtige buur. Als dit elke dag op hetzelfde uur terugkeert en uw supportticket levert geen resultaat op, dan is de oplossing een abonnement waarbij de I/O niet op dezelfde manier wordt gedeeld. Dit is het geval bij een storage VPS in plaats van een reguliere VPS wanneer de werklast schijfgebonden is.

Signaal 4: bestandssysteemcontroles die u kunt uitvoeren terwijl het systeem is aangekoppeld

ext4 houdt een foutenteller bij in het superblock; deze blijft behouden na een herstart, zelfs als uw logs dat niet doen.

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

Een gezond bestandssysteem geeft Filesystem state: clean en FS Error count: 0 weer. clean with errors en een teller die niet op nul staat, betekenen dat de kernel op enig moment een metadatafout heeft aangetroffen, zelfs als niemand dit heeft opgemerkt en het logbestand inmiddels is overschreven. Dat ene commando hoort thuis in een wekelijkse controle.

U kunt geen fsck uitvoeren op een aangekoppeld root-bestandssysteem, en e2fsck -n op een actief bestandssysteem rapporteert problemen die enkel het gevolg zijn van gegevens die onderliggend wijzigen. Om een echte controle af te dwingen, voegt u fsck.mode=force fsck.repair=yes toe aan de kernel-commandoregel voor één opstart via de console van uw provider. systemd-fsck voert de controle vervolgens uit voordat de root-partitie lees-schrijf wordt aangekoppeld.

XFS heeft geen online controle. xfs_repair -n /dev/vda1 weigert te draaien op een aangekoppeld bestandssysteem, dus dit hoort thuis in de rescue-modus. XFS compenseert dit door luidruchtig te zijn: het schakelt het bestandssysteem uit bij een metadatafout in plaats van door te gaan.

Bij Btrfs zijn de tellers ingebouwd en persistent.

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

write_io_errs of corruption_errs boven nul is een daadwerkelijke gebeurtenis, en de tellers behouden hun waarden na een herstart totdat u ze reset. scrub leest elk blok opnieuw en verifieert de checksum; dit is het dichtstbijzijnde alternatief voor een mediatest op een virtuele schijf. Het is zwaar voor de I/O, dus plan dit in tijdens een rustig moment.

Signaal 5: vrije schijfruimte, inclusief de delen die df verbergt

Een tekort aan schijfruimte legt een server net zo plat als een defecte schijf, en het komt aanzienlijk vaker voor.

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

No space left on device terwijl df -h vrije ruimte toont, betekent dit dat het aantal inodes op is in plaats van de bytes, en df -i toont IUse% op 100 procent. Miljoenen kleine bestanden in een cache-directory of een mail-spool veroorzaken dit; het verwijderen van grote bestanden helpt dan niet.

Schijfruimte die na verwijdering niet vrijkomt, wordt meestal bezet door een verwijderd bestand dat nog openstaat in een actief proces. sudo lsof +L1 toont bestanden waarvan de link-count nul is bereikt. Het herstarten van het proces dat het bestand vasthoudt, geeft de ruimte vrij.

De journal is een veelvoorkomende, onopvallende verbruiker. journalctl --disk-usage rapporteert de huidige omvang. Begrens deze met SystemMaxUse=200M in /etc/systemd/journald.conf, gevolgd door sudo systemctl restart systemd-journald, en claim de ruimte direct terug met sudo journalctl --vacuum-size=200M.

Eén situatie lijkt op een bug, maar is dat niet. Bij thin-provisioned host-storage kan de pool van de host volraken terwijl uw df nog vrije gigabytes aangeeft. Uw schrijfoperaties falen vervolgens met I/O-fouten in het kernel-log, zonder enige waarschuwing over schijfruimte binnen de guest. Fouten zonder een vol bestandssysteem vormen een combinatie waarvoor u direct een ticket moet aanmaken.

Signalen koppelen aan een metrics agent

Een push-probe geeft een ja of nee als antwoord. Voor trends is een metrics agent nodig, en de Prometheus node_exporter exporteert al het bovenstaande zonder extra configuratie. De metric-namen om op voort te bouwen:

• node_filesystem_readonly wordt 1 wanneer een mount alleen-lezen is; dit is uw alarm voor een remount.
• node_filesystem_avail_bytes en node_filesystem_files_free dekken bytes en inodes afzonderlijk.
• node_disk_io_time_seconds_total en node_disk_read_time_seconds_total bieden bezettingstijd en latentie als counters die u kunt visualiseren.

Twee regels vangen de gevallen op die daadwerkelijk een melding (page) genereren:

- 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

De tweede regel wordt geactiveerd wanneer de huidige trend binnen vier dagen nul bereikt. Hierdoor wordt u dagen van tevoren gewaarschuwd in plaats van bij 95 procent vol, wanneer u nog maar minuten heeft.

Wie is waarvoor verantwoordelijk

Uw provider is eigenaar van de fysieke schijven. Zij lezen SMART-gegevens uit, beheren de array en vervangen een schijf met een oplopend aantal 'reallocated sectors', meestal zonder u daarvan op de hoogte te stellen, omdat de array het defect opvangt. Dat is waar RAID 10 op uw VPS voor dient: een defecte schijf leidt tot een rebuild in plaats van een uitval. U ziet hier niets van, en betalen voor die abstractie is grotendeels het doel van het huren van een virtuele server.

U bent eigenaar van uw data, en schijftelemetrie zou deze toch niet beschermen. De gebeurtenissen die daadwerkelijk data van een huurder vernietigen zijn een foutieve rm, een mislukte deploy, een indringer met uw SSH key, en een platformincident dat de array meeneemt. SMART-attributen voorspellen geen van deze zaken.

De werkelijke bescherming voor een huurder is dus een back-up die buiten de server staat en een restore die u zelf heeft uitgevoerd. Snapshots van de provider zijn handig, maar ze bevinden zich op hetzelfde platform als het object dat ze beschermen; daarom zijn snapshots en back-ups verschillende vormen van bescherming. Plan een oefening in uw agenda: herstel elk kwartaal de nieuwste back-up naar een nieuwe VPS, start de applicatie en noteer hoe lang dit duurde. Dat getal is uw werkelijke hersteltijd. De eerste oefening verloopt altijd trager dan verwacht.

Wanneer SMART op u van toepassing is

Handleidingen die smartctl onderwijzen zijn correct en zijn van toepassing zodra de hardware daadwerkelijk van u is:

• Een dedicated of bare metal server, waarbij sudo smartctl -a /dev/sda de volledige attributentabel retourneert en smartd u kan mailen wanneer een attribuut wijzigt.
• Opslagplannen die een fysieke schijf doorgeven aan de guest. Providers documenteren dit expliciet, omdat het een verkoopargument is.
• Hardware die uw eigendom is, thuis of in gehuurde rackruimte.
• Een schijf achter een RAID-controller, bereikbaar met sudo smartctl -a -d megaraid,0 /dev/sda, of een USB-behuizing met -d sat.

Bij echte NVMe rapporteren sudo smartctl -a -d nvme /dev/nvme0 en sudo nvme smart-log /dev/nvme0n1 critical_warning en percentage_used vanaf de schijf zelf. Bij echte SATA zijn de attributen die falen voorspellen Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) en Reported_Uncorrect (187). Als een van deze afwijkt van nul, betekent dit dat u vervanging moet plannen. Grootschalige schijfstudies komen steeds weer uit op diezelfde korte lijst; de meeste andere attributen zijn ruis.

Draai de daemon in plaats van handmatig te controleren.

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

Het logboek van de zelftest hoort Completed without error te tonen voor de test die u zojuist bent gestart. Ubuntu en Debian leveren /etc/smartd.conf met een DEVICESCAN-regel, actueel per augustus 2026, waardoor de daemon elke schijf die hij kan zien oppikt en bij een wijziging naar root mailt. Niets hiervan werkt op een virtuele schijf, en dat is de reden waarom de rest van deze handleiding bestaat.

FAQ

Waarom werkt smartctl niet op mijn VPS?

Omdat de schijf virtueel is. Op een KVM-gast die gebruikmaakt van virtio-blk, geeft smartctl -a /dev/vda de melding /dev/vda: Unable to detect device type, aangezien een paravirtuele schijf geen ATA- of SCSI-opdrachtkanaal bevat waarover een SMART-verzoek kan worden verzonden. Op een geëmuleerde schijf bereikt u een apparaat waarvan het model wordt weergegeven als QEMU HARDDISK, zonder bruikbare SMART-data erachter. Binnen een container wordt smartctl direct geweigerd vanwege het ontbreken van CAP_SYS_RAWIO. Geen van deze gevallen is een configuratiefout en geen enkele -d-vlag lost dit op.

Hoe weet ik of mijn VPS-schijf defect raakt?

Let op de effecten in plaats van op de hardware. Controleer sudo journalctl -k -p err -b op blk_update_request: I/O error-regels en op Remounting filesystem read-only. Voer sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' uit om fouten te vinden die niet meer in de logs staan. Houd r_await uit iostat -xdz 5 bij en vergelijk deze met een nulmeting die u hebt vastgelegd toen het systeem naar behoren functioneerde. Op een VPS duidt een I/O-fout meestal op een probleem met de opslag van de host in plaats van op een stervende schijf; dit hoort daarom thuis in een supportticket, inclusief de tijdstempel en de betreffende sector.

Waarop moet ik alarmeren voor de schijfgezondheid van een VPS?

Vier waarschuwingen dekken dit af. Een read-only mount, gedetecteerd via node_filesystem_readonly == 1 of een schrijf-test die faalt. Vrije ruimte en vrije inodes die naar nul neigen. Elke kernel I/O error in het laatste interval. Een heartbeat van de server, zodat stilte u alarmeert wanneer de machine niet meer reageert. Sla alles over wat is afgeleid van SMART, omdat deze waarden op een virtuele schijf ofwel ontbreken ofwel de emulatie van de hypervisor beschrijven.

Waarom is mijn bestandssysteem opnieuw gemount als read-only?

ext4, gemount met errors=remount-ro, doet dit bewust wanneer het een metadatafout tegenkomt: het stopt met schrijven in plaats van door te gaan over beschadigde data. De trigger staat in de kernellog vlak boven de remount-regel, meestal een EXT4-fs error over een afgebroken journal nadat het onderliggende apparaat een I/O-fout teruggaf. Opnieuw mounten als read-write zonder het bestandssysteem te controleren verbergt het symptoom en laat de oorzaak in stand. Sla de log op en controleer vervolgens het bestandssysteem terwijl het ontkoppeld is vanuit de rescue-modus met e2fsck -fy /dev/vda1.

Kan ik ooit SMART-data uitlezen op een virtuele server?

In specifieke gevallen wel. Dedicated en bare-metal servers bieden u echte attributen. Dat geldt ook voor opslagabonnementen die een fysieke schijf direct doorgeven aan de gast, en elke host die u zelf beheert. Sommige platforms presenteren een NVMe-controller aan de gast en nvme smart-log geeft een log terug, dus voer eerst sudo nvme id-ctrl /dev/nvme0 uit: een modelnummer dat verwijst naar een netwerkopslagdienst betekent dat die tellers afkomstig zijn van een softwarematige controller. En waar een passthrough-node wel echte tellers blootstelt op een gedeelde machine, beschrijven deze hardware die met andere huurders wordt gedeeld; de enige nuttige actie is dan een supportticket.