Monitorear salud de disco en VPS sin SMART

Qué puede ver realmente la monitorización del estado del disco en un VPS

La monitorización del estado del disco en un VPS comienza con un hecho que la mayoría de las guías omiten: el disco no es suyo. Su sistema invitado ve un dispositivo de bloques virtual. La unidad física, y cada contador almacenado en ella, pertenece al host. smartctl /dev/vda no falla porque haya escrito mal el comando. Falla porque nada detrás de ese dispositivo puede responder a la pregunta.

SMART (tecnología de auto-monitorización, análisis y notificación) es una tabla de contadores mantenida en la propia unidad: sectores reasignados, sectores pendientes, horas de encendido y errores de soporte. Leer esa tabla requiere una ruta para que los comandos ATA o NVMe (memoria no volátil exprés) lleguen al hardware real. Un disco paravirtualizado no proporciona dicha ruta, por lo que el invitado obtiene almacenamiento sin telemetría.

Un inquilino monitoriza los efectos, no el hardware. Desde el interior del invitado son visibles cuatro señales: errores de E/S (entrada/salida) en el registro del kernel, un sistema de archivos que se remonta como de solo lectura, latencia que aumenta progresivamente y falta de espacio. Se puede configurar alertas para las cuatro señales hoy mismo, y las cuatro aparecen antes de que un usuario se queje. Configure esto primero. La división de responsabilidades llega al final, ya que determina dónde debe invertir sus esfuerzos.

Compruebe lo que expone su propio servidor

No asuma en qué caso se encuentra. Observe y luego lea la sección que corresponda.

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

virtio-blk, el disco habitual de KVM (kernel-based virtual machine). El dispositivo es /dev/vda y smartctl se detiene antes de enviar nada:

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

virtio-blk es un transporte paravirtualizado sin un conjunto de comandos ATA o SCSI detrás, por lo que no existe un canal para transmitir una solicitud SMART. -d sat y -d scsi fallan de la misma manera, porque el problema es el transporte y no el flag.

Un disco SATA o SCSI emulado. El dispositivo es /dev/sda y smartctl llega lo suficientemente lejos como para identificarlo. La línea del modelo indica QEMU HARDDISK. Esa cadena responde a la pregunta por sí misma: está leyendo un dispositivo inventado por el emulador, el cual no reporta ninguna capacidad SMART utilizable.

Un espacio de nombres NVMe. sudo nvme smart-log /dev/nvme0n1 devuelve un registro completo, que es donde la gente se confunde. Compruebe primero la identidad del controlador con sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Un número de modelo que nombra un producto de almacenamiento en red significa que el controlador es software, por lo que percentage_used y media_errors describen esa emulación en lugar de la memoria flash bajo sus datos. Si desea saber qué es realmente su almacenamiento, verifique el disco NVMe en Linux en lugar de confiar en la descripción del plan.

Un contenedor, como LXC (Linux containers) u OpenVZ. Usted no posee un dispositivo de bloques propio. lsblk muestra los dispositivos del host o nada en absoluto, y smartctl es rechazado porque el contenedor no posee CAP_SYS_RAWIO:

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

Una advertencia sobre el caso en el que sí funciona. Si smartctl en un VPS devuelve una tabla de atributos completa, lea el número de serie antes de actuar al respecto. Algunos hosts exponen un nodo de dispositivo mediante passthrough, y esos contadores pertenecen a hardware compartido por todos los inquilinos en esa máquina. Un valor creciente en Reallocated_Sector_Ct es motivo para abrir un ticket de soporte. No es una declaración sobre sus datos.

Señal 1: errores de E/S en el registro del kernel

Esta es la señal de mayor valor que tiene un inquilino y no requiere ningún agente.

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 petición fallida desde el disco virtual tiene este aspecto:

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

La capa de bloques solicitó una escritura al host y este devolvió un error. En un VPS, esto rara vez se debe a una celda flash defectuosa. Por lo general, se trata de la capa de almacenamiento del host o de la ruta de red hacia el almacenamiento conectado en red, por lo que es un evento del lado del proveedor. Copie la marca de tiempo, el nombre del dispositivo y el sector en su ticket, ya que son los datos que el equipo de almacenamiento puede contrastar con sus propios registros.

La secuencia de ext4 que más importa es este par:

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

La segunda línea es la que causa problemas, porque la máquina permanece encendida. Responde a ping, responde a SSH y cada escritura falla. Una comprobación HTTP simple sigue pasando mientras su aplicación lanza un error en cada petición.

XFS, en cambio, desmonta el sistema de archivos:

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 lee solo el arranque actual a menos que el diario se almacene en el disco, y muchas imágenes incluyen un diario volátil que reside en la RAM. Active la persistencia o la evidencia desaparecerá exactamente en el reinicio que realizará mientras soluciona el problema.

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

Después de su próximo reinicio, journalctl --list-boots debería listar más de un arranque. Incluso con la persistencia activada, un sistema de archivos que ha pasado a modo de solo lectura no puede registrar lo que sucedió después, lo cual es el argumento más sólido para enviar los registros fuera del servidor.

Señal 2: detectar un remontaje de solo lectura

Haga que el fallo sea evidente antes de intentar detectarlo.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Busque errors=remount-ro en las opciones. Las imágenes en la nube de Ubuntu y Debian lo definen en /etc/fstab, por lo que un error de metadatos deja el sistema de archivos en modo de solo lectura en lugar de continuar sobre un daño. Si falta, añádalo a la entrada raíz en /etc/fstab, o establézcalo en el superbloque con sudo tune2fs -e remount-ro /dev/vda1. Una detención ruidosa es preferible a una corrupción silenciosa.

Un flag de montaje no es una prueba definitiva. Compruebe mediante escritura:

touch /var/tmp/.disk-probe

En una raíz de solo lectura, esto imprime exactamente:

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

Utilice /var/tmp, no /tmp. En la mayoría de las imágenes, /tmp es un tmpfs alojado en memoria, por lo que una escritura exitosa allí no prueba nada sobre su disco.

Combine la prueba de escritura con una comprobación de espacio y envíe un latido (heartbeat) solo cuando todas las comprobaciones sean correctas:

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 en esa última línea significa que toda la cadena funciona. set -eu hace que cualquier comprobación fallida termine con un código distinto de cero antes de que se ejecute la línea curl, por lo que no se envía ningún latido. Esa inversión es el objetivo: el monitor se vuelve rojo porque no llegó nada, y no se puede confiar en que un servidor que no puede escribir describa su propio problema. Las lecturas siguen funcionando en un sistema de archivos de solo lectura, por lo que el script se inicia correctamente.

Ejecútelo desde un timer de 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 debería mostrar la unidad con un tiempo NEXT inferior a cinco minutos. Una ejecución fallida aparece en journalctl -u disk-probe.service con el propio texto de error del shell, por lo que puede distinguir un sistema de archivos de solo lectura de uno lleno sin necesidad de iniciar sesión.

Esa URL de envío es un monitor de tipo Push de Uptime Kuma. Cree un monitor de tipo Push, copie su token en el script y establezca el intervalo de latido del monitor un poco más largo que el intervalo del temporizador para que una ejecución lenta no le envíe una alerta a las 03:00. Si aún no tiene una página de estado, una instancia de Uptime Kuma autohospedada es el lugar más económico para colocar esta comprobación.

Dos límites honestos. La sonda confirma que se aceptó una escritura, no que los bytes llegaron al almacenamiento duradero, ya que la lectura posterior puede servirse desde la caché de páginas. Además, se ejecuta en la misma máquina que supervisa, por lo que un servidor totalmente bloqueado se quedará en silencio en lugar de informar un diagnóstico.

Señal 3: tendencias de latencia y rendimiento

sudo apt install -y sysstat
iostat -xdz 5 3

Lea primero r_await y w_await. Son los milisegundos promedio que tomó una lectura o una escritura, incluyendo el tiempo de espera en la cola. A continuación, lea aqu-sz, el número promedio de solicitudes en curso. Ignore %util en un disco virtual: solo significa que la cola no estaba vacía, y un dispositivo que atiende muchas solicitudes en paralelo se sitúa cerca del 100 por ciento sin estar cerca de su límite. await es el número que registra lo que perciben los usuarios.

Los valores absolutos importan menos que su propia línea base, así que registre una hora de baja actividad y consérvela. /proc/diskstats es la fuente original si prefiere recopilar los contadores usted mismo.

Para una medición deliberada:

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

Lea el bloque clat percentiles, en particular el percentil 99. --direct=1 omite su caché de página. No omite la caché del host, por lo que el resultado describe todo el camino desde su proceso hasta el almacenamiento de la plataforma. Ejecútelo mientras el servidor esté inactivo, ya que compite con su propia carga de trabajo.

Un aumento en await sin errores en el registro del kernel generalmente no indica una unidad defectuosa. Es contención en el host, la versión de almacenamiento de tiempo de robo de CPU de un vecino ruidoso. Si ocurre a la misma hora todos los días y su ticket de soporte no reporta problemas, la solución es un plan cuyo I/O no se comparta de la misma manera, que es el caso de un VPS de almacenamiento frente a un VPS regular cuando la carga de trabajo depende del disco.

Señal 4: comprobaciones del sistema de archivos que puede ejecutar mientras está montado

ext4 mantiene un contador de errores en el superbloque, el cual sobrevive a los reinicios incluso cuando sus registros ya no existen.

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

Un sistema de archivos saludable muestra Filesystem state: clean y FS Error count: 0. clean with errors y un contador distinto de cero significan que el kernel encontró un error de metadatos en algún momento, incluso si nadie lo notó y el registro ha sido sobrescrito. Ese comando debería formar parte de una revisión semanal.

No puede ejecutar fsck en un sistema de archivos raíz montado, y e2fsck -n en un sistema de archivos activo informa de problemas que solo son datos cambiando mientras se leen. Para forzar una comprobación real, añada fsck.mode=force fsck.repair=yes a la línea de comandos del kernel para un arranque desde la consola de su proveedor. systemd-fsck ejecutará entonces la comprobación antes de que la raíz se monte en modo lectura-escritura.

XFS no tiene comprobación en línea. xfs_repair -n /dev/vda1 se niega a ejecutarse contra un sistema de archivos montado, por lo que debe hacerse en modo de rescate. XFS compensa esto siendo explícito: detiene el sistema de archivos ante un error de metadatos en lugar de continuar.

En Btrfs, los contadores están integrados y son persistentes.

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

write_io_errs o corruption_errs por encima de cero indican un evento real, y los contadores mantienen sus valores tras los reinicios hasta que usted los restablezca. scrub vuelve a leer cada bloque y verifica su suma de comprobación, lo cual es lo más parecido a una prueba de medios disponible en un disco virtual. Consume muchos recursos de E/S, así que prográmelo para una hora de baja actividad.

Señal 5: espacio libre, incluyendo las partes que oculta df

Quedarse sin espacio inutiliza un servidor igual que un disco defectuoso, y ocurre con mucha más frecuencia.

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

No space left on device mientras que df -h muestra espacio libre significa que se han agotado los inodos en lugar de los bytes, y df -i muestra IUse% al 100 por ciento. Millones de archivos pequeños en un directorio de caché o en una cola de correo provocan esto, y eliminar archivos grandes no ayuda.

El espacio que no se recupera tras una eliminación suele ser un archivo borrado que un proceso en ejecución mantiene abierto. sudo lsof +L1 lista los archivos cuyo contador de enlaces ha llegado a cero. Reiniciar el proceso que mantiene uno de ellos libera el espacio.

El diario es un consumidor silencioso habitual. journalctl --disk-usage informa de lo que contiene. Limítelo con SystemMaxUse=200M en /etc/systemd/journald.conf seguido de sudo systemctl restart systemd-journald, y recupere el espacio ahora con sudo journalctl --vacuum-size=200M.

Un caso parece un error pero no lo es. En almacenamiento host con aprovisionamiento ligero (thin provisioning), el pool del host puede llenarse mientras su df sigue mostrando gigabytes libres. Sus escrituras fallan entonces con errores de E/S en el registro del kernel sin ninguna advertencia de espacio dentro del invitado. Los errores sin un sistema de archivos lleno son una combinación que merece un ticket en la misma hora.

Conexión de las señales a un agente de métricas

Una sonda de tipo push responde sí o no. Las tendencias requieren un agente de métricas, y node_exporter de Prometheus ya exporta todo lo anterior sin configuración adicional. Los nombres de las métricas sobre las que trabajar son:

• node_filesystem_readonly pasa a 1 cuando un punto de montaje es de solo lectura, lo cual es su alarma de remontaje.
• node_filesystem_avail_bytes y node_filesystem_files_free cubren bytes e inodos por separado.
• node_disk_io_time_seconds_total y node_disk_read_time_seconds_total proporcionan el tiempo de ocupación y la latencia como contadores que puede graficar.

Dos reglas detectan los casos que realmente generan alertas:

- 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 segunda regla se activa cuando la tendencia actual llega a cero en un plazo de cuatro días, por lo que recibe la advertencia con días de antelación en lugar de al 95 por ciento de capacidad, cuando solo dispone de minutos.

Responsabilidades de cada parte

Su proveedor es el propietario de los discos físicos. Ellos leen los datos SMART, gestionan el array y reemplazan los discos con sectores reasignados en aumento, generalmente sin avisarle, ya que el array absorbe el fallo. Para eso sirve RAID 10 en su VPS: un disco muerto se convierte en una reconstrucción en lugar de una interrupción del servicio. Usted no puede ver nada de esto, y pagar por esa abstracción es el objetivo principal de alquilar un servidor virtual.

Usted es el propietario de sus datos, y la telemetría del disco no los protegería de todos modos. Los eventos que realmente destruyen los datos de un cliente son un rm por error, un despliegue defectuoso, un intruso con su clave SSH y un incidente en la plataforma que arrastra al array consigo. Los atributos SMART no predicen ninguno de estos casos.

Por lo tanto, la protección real de un cliente es una copia de seguridad que resida fuera del servidor y una restauración que usted mismo haya realizado. Las instantáneas (snapshots) del proveedor son convenientes, pero residen en la misma plataforma que el elemento que protegen; por eso las instantáneas y las copias de seguridad son protecciones diferentes. Programe un ejercicio: una vez al trimestre, restaure la copia de seguridad más reciente en un VPS nuevo, inicie la aplicación y anote cuánto tiempo le llevó. Esa cifra es su tiempo real de recuperación. El primer ejercicio siempre es más lento de lo que cualquiera habría estimado.

Cuándo se aplica SMART en su caso

Las guías que enseñan smartctl son correctas y se aplican en el momento en que el hardware es realmente suyo:

• Un servidor dedicado o bare metal, donde sudo smartctl -a /dev/sda devuelve la tabla completa de atributos y smartd puede enviarle un correo cuando un atributo cambia.
• Planes de almacenamiento que pasan un disco físico directamente al invitado. Los proveedores documentan esto explícitamente porque es un argumento de venta.
• Hardware que usted posee, en casa o en un espacio de rack que alquila.
• Un disco detrás de una controladora RAID, accesible con sudo smartctl -a -d megaraid,0 /dev/sda, o una carcasa USB con -d sat.

En NVMe real, sudo smartctl -a -d nvme /dev/nvme0 y sudo nvme smart-log /dev/nvme0n1 informan de critical_warning y percentage_used desde la propia unidad. En SATA real, los atributos que predicen fallos son Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) y Reported_Uncorrect (187). Que cualquiera de ellos deje de ser cero significa que debe planificar un reemplazo. Los estudios de unidades a gran escala siguen señalando esa misma lista corta, y la mayoría de los demás atributos son ruido.

Ejecute el daemon en lugar de comprobarlo manualmente.

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

El registro de autodiagnóstico debería mostrar Completed without error para la ejecución que acaba de iniciar. Ubuntu y Debian incluyen /etc/smartd.conf con una línea DEVICESCAN, vigente a agosto de 2026, por lo que el daemon detecta cada disco que puede ver y envía un correo a root ante cualquier cambio. Nada de esto funciona en un disco virtual, que es la razón por la que existe el resto de esta guía.

FAQ

¿Por qué smartctl no funciona en mi VPS?

Porque el disco es virtual. En un invitado KVM que utiliza virtio-blk, smartctl -a /dev/vda imprime /dev/vda: Unable to detect device type, ya que un disco paravirtualizado no dispone de un canal de comandos ATA o SCSI por el cual enviar una petición SMART. En un disco emulado, usted accede a un dispositivo cuyo modelo se identifica como QEMU HARDDISK, sin datos SMART utilizables detrás. Dentro de un contenedor, smartctl es rechazado directamente por falta de CAP_SYS_RAWIO. Ninguno de estos casos es una mala configuración y ninguna bandera -d los soluciona.

¿Cómo sé si el disco de mi VPS está fallando?

Observe los efectos en lugar del hardware. Revise sudo journalctl -k -p err -b en busca de líneas blk_update_request: I/O error y de Remounting filesystem read-only. Ejecute sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' para encontrar errores que los registros ya hayan perdido. Rastree r_await desde iostat -xdz 5 comparándolos con una línea base que registró cuando el sistema funcionaba correctamente. En un VPS, un error de E/S suele significar un problema de almacenamiento en el host y no un disco que está muriendo, por lo que debe reportarse mediante un ticket de soporte incluyendo la marca de tiempo y el sector afectado.

¿Sobre qué debo configurar alertas para la salud del disco del VPS?

Cuatro alertas cubren este aspecto. Un montaje de solo lectura, detectado mediante node_filesystem_readonly == 1 o una prueba de escritura que falla. El espacio libre y los inodos libres tendiendo a cero. Cualquier I/O error del kernel en el último intervalo. Un latido (heartbeat) del servidor, para que el silencio le avise cuando la máquina deje de responder. Ignore cualquier métrica derivada de SMART, ya que en un disco virtual esos valores no existen o describen la emulación del hipervisor.

¿Por qué mi sistema de archivos se volvió a montar como solo lectura?

ext4 montado con errors=remount-ro hace esto deliberadamente cuando encuentra un error de metadatos: detiene la escritura en lugar de continuar sobre un daño. El disparador se encuentra en el registro del kernel justo encima de la línea de remontaje, generalmente un EXT4-fs error sobre un diario abortado después de que el dispositivo subyacente devolviera un error de E/S. Remontar como lectura-escritura sin verificar el sistema de archivos oculta el síntoma y mantiene la causa. Capture el registro, luego verifique el sistema de archivos desmontado desde el modo de rescate con e2fsck -fy /dev/vda1.

¿Puedo leer datos SMART en un servidor virtual en algún caso?

En casos específicos, sí. Los servidores dedicados y bare metal le proporcionan atributos reales. También lo hacen los planes de almacenamiento que pasan un disco físico directamente al invitado, y cualquier host que usted mismo administre. Algunas plataformas presentan un controlador NVMe al invitado y nvme smart-log devuelve un registro, así que ejecute sudo nvme id-ctrl /dev/nvme0 primero: un número de modelo que nombre un servicio de almacenamiento en red significa que esos contadores provienen de un controlador de software. Y donde un nodo con passthrough exponga contadores reales en una máquina compartida, estos describen hardware compartido con otros inquilinos, por lo que la única acción útil es abrir un ticket de soporte.