Monitoraggio salute disco su un VPS: cosa puoi vedere

Cosa può effettivamente rilevare il monitoraggio dello stato dei dischi su un VPS

Il monitoraggio dello stato dei dischi su un VPS parte da un dato che la maggior parte delle guide evita: il disco non è di tua proprietà. Il sistema guest vede un dispositivo a blocchi virtuale. Il disco fisico e tutti i contatori memorizzati al suo interno appartengono all'host. smartctl /dev/vda non fallisce perché hai digitato il comando in modo errato. Fallisce perché dietro quel dispositivo non c'è nulla in grado di fornire la risposta.

SMART (self-monitoring, analysis and reporting technology) è una tabella di contatori memorizzata direttamente sul disco: settori riallocati, settori in attesa, ore di funzionamento e errori del supporto. Per leggere questa tabella, i comandi ATA o NVMe (non-volatile memory express) devono poter raggiungere l'hardware reale. Un disco paravirtualizzato non fornisce questo percorso, quindi il guest riceve uno storage privo dei relativi dati di telemetria.

Un tenant monitora gli effetti, non l'hardware. Dall'interno del guest sono visibili quattro segnali: errori di I/O (input/output) nel log del kernel, un filesystem rimontato in sola lettura, una latenza in aumento e lo spazio in esaurimento. È possibile configurare un alert per tutti e quattro già oggi e tutti possono manifestarsi prima che un utente segnali un problema. Configura prima questi controlli. La suddivisione delle responsabilità viene trattata alla fine, perché determina dove conviene concentrare l'attività.

Verifica cosa espone il tuo server

Non supporre in quale caso ti trovi. Controlla, quindi leggi la sezione corrispondente.

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

virtio-blk, il disco KVM (kernel-based virtual machine) più comune. Il dispositivo è /dev/vda e smartctl si interrompe prima di inviare qualsiasi richiesta:

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

virtio-blk è un trasporto paravirtualizzato che non dispone di un set di comandi ATA o SCSI sottostante. Non esiste quindi un canale per trasportare una richiesta SMART. -d sat e -d scsi falliscono nello stesso modo, perché il problema è il trasporto, non l'opzione.

Un disco SATA o SCSI emulato. Il dispositivo è /dev/sda e smartctl riesce a identificarlo. La riga del modello è QEMU HARDDISK. Questa stringa risponde da sola alla domanda: stai leggendo un dispositivo creato dall'emulatore e non viene riportata alcuna funzionalità SMART utilizzabile.

Un namespace NVMe. sudo nvme smart-log /dev/nvme0n1 restituisce un log completo, ed è qui che è facile trarre conclusioni errate. Controlla prima l'identità del controller con sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Un numero di modello che identifica un prodotto di storage di rete indica che il controller è software. percentage_used e media_errors descrivono quindi quell'emulazione, non la memoria flash su cui sono archiviati i tuoi dati. Se vuoi sapere qual è realmente il tuo storage, verifica il disco NVMe su Linux invece di fidarti della descrizione del piano.

Un container, come LXC (Linux containers) o OpenVZ. Non disponi di un block device personale. lsblk mostra i dispositivi dell'host oppure non mostra nulla, e smartctl viene rifiutato perché il container non contiene CAP_SYS_RAWIO:

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

Una precisazione sul caso in cui il controllo funzioni. Se smartctl su un VPS restituisce una tabella completa degli attributi, leggi il numero di serie prima di intervenire. Alcuni host espongono un device node tramite passthrough, e quei contatori appartengono a hardware condiviso da tutti i tenant di quella macchina. Un valore Reallocated_Sector_Ct in aumento richiede l'apertura di un ticket al supporto. Non indica un problema nei tuoi dati.

Segnale 1: errori I/O nel log del kernel

Questo è il segnale più utile per un tenant e non richiede alcun agent.

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'

Una richiesta non riuscita dal disco virtuale appare così:

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

Il block layer ha richiesto una scrittura all'host, ma l'host ha restituito un errore. Su un VPS, raramente la causa è una cella flash guasta. Di solito il problema riguarda il livello di storage dell'host oppure il percorso di rete verso lo storage collegato alla rete; quindi si tratta di un evento lato provider. Inserisci nel ticket il timestamp, il nome del device e il settore. Il team storage può confrontare questi dati con i propri log.

La sequenza ext4 più importante è questa coppia:

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

La seconda riga è quella più problematica, perché la macchina rimane attiva. Risponde al ping, risponde via SSH, ma ogni scrittura fallisce. Un controllo HTTP semplice continua ad avere esito positivo, mentre l'applicazione restituisce un errore a ogni richiesta.

XFS arresta invece il filesystem:

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 legge soltanto il boot corrente, a meno che il journal non sia memorizzato su disco. Molte immagini includono un journal volatile che risiede nella RAM. Abilita la persistenza, altrimenti le prove scompaiono proprio durante il riavvio che eseguirai per il troubleshooting.

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

Dopo il prossimo riavvio, journalctl --list-boots dovrebbe elencare più di un boot. Anche con la persistenza abilitata, un filesystem diventato di sola lettura non può registrare ciò che accade in seguito. Questo dimostra perché è opportuno inviare i log a un sistema esterno.

Segnale 2: rilevare un rimontaggio in sola lettura

Rendi evidente l'errore prima di provare a rilevarlo.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Cerca errors=remount-ro nelle opzioni. Le immagini cloud Ubuntu e Debian lo impostano in /etc/fstab, quindi un errore dei metadati forza il filesystem in sola lettura invece di continuare dopo il danneggiamento. Se manca, aggiungilo alla voce della root in /etc/fstab oppure impostalo nel superblocco con sudo tune2fs -e remount-ro /dev/vda1. Un arresto evidente è preferibile a una corruzione silenziosa.

Un flag di mount non è una prova. Verifica scrivendo:

touch /var/tmp/.disk-probe

Su una root in sola lettura, il comando stampa esattamente:

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

Usa /var/tmp, non /tmp. Nella maggior parte delle immagini, /tmp è un tmpfs conservato in memoria, quindi una scrittura riuscita su quel percorso non dimostra nulla sul disco.

Combina il test di scrittura con un controllo dello spazio e invia un heartbeat solo quando tutti i controlli hanno esito positivo:

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 nell'ultima riga indica che l'intera catena funziona. set -eu fa terminare l'esecuzione con un codice diverso da zero al primo controllo fallito, prima dell'esecuzione della riga curl, quindi non viene inviato alcun heartbeat. Questa inversione è il punto: il monitor passa allo stato rosso perché non riceve nulla e un server che non può scrivere non è affidabile nel descrivere il proprio problema. Le letture continuano a funzionare su un filesystem in sola lettura, quindi lo script può comunque avviarsi.

Eseguilo con un timer 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 dovrebbe mostrare l'unità con un orario NEXT a meno di cinque minuti di distanza. Un'esecuzione non riuscita compare in journalctl -u disk-probe.service con il testo di errore prodotto dalla shell, quindi puoi distinguere un filesystem in sola lettura da uno pieno senza eseguire l'accesso al server.

Quell'URL push appartiene a un monitor push di Uptime Kuma. Crea un monitor di tipo Push, copia il relativo token nello script e imposta l'intervallo dell'heartbeat del monitor a un valore leggermente superiore all'intervallo del timer, così un'esecuzione lenta non ti invia una notifica alle 03:00. Se non hai ancora una status page, un'istanza Uptime Kuma self-hosted è la soluzione meno costosa per ospitare questo controllo.

Ci sono due limiti importanti. Il test conferma che una scrittura è stata accettata, ma non che i byte siano stati salvati su storage persistente, perché la lettura successiva può essere servita dalla page cache. Inoltre, il controllo viene eseguito sulla macchina monitorata, quindi un server completamente bloccato diventa silenzioso invece di fornire una diagnosi.

Tendenza di latenza e throughput

sudo apt install -y sysstat
iostat -xdz 5 3

Leggere prima r_await e w_await. Sono i millisecondi medi impiegati da un'operazione di lettura o scrittura, incluso il tempo di attesa nella coda. Leggere poi aqu-sz, cioè il numero medio di richieste in corso. Ignorare %util su un disco virtuale: indica soltanto che la coda non era vuota. Un dispositivo che gestisce molte richieste in parallelo può rimanere vicino al 100 percento senza essere prossimo al limite. await è il valore che riflette ciò che percepiscono gli utenti.

I valori assoluti contano meno della propria baseline, quindi registrare un'ora di bassa attività e conservarla. /proc/diskstats è la sorgente grezza, se si preferisce raccogliere direttamente i contatori.

Per una misurazione controllata:

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

Leggere il blocco clat percentiles, in particolare il 99° percentile. --direct=1 bypassa la page cache. Non bypassa la cache dell'host, quindi il risultato descrive l'intero percorso dal processo fino allo storage della piattaforma. Eseguire il test mentre il server è inattivo, perché il test compete con il carico di lavoro.

L'aumento di await senza errori nel kernel log di solito non indica un disco guasto. Indica contesa sull'host, l'equivalente lato storage del tempo CPU sottratto da un vicino rumoroso. Se il fenomeno si ripresenta alla stessa ora ogni giorno e il ticket viene chiuso senza anomalie, la soluzione consiste in un piano con I/O non condiviso allo stesso modo. È il caso di un VPS con storage dedicato rispetto a un VPS standard quando il carico di lavoro è vincolato dal disco.

Segnale 4: controlli del filesystem eseguibili mentre è montato

ext4 conserva un contatore degli errori nel superblocco. Il contatore resta disponibile anche dopo i riavvii, quando i log potrebbero non essere più presenti.

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

Un filesystem integro restituisce Filesystem state: clean e FS Error count: 0. clean with errors e un contatore diverso da zero indicano che il kernel ha rilevato un errore nei metadati, anche se nessuno lo ha notato e il log è già stato ruotato. Questo comando va incluso nei controlli settimanali.

Non è possibile eseguire fsck sul filesystem root montato. Inoltre, e2fsck -n su un filesystem attivo segnala problemi causati soltanto dai dati che cambiano durante il controllo. Per eseguire un controllo effettivo, aggiungere fsck.mode=force fsck.repair=yes alla riga di comando del kernel per un avvio dalla console del provider. systemd-fsck esegue quindi il controllo prima che il filesystem root venga montato in lettura e scrittura.

XFS non supporta i controlli online. xfs_repair -n /dev/vda1 rifiuta di operare su un filesystem montato, quindi va eseguito in modalità di ripristino. XFS compensa questa limitazione con un comportamento immediato: arresta il filesystem quando rileva un errore nei metadati, invece di continuare a operare.

In Btrfs i contatori sono integrati e persistenti.

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

Un valore di write_io_errs o corruption_errs superiore a zero indica un evento reale. I contatori mantengono i valori dopo i riavvii, fino a quando non vengono azzerati. scrub rilegge ogni blocco e verifica il relativo checksum. È l'operazione più simile a un test del supporto disponibile su un disco virtuale. Richiede molto I/O, quindi pianificala in un'ora con poca attività.

Segnale 5: spazio libero, comprese le parti che df non mostra

L'esaurimento dello spazio interrompe il funzionamento di un server come farebbe un disco guasto, ma si verifica molto più spesso.

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

No space left on device mentre df -h mostra lo spazio libero indica che hai esaurito gli inode anziché i byte; df -i mostra IUse% al 100%. Milioni di file piccoli in una directory di cache o in una coda di posta possono causare questo problema, e l'eliminazione di file di grandi dimensioni non è sufficiente.

Lo spazio che non torna disponibile dopo l'eliminazione di un file è generalmente occupato da un file eliminato che un processo in esecuzione tiene ancora aperto. sudo lsof +L1 elenca i file il cui numero di collegamenti ha raggiunto zero. Riavviando il processo che tiene aperto uno di questi file, lo spazio viene rilasciato.

Il journal è un elemento che consuma spesso spazio senza attirare l'attenzione. journalctl --disk-usage indica quanto spazio occupa. Imposta un limite con SystemMaxUse=200M in /etc/systemd/journald.conf, quindi applicalo con sudo systemctl restart systemd-journald e recupera subito lo spazio con sudo journalctl --vacuum-size=200M.

Un caso sembra un bug, ma non lo è. In uno storage dell'host con thin provisioning, il pool dell'host può esaurirsi mentre df mostra ancora gigabyte liberi. Le scritture iniziano quindi a fallire con errori di I/O nel log del kernel, senza alcun avviso di spazio esaurito all'interno del guest. Gli errori in assenza di un filesystem pieno indicano una combinazione per cui conviene aprire un ticket nella stessa ora.

Collegare i segnali a un agent per le metriche

Un probe push restituisce sì o no. Per analizzare le tendenze serve un agent per le metriche; Prometheus node_exporter esporta già tutti i dati precedenti senza configurazione aggiuntiva. I nomi delle metriche da usare sono:

• node_filesystem_readonly passa a 1 quando un mount è in sola lettura. Questo genera l'allarme per il remount.
• node_filesystem_avail_bytes e node_filesystem_files_free coprono separatamente byte e inode.
• node_disk_io_time_seconds_total e node_disk_read_time_seconds_total forniscono il tempo occupato e la latenza come contatori che è possibile rappresentare nei grafici.

Due regole rilevano i casi che devono effettivamente generare una pagina:

- 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

La seconda regola si attiva quando la tendenza corrente raggiunge zero entro quattro giorni. In questo modo ricevi un avviso con giorni di anticipo, invece di essere avvisato quando il filesystem è pieno al 95 percento e restano solo pochi minuti.

Chi è responsabile di cosa

Il provider è responsabile dei dischi fisici. Legge i dati SMART, gestisce l'array e sostituisce i dischi con un numero crescente di settori riallocati, di solito senza informarti, perché l'array assorbe il guasto. È questo lo scopo di RAID 10 nel tuo VPS: un disco guasto diventa una ricostruzione dell'array invece di un'interruzione del servizio. Non puoi vedere nulla di tutto questo e pagare per questa astrazione è in gran parte il motivo per cui noleggi un server virtuale.

Tu sei responsabile dei tuoi dati e, in ogni caso, la telemetria dei dischi non li proteggerebbe. Gli eventi che distruggono realmente i dati del tenant sono un rm eseguito per errore, un deploy errato, un intruso con la tua chiave SSH e un incidente della piattaforma che coinvolge anche l'array. Gli attributi SMART non prevedono nessuno di questi eventi.

La protezione effettiva per un tenant è quindi un backup conservato fuori dal server e un ripristino eseguito personalmente. Gli snapshot del provider sono comodi, ma risiedono sulla stessa piattaforma dell'elemento che proteggono. Per questo snapshot e backup sono protezioni diverse. Pianifica un'esercitazione nel calendario: una volta a trimestre, ripristina il backup più recente in un VPS nuovo, avvia l'applicazione e annota quanto tempo è servito. Questo è il tuo tempo di ripristino effettivo. La prima esercitazione è sempre più lenta di quanto si prevedesse.

Quando SMART si applica al tuo caso

Le guide che insegnano smartctl sono corrette e si applicano non appena l'hardware è realmente tuo:

• Un server dedicato o bare metal, in cui sudo smartctl -a /dev/sda restituisce la tabella completa degli attributi e smartd può inviarti un'e-mail quando un attributo cambia.
• Piani di storage che espongono un disco fisico direttamente al guest. I provider lo documentano esplicitamente, perché è un elemento distintivo dell'offerta.
• Hardware di tua proprietà, a casa oppure in uno spazio rack che affitti.
• Un disco collegato tramite un controller RAID, accessibile con sudo smartctl -a -d megaraid,0 /dev/sda, oppure un enclosure USB con -d sat.

Su un NVMe reale, sudo smartctl -a -d nvme /dev/nvme0 e sudo nvme smart-log /dev/nvme0n1 restituiscono critical_warning e percentage_used direttamente dall'unità. Su un SATA reale, gli attributi che predicono un guasto sono Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) e Reported_Uncorrect (187). Se uno di questi valori aumenta rispetto a zero, pianifica la sostituzione del disco. Gli studi su larga scala sulle unità continuano a individuare lo stesso breve elenco; la maggior parte degli altri attributi è rumore.

Esegui il daemon invece di controllare manualmente.

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

Il log dei self-test dovrebbe mostrare Completed without error per l'esecuzione appena avviata. Ubuntu e Debian distribuiscono /etc/smartd.conf con una riga DEVICESCAN, aggiornata ad agosto 2026; il daemon rileva quindi ogni disco visibile e invia un'e-mail a root quando rileva una modifica. Nulla di tutto questo funziona su un disco virtuale, motivo per cui esiste il resto di questa guida.

FAQ

Perché smartctl non funziona sul mio VPS?

Perché il disco è virtuale. Su un guest KVM che usa virtio-blk, smartctl -a /dev/vda stampa /dev/vda: Unable to detect device type, perché un disco paravirtualizzato non dispone di un canale di comandi ATA o SCSI attraverso cui inoltrare una richiesta SMART. Su un disco emulato si raggiunge un dispositivo il cui modello restituisce QEMU HARDDISK, senza dati SMART utilizzabili. All'interno di un container, smartctl viene rifiutato direttamente per l'assenza di CAP_SYS_RAWIO. Nessuno di questi casi è dovuto a una configurazione errata e nessun flag -d può risolverli.

Come posso sapere se il disco del mio VPS sta per guastarsi?

Controlla gli effetti, non l'hardware. Verifica sudo journalctl -k -p err -b per individuare le righe blk_update_request: I/O error e Remounting filesystem read-only. Esegui sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' per trovare gli errori che i log hanno già perso. Monitora r_await da iostat -xdz 5 e confrontalo con una baseline registrata quando il sistema funzionava correttamente. Su un VPS, un errore di I/O indica generalmente un problema dello storage dell'host, non un disco guasto. Apri quindi un ticket all'assistenza allegando il timestamp e il settore interessato.

Su cosa devo configurare gli alert per lo stato del disco del VPS?

Quattro alert sono sufficienti. Un filesystem montato in sola lettura, rilevato tramite node_filesystem_readonly == 1 o da una probe di scrittura che restituisce un errore. Lo spazio libero e gli inode liberi che tendono verso zero. Qualsiasi I/O error del kernel nell'ultimo intervallo. Un heartbeat dal server, in modo che l'assenza di risposte generi un alert quando il sistema smette di rispondere. Evita tutto ciò che deriva da SMART, perché su un disco virtuale questi valori sono assenti oppure descrivono l'emulazione dell'hypervisor.

Perché il mio filesystem è stato rimontato in sola lettura?

ext4, se montato con errors=remount-ro, esegue deliberatamente questa operazione quando rileva un errore nei metadati: interrompe le scritture invece di continuare a operare su dati danneggiati. L'origine dell'evento è indicata nel log del kernel subito prima della riga relativa al rimontaggio. Di solito si tratta di un EXT4-fs error relativo a un journal interrotto dopo che il dispositivo sottostante ha restituito un errore di I/O. Rimontare il filesystem in lettura-scrittura senza controllarlo nasconde il sintomo e lascia invariata la causa. Acquisisci il log, quindi controlla il filesystem smontato dalla rescue mode con e2fsck -fy /dev/vda1.

Posso mai leggere dati SMART su un server virtuale?

In casi specifici, sì. I server dedicati e bare metal forniscono attributi reali. Lo stesso vale per i piani di storage che espongono direttamente un disco fisico al guest e per qualsiasi host di tua proprietà. Alcune piattaforme presentano un controller NVMe al guest e nvme smart-log restituisce un log. Esegui quindi prima sudo nvme id-ctrl /dev/nvme0: un numero di modello che identifica un servizio di storage di rete indica che questi contatori provengono da un controller software. Inoltre, se un nodo passthrough espone contatori reali su una macchina condivisa, questi descrivono hardware condiviso con altri tenant. In questo caso, l'unica azione utile è aprire un ticket all'assistenza.