Surveiller l'état des disques sur un VPS

Ce que la surveillance de l'état des disques sur un VPS permet réellement de voir

La surveillance de l'état des disques sur un VPS commence par un fait que la plupart des guides omettent : le disque ne vous appartient pas. Votre système invité voit un périphérique de bloc virtuel. Le disque physique, ainsi que chaque compteur stocké dessus, appartient à l'hôte. smartctl /dev/vda ne tombe pas en panne parce que vous avez mal tapé la commande. Il échoue parce que rien derrière ce périphérique ne peut répondre à la requête.

Le SMART (Self-Monitoring, Analysis and Reporting Technology) est une table de compteurs conservée sur le disque lui-même : secteurs réalloués, secteurs en attente, heures de fonctionnement, erreurs de support. La lecture de cette table nécessite un chemin pour que les commandes ATA ou NVMe (Non-Volatile Memory Express) atteignent le matériel réel. Un disque paravirtualisé ne fournit pas ce chemin, donc l'invité reçoit un stockage dont la télémétrie a été supprimée.

Un locataire surveille les effets, pas le matériel. Quatre signaux sont visibles depuis l'intérieur de l'invité : les erreurs d'I/O (Input/Output) dans le journal du noyau, un système de fichiers qui repasse en lecture seule, une latence qui dérive à la hausse et un espace disque saturé. Ces quatre points peuvent faire l'objet d'alertes dès aujourd'hui, et tous apparaissent avant qu'un utilisateur ne se plaigne. Configurez-les en priorité. La répartition des responsabilités intervient à la fin, car elle détermine où vous devez concentrer vos efforts.

Vérifiez ce que votre propre serveur expose

Ne présumez pas de votre situation. Observez, puis lisez la section correspondante.

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

virtio-blk, le disque KVM (kernel-based virtual machine) habituel. Le périphérique est /dev/vda et smartctl s'arrête avant d'envoyer quoi que ce soit :

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

virtio-blk est un transport paravirtualisé sans jeu de commandes ATA ou SCSI sous-jacent ; il n'existe donc aucun canal pour transmettre une requête SMART. -d sat et -d scsi échouent de la même manière, car le problème vient du transport et non du flag.

Un disque SATA ou SCSI émulé. Le périphérique est /dev/sda et smartctl va assez loin pour l'identifier. La ligne du modèle indique QEMU HARDDISK. Cette chaîne répond d'elle-même à la question : vous lisez un périphérique inventé par l'émulateur, qui ne signale aucune capacité SMART utilisable.

Un espace de nommage NVMe. sudo nvme smart-log /dev/nvme0n1 renvoie un journal complet, ce qui induit souvent en erreur. Vérifiez d'abord l'identité du contrôleur avec sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Un numéro de modèle mentionnant un produit de stockage réseau signifie que le contrôleur est logiciel ; percentage_used et media_errors décrivent donc cette émulation plutôt que la mémoire flash contenant vos données. Si vous voulez connaître la nature réelle de votre stockage, vérifiez le disque NVMe sous Linux au lieu de vous fier à la description du plan.

Un conteneur, comme LXC (Linux containers) ou OpenVZ. Vous ne possédez pas de périphérique bloc propre. lsblk affiche les périphériques de l'hôte ou rien du tout, et smartctl est refusé car le conteneur ne détient pas CAP_SYS_RAWIO :

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

Une mise en garde pour les cas où cela fonctionne. Si smartctl sur un VPS renvoie une table d'attributs complète, lisez le numéro de série avant d'agir. Certains hébergeurs exposent un nœud de périphérique en passthrough, et ces compteurs appartiennent au matériel partagé par tous les locataires de la machine. Une augmentation de Reallocated_Sector_Ct à cet endroit nécessite l'ouverture d'un ticket de support. Ce n'est pas une information concernant vos données.

Signal 1 : erreurs d'E/S dans le journal du noyau

C'est le signal le plus précieux pour un locataire, et il ne nécessite aucun 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'

Une requête ayant échoué depuis le disque virtuel ressemble à ceci :

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

La couche bloc a demandé une écriture à l'hôte et l'hôte a renvoyé une erreur. Sur un VPS, il s'agit rarement d'une cellule flash en fin de vie. C'est généralement la couche de stockage de l'hôte ou le chemin réseau vers le stockage distant, il s'agit donc d'un événement côté fournisseur. Copiez l'horodatage, le nom du périphérique et le secteur dans votre ticket, car ce sont les éléments qu'une équipe de stockage peut faire correspondre avec ses propres journaux.

La séquence ext4 qui compte le plus est cette paire :

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

La deuxième ligne est celle qui pose problème, car la machine reste active. Elle répond au ping, elle répond au SSH, et chaque écriture échoue. Un simple test HTTP continue de passer alors que votre application renvoie une erreur à chaque requête.

XFS verrouille le système de fichiers à la place :

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 ne lit que le boot actuel à moins que le journal ne soit stocké sur le disque, et de nombreuses images fournissent un journal volatil qui réside en RAM. Activez la persistance, sinon les preuves disparaîtront exactement au moment du redémarrage que vous effectuerez lors du dépannage.

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

Après votre prochain redémarrage, journalctl --list-boots devrait lister plus d'un boot. Même avec la persistance activée, un système de fichiers passé en lecture seule ne peut pas enregistrer ce qui s'est passé ensuite, ce qui est l'argument logique pour déporter les journaux hors de la machine.

Signal 2 : détecter un remontage en lecture seule

Faites en sorte que la défaillance soit explicite avant d'essayer de la détecter.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Recherchez errors=remount-ro dans les options. Les images cloud Ubuntu et Debian le définissent dans /etc/fstab, ainsi une erreur de métadonnées bascule le système de fichiers en lecture seule au lieu de poursuivre sur une corruption. S'il est absent, ajoutez-le à l'entrée racine dans /etc/fstab, ou définissez-le dans le superbloc avec sudo tune2fs -e remount-ro /dev/vda1. Un arrêt brutal vaut mieux qu'une corruption silencieuse.

Un flag de montage ne constitue pas une preuve. Testez par une écriture :

touch /var/tmp/.disk-probe

Sur une racine en lecture seule, cela affiche exactement :

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

Utilisez /var/tmp, pas /tmp. Sur la plupart des images, /tmp est un tmpfs en mémoire, donc une écriture réussie à cet endroit ne prouve rien sur votre disque.

Combinez le test d'écriture avec une vérification d'espace disque, et n'envoyez un heartbeat que si tous les tests réussissent :

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 sur cette dernière ligne signifie que toute la chaîne fonctionne. set -eu fait en sorte que tout échec de test provoque une sortie en erreur avant que la ligne curl ne s'exécute, donc aucun heartbeat n'est envoyé. Cette inversion est le but recherché : le moniteur passe au rouge car rien n'est arrivé, et un serveur qui ne peut pas écrire ne peut pas être considéré comme fiable pour décrire son propre problème. Les lectures fonctionnent toujours sur un système de fichiers en lecture seule, donc le script lui-même démarre toujours.

Exécutez-le via 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 doit afficher l'unité avec un temps NEXT inférieur à cinq minutes. Une exécution échouée apparaît dans journalctl -u disk-probe.service avec le texte d'erreur du shell, vous pouvez donc distinguer un système de fichiers en lecture seule d'un système plein sans vous connecter.

Cette URL de push correspond à un moniteur de type Push dans Uptime Kuma. Créez un moniteur de type Push, copiez son jeton dans le script, et réglez l'intervalle de heartbeat du moniteur un peu plus long que l'intervalle du timer pour qu'une exécution lente ne vous alerte pas à 03:00. Si vous n'avez pas encore de page de statut, une instance Uptime Kuma auto-hébergée est l'endroit le moins coûteux pour placer cette vérification.

Deux limites honnêtes. La sonde confirme qu'une écriture a été acceptée, pas que les octets ont atteint un stockage durable, car la relecture peut être servie depuis le cache de pages. Et elle s'exécute sur la machine qu'elle surveille, donc un serveur totalement bloqué devient silencieux au lieu de rapporter un diagnostic.

Signal 3 : tendances de latence et de débit

sudo apt install -y sysstat
iostat -xdz 5 3

Lisez d'abord r_await et w_await. Il s'agit du nombre moyen de millisecondes nécessaires à une lecture ou une écriture, incluant le temps d'attente dans la file. Lisez ensuite aqu-sz, le nombre moyen de requêtes en cours. Ignorez %util sur un disque virtuel : cela signifie seulement que la file n'était pas vide. Un périphérique traitant de nombreuses requêtes en parallèle affiche près de 100 pour cent alors qu'il est loin de sa limite. await est l'indicateur qui reflète le ressenti des utilisateurs.

Les valeurs absolues importent moins que votre propre ligne de base ; enregistrez donc une période d'activité faible et conservez-la. /proc/diskstats est la source brute si vous préférez collecter les compteurs vous-même.

Pour une mesure délibérée :

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

Lisez le bloc clat percentiles, en particulier le 99e centile. --direct=1 ignore votre cache de page. Il ne contourne pas le cache de l'hôte, donc le résultat décrit le chemin complet depuis votre processus jusqu'au stockage de la plateforme. Exécutez-le pendant que le serveur est inactif, car il entre en concurrence avec votre propre charge de travail.

Une augmentation de await sans erreur dans le journal du noyau n'indique généralement pas une défaillance du disque. Il s'agit d'une contention sur l'hôte, l'équivalent stockage du temps de vol CPU dû à un voisin bruyant. Si le phénomène se reproduit à la même heure chaque jour et que votre ticket d'assistance ne révèle rien, la solution est de prévoir un stockage qui n'est pas partagé de la même manière, ce qui est le cas pour un VPS de stockage par rapport à un VPS classique lorsque la charge de travail est limitée par les entrées/sorties disque.

Signal 4 : vérifications du système de fichiers réalisables à chaud

ext4 conserve un compteur d'erreurs dans le superbloc, qui persiste après les redémarrages même si vos journaux ont été effacés.

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

Un système de fichiers sain affiche Filesystem state: clean et FS Error count: 0. clean with errors et un compteur différent de zéro indiquent que le noyau a rencontré une erreur de métadonnées à un moment donné, même si personne ne l'a remarqué et que le journal a été purgé. Cette commande doit faire partie de vos vérifications hebdomadaires.

Vous ne pouvez pas exécuter fsck sur un système de fichiers racine monté, et e2fsck -n sur un système de fichiers actif signale des problèmes qui ne sont que le résultat de la modification des données en cours d'utilisation. Pour forcer une vérification réelle, ajoutez fsck.mode=force fsck.repair=yes à la ligne de commande du noyau pour un démarrage depuis la console de votre fournisseur. systemd-fsck effectue alors la vérification avant que la racine ne soit montée en lecture-écriture.

XFS ne propose pas de vérification en ligne. xfs_repair -n /dev/vda1 refuse de s'exécuter sur un système de fichiers monté ; son utilisation est donc réservée au mode secours. XFS compense cela par sa verbosité : il verrouille le système de fichiers en cas d'erreur de métadonnées au lieu de continuer.

Sur Btrfs, les compteurs sont intégrés et persistants.

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

write_io_errs ou corruption_errs au-dessus de zéro constituent un événement réel, et les compteurs conservent leurs valeurs après les redémarrages jusqu'à ce que vous les réinitialisiez. scrub relit chaque bloc et vérifie sa somme de contrôle, ce qui est l'équivalent le plus proche d'un test de support disponible sur un disque virtuel. Cette opération est intensive en I/O, planifiez-la donc durant une période de faible activité.

Signal 5 : espace libre, y compris les zones masquées par df

Le manque d'espace disque paralyse un serveur tout comme une défaillance matérielle, et ce problème survient beaucoup plus fréquemment.

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

No space left on device alors que df -h indique de l'espace libre signifie que vous avez épuisé vos inodes plutôt que vos octets, et df -i affiche IUse% à 100 pour cent. Des millions de petits fichiers dans un répertoire de cache ou une file d'attente de mails provoquent ce phénomène, et supprimer de gros fichiers ne résout rien.

L'espace qui ne revient pas après une suppression correspond généralement à un fichier supprimé mais toujours maintenu ouvert par un processus en cours d'exécution. sudo lsof +L1 liste les fichiers dont le compteur de liens a atteint zéro. Redémarrer le processus qui détient le fichier libère l'espace.

Le journal est un consommateur silencieux courant. journalctl --disk-usage indique ce qu'il occupe. Limitez sa taille avec SystemMaxUse=200M dans /etc/systemd/journald.conf, suivi de sudo systemctl restart systemd-journald, puis récupérez l'espace immédiatement avec sudo journalctl --vacuum-size=200M.

Un cas ressemble à un bug sans en être un. Sur un stockage hôte en provisionnement fin (thin provisioning), le pool de l'hôte peut être saturé alors que votre df affiche encore des gigaoctets libres. Vos écritures échouent alors avec des erreurs d'E/S dans le journal du noyau, sans aucune alerte d'espace disque à l'intérieur de l'invité. Des erreurs sans système de fichiers saturé constituent une situation qui justifie l'ouverture d'un ticket dans l'heure.

Relier les signaux à un agent de métriques

Une sonde de type push répond par oui ou par non. Les tendances nécessitent un agent de métriques, et le node_exporter de Prometheus exporte déjà tout ce qui précède sans configuration supplémentaire. Les noms de métriques sur lesquels s'appuyer :

• node_filesystem_readonly passe à 1 lorsqu'un point de montage est en lecture seule, ce qui constitue votre alarme de remontage.
• node_filesystem_avail_bytes et node_filesystem_files_free couvrent séparément les octets et les inodes.
• node_disk_io_time_seconds_total et node_disk_read_time_seconds_total fournissent le temps d'activité et la latence sous forme de compteurs que vous pouvez représenter graphiquement.

Deux règles permettent de détecter les cas qui déclenchent réellement une alerte :

- 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 seconde règle se déclenche lorsque la tendance actuelle atteint zéro d'ici quatre jours, ce qui vous permet d'être averti plusieurs jours à l'avance au lieu d'attendre le seuil de 95 pour cent, où il ne vous reste que quelques minutes.

Qui est responsable de quoi

Votre fournisseur est propriétaire des disques physiques. Il surveille les données SMART, gère la grappe de disques et remplace un disque présentant un nombre croissant de secteurs réalloués, généralement sans vous en informer, car la grappe absorbe la défaillance. C'est précisément l'utilité du RAID 10 sur votre VPS : un disque défectueux entraîne une reconstruction plutôt qu'une interruption de service. Vous ne voyez rien de tout cela, et payer pour cette abstraction constitue l'essentiel de l'intérêt de louer un serveur virtuel.

Vous êtes propriétaire de vos données, et la télémétrie des disques ne les protégerait pas de toute façon. Les événements qui détruisent réellement les données d'un locataire sont une commande rm erronée, un déploiement défectueux, un intrus possédant votre clé SSH, ou un incident de plateforme qui emporte la grappe avec lui. Les attributs SMART ne permettent de prédire aucun de ces scénarios.

La véritable protection d'un locataire réside donc dans une sauvegarde située hors du serveur et dans une procédure de restauration que vous avez vous-même effectuée. Les snapshots du fournisseur sont pratiques, mais ils résident sur la même plateforme que ce qu'ils protègent, c'est pourquoi les snapshots et les sauvegardes sont des protections différentes. Inscrivez un exercice dans votre calendrier : une fois par trimestre, restaurez la sauvegarde la plus récente sur un VPS vierge, démarrez l'application et notez le temps nécessaire. Ce chiffre représente votre véritable temps de rétablissement. Le premier exercice est toujours plus long que ce que tout le monde avait estimé.

Quand SMART vous concerne

Les guides qui enseignent smartctl sont corrects, et ils s'appliquent dès que le matériel vous appartient réellement :

• Un serveur dédié ou bare metal, où sudo smartctl -a /dev/sda renvoie la table complète des attributs et smartd peut vous envoyer un e-mail lorsqu'un attribut change.
• Les offres de stockage qui transmettent un disque physique directement à l'invité. Les fournisseurs documentent cela explicitement, car c'est un argument de vente.
• Le matériel que vous possédez, à domicile ou dans un espace de rack que vous louez.
• Un disque derrière un contrôleur RAID, accessible avec sudo smartctl -a -d megaraid,0 /dev/sda, ou un boîtier USB avec -d sat.

Sur du NVMe réel, sudo smartctl -a -d nvme /dev/nvme0 et sudo nvme smart-log /dev/nvme0n1 rapportent critical_warning et percentage_used depuis le disque lui-même. Sur du SATA réel, les attributs qui prédisent une défaillance sont Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) et Reported_Uncorrect (187). Si l'un d'entre eux s'écarte de zéro, planifiez un remplacement. Les études à grande échelle sur les disques aboutissent systématiquement à cette même courte liste, et la plupart des autres attributs ne sont que du bruit.

Exécutez le daemon plutôt que de vérifier manuellement.

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

Le journal d'auto-test doit afficher Completed without error pour l'exécution que vous venez de lancer. Ubuntu et Debian fournissent /etc/smartd.conf avec une ligne DEVICESCAN, à jour en août 2026, afin que le daemon détecte chaque disque visible et envoie un e-mail à root en cas de changement. Rien de tout cela ne fonctionne sur un disque virtuel, ce qui explique pourquoi le reste de ce guide existe.

FAQ

Pourquoi smartctl ne fonctionne-t-il pas sur mon VPS ?

Parce que le disque est virtuel. Sur une instance KVM utilisant virtio-blk, smartctl -a /dev/vda affiche /dev/vda: Unable to detect device type, car un disque paravirtualisé ne dispose pas de canal de commande ATA ou SCSI pour transmettre une requête SMART. Sur un disque émulé, vous accédez à un périphérique dont le modèle indique QEMU HARDDISK, sans aucune donnée SMART exploitable derrière. Dans un conteneur, smartctl est refusé d'emblée par manque de CAP_SYS_RAWIO. Rien de tout cela n'est une erreur de configuration, et aucun flag -d ne peut corriger ces limitations.

Comment savoir si le disque de mon VPS est défaillant ?

Surveillez les effets plutôt que le matériel. Vérifiez sudo journalctl -k -p err -b pour détecter des lignes blk_update_request: I/O error et des Remounting filesystem read-only. Exécutez sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' pour trouver des erreurs que les journaux ont déjà perdues. Suivez les r_await issus de iostat -xdz 5 par rapport à une base de référence enregistrée lorsque le système était sain. Sur un VPS, une erreur d'E/S signifie généralement un problème de stockage sur l'hôte plutôt qu'un disque en fin de vie ; il convient donc d'ouvrir un ticket de support en joignant l'horodatage et le secteur concerné.

Sur quels indicateurs de santé disque dois-je créer des alertes pour un VPS ?

Quatre alertes suffisent. Un montage en lecture seule, détecté via node_filesystem_readonly == 1 ou par une sonde d'écriture qui échoue. L'espace libre et les inodes libres tendant vers zéro. Toute erreur I/O error du noyau survenue lors du dernier intervalle. Un heartbeat du serveur, afin d'être alerté si la machine cesse de répondre. Ignorez tout ce qui provient de SMART, car sur un disque virtuel, ces valeurs sont soit absentes, soit représentatives de l'émulation de l'hyperviseur.

Pourquoi mon système de fichiers a-t-il été remonté en lecture seule ?

ext4 monté avec errors=remount-ro effectue cette opération délibérément lorsqu'il rencontre une erreur de métadonnées : il cesse d'écrire plutôt que de continuer à corrompre les données. Le déclencheur se trouve dans le journal du noyau juste au-dessus de la ligne de remontage, généralement une EXT4-fs error concernant un journal abandonné après qu'un périphérique sous-jacent a renvoyé une erreur d'E/S. Remonter le système en lecture-écriture sans vérifier le système de fichiers masque le symptôme et maintient la cause. Capturez le journal, puis vérifiez le système de fichiers démonté depuis un mode rescue avec e2fsck -fy /dev/vda1.

Puis-je lire les données SMART sur un serveur virtuel ?

Dans certains cas précis, oui. Les serveurs dédiés et bare metal vous fournissent des attributs réels. C'est également le cas des offres de stockage qui transmettent un disque physique directement à l'invité, ainsi que tout hôte dont vous avez la maîtrise. Certaines plateformes présentent un contrôleur NVMe à l'invité et nvme smart-log renvoie un journal ; exécutez donc sudo nvme id-ctrl /dev/nvme0 en premier : un numéro de modèle désignant un service de stockage réseau signifie que ces compteurs proviennent d'un contrôleur logiciel. Et lorsqu'un nœud en passthrough expose des compteurs réels sur une machine partagée, ils décrivent un matériel partagé avec d'autres locataires ; la seule action utile est donc l'ouverture d'un ticket de support.