Solucionar pvestatd.service fallado en Proxmox: Restaurar gráficos y estadísticas rápido

Qué hace realmente pvestatd (y qué no hace)

pvestatd es el demonio de estadísticas de nodo de Proxmox. Su trabajo es recopilar periódicamente métricas (nodo, VMs/CTs, almacenamiento, algunos detalles orientados al clúster) y almacenar series temporales para que la interfaz gráfica pueda dibujar gráficos y mostrar tendencias. No es la propia interfaz y no es un “sistema de monitorización” al estilo Prometheus. Es la tubería que hace que los gráficos integrados funcionen.

En la mayoría de instalaciones, los gráficos se respaldan en archivos RRD (Round Robin Database) bajo /var/lib/rrdcached/db y las actualizaciones se medían por rrdcached para evitar E/S constante en disco. Cuando pvestatd no puede escribir actualizaciones —o no puede hablar con rrdcached, o no puede leer las estadísticas del sistema limpiamente— falla o queda atascado. La interfaz entonces muestra gráficos obsoletos o vacíos, a menudo sin una explicación útil.

Conclusión práctica: cuando desaparecen los gráficos, no te quedes mirando el navegador. Depura pvestatd, rrdcached, la salud del almacenamiento, permisos y sincronización de tiempo. En ese orden.

Una verdad seca: si operas sin datos temporales fiables, manejas producción como un piloto que piensa que los altímetros son “accesorios opcionales”.

Guía de diagnóstico rápido (primero/segundo/tercero)

Primero: confirma el modo de fallo (¿es realmente pvestatd?)

• Revisa el estado del servicio y los registros recientes. Buscas un error claro: permiso denegado, disco lleno, socket ausente, RRD corrupto, salto de tiempo.
• Comprueba si rrdcached está en ejecución y si su socket existe.
• Verifica espacio libre y presión de inodos en el sistema de archivos que contiene los datos RRD.

Segundo: aisla si es la ruta de escritura o de lectura

• Ruta de escritura: ¿podemos actualizar los RRD? ¿Socket? ¿Permisos? ¿Disco? ¿Corrupción?
• Ruta de lectura: ¿pvestatd se bloquea al recopilar estadísticas de backends de almacenamiento (ZFS, Ceph, NFS, iSCSI)? ¿Un único almacenamiento roto detiene todo?

Tercero: confirma implicaciones en el clúster

• En un clúster, verifica si un nodo está enfermo o si todos los nodos están afectados.
• Comprueba sincronización de tiempo y comunicación del clúster. Saltos raros de tiempo pueden hacer que los gráficos RRD parezcan “en plano” o ausentes incluso cuando hay actualizaciones.
• Si usas almacenamiento compartido para RRD (inusual, pero sucede), revisa la salud y latencia del montaje.

No empieces con reinstalaciones. No empieces con eliminaciones aleatorias. Y por favor no “arregles” deshabilitando la recopilación de estadísticas. Eso es como curar una fiebre rompiendo el termómetro.

Datos interesantes y contexto (por qué falla así)

1. RRD se diseñó a finales de los 90 para almacenamiento compacto de series temporales con tamaño fijo, sacrificando detalle por predictibilidad. Genial para gráficos embebidos; no tan bueno para análisis forense profundo.
2. rrdcached existe para reducir la amplificación de escrituras: sin él, las actualizaciones frecuentes de RRD pueden causar muchas escrituras pequeñas síncronas y desgaste innecesario en SSD.
3. Proxmox históricamente confió en RRD para gráficos integrados porque es simple, local y no requiere una pila de monitorización. Esa simplicidad explica por qué está en todas partes—y por qué los fallos sorprenden.
4. Los archivos RRD son binarios y exigentes. Una escritura parcial, disco lleno o error de sistema de archivos puede volverlos ilegibles, y las herramientas suelen reportar “encabezado inválido” en lugar de “tu disco te mintió”.
5. Los saltos de tiempo pueden romper la ilusión de continuidad: RRD consolida datos en cubos; si el tiempo del sistema salta hacia atrás/adelante, los gráficos pueden mostrar huecos o líneas planas sin un error obvio.
6. Los servicios de nodo de Proxmox son unidades systemd. Un único directorio faltante, propiedad incorrecta o dependencia fallida puede empujar a pvestatd a bucles de reinicio que parecen “está funcionando” a simple vista.
7. El renderizado de gráficos no lo hace pvestatd. El demonio solo actualiza datos; la interfaz los consume. La gente suele perseguir el componente equivocado primero (normalmente la interfaz web).
8. Los backends de almacenamiento pueden envenenar la tubería de estadísticas: un montaje NFS atascado, Ceph degradado o comando ZFS lento puede bloquear la recopilación y provocar timeouts y fallos en pvestatd.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas reales que ejecutaría en un nodo con gráficos ausentes y pvestatd fallando. Cada una incluye qué significa la salida y la decisión que tomas a partir de ella. Ejecútalas como root o con los privilegios apropiados.

Tarea 1: Confirma el estado del servicio y la última razón de fallo

cr0x@server:~$ systemctl status pvestatd --no-pager
● pvestatd.service - PVE status daemon
     Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled)
     Active: failed (Result: exit-code) since Tue 2025-12-23 09:11:31 UTC; 2min 10s ago
    Process: 1442 ExecStart=/usr/bin/pvestatd (code=exited, status=1/FAILURE)
Dec 23 09:11:31 server pvestatd[1442]: unable to write rrd: Permission denied
Dec 23 09:11:31 server systemd[1]: pvestatd.service: Failed with result 'exit-code'.

Significado: Tienes un error concreto. No adivines. “Permission denied” apunta firmemente a la propiedad/modo en directorios RRD o al socket de rrdcached.

Decisión: Ve a comprobaciones de permisos (Presión de almacenamiento, permisos) y verificación del socket de rrdcached.

Tarea 2: Lee el journal para contexto (suele mostrar el primer error real)

cr0x@server:~$ journalctl -u pvestatd -b --no-pager -n 200
Dec 23 09:11:30 server pvestatd[1442]: starting server
Dec 23 09:11:31 server pvestatd[1442]: rrdcached: connect to /var/run/rrdcached.sock: No such file or directory
Dec 23 09:11:31 server pvestatd[1442]: can't initialize rrd: No such file or directory

Significado: No es un problema de permisos; falta el socket. Eso es o rrdcached no está en ejecución, o está configurado con otra ruta de socket, o falta el directorio.

Decisión: Comprueba el servicio rrdcached y la ruta del socket.

Tarea 3: Comprueba salud de rrdcached y existencia del socket

cr0x@server:~$ systemctl status rrdcached --no-pager
● rrdcached.service - data caching daemon for rrdtool
     Loaded: loaded (/lib/systemd/system/rrdcached.service; enabled)
     Active: active (running) since Tue 2025-12-23 08:55:02 UTC; 18min ago
   Main PID: 612 (rrdcached)
     Tasks: 1
     Memory: 2.3M
Dec 23 08:55:02 server rrdcached[612]: starting up

cr0x@server:~$ ls -l /var/run/rrdcached.sock
ls: cannot access '/var/run/rrdcached.sock': No such file or directory

Significado: El servicio está en ejecución pero el socket no está en esa ruta. El demonio podría usar una ubicación distinta (común entre diferencias de empaquetado) o fallar al crearlo.

Decisión: Encuentra la ruta real del socket y alinea las expectativas de Proxmox o la configuración del servicio.

Tarea 4: Localiza el socket real de rrdcached y verifica que sea un socket

cr0x@server:~$ ss -xlpn | grep rrdcached
u_str LISTEN 0      4096   /run/rrdcached/rrdcached.sock  12345              * 0    users:(("rrdcached",pid=612,fd=4))

Significado: El socket es en realidad /run/rrdcached/rrdcached.sock. Si pvestatd está codificado o configurado para usar /var/run/rrdcached.sock, hay una incompatibilidad.

Decisión: Confirma cómo está configurado Proxmox para conectarse; corrige ajustando la configuración o creando un enlace simbólico con cuidado.

Tarea 5: Comprueba el symlink esperado (solución habitual)

cr0x@server:~$ ls -ld /var/run
lrwxrwxrwx 1 root root 4 Dec 23 08:40 /var/run -> /run

cr0x@server:~$ ls -l /run/rrdcached/rrdcached.sock
srwxrwxrwx 1 root root 0 Dec 23 08:55 /run/rrdcached/rrdcached.sock

Significado: /var/run apunta a /run. Pero el nombre del socket esperado difiere. A veces Proxmox busca /run/rrdcached.sock mientras que rrdcached usa un subdirectorio.

Decisión: Reconfigura rrdcached para crear el socket donde Proxmox lo espera, o crea un symlink (mejor preferir la configuración, acepta el symlink si sabes lo que haces).

Tarea 6: Inspecciona valores por defecto de rrdcached (socket y directorio base)

cr0x@server:~$ grep -E 'SOCK|BASE|OPTS' /etc/default/rrdcached
SOCKGROUP=www-data
BASE_PATH=/var/lib/rrdcached
DAEMON_OPTS="-l unix:/run/rrdcached/rrdcached.sock -g -w 1800 -z 1800 -f 3600 -j /var/lib/rrdcached/journal/"

Significado: El socket está explícitamente configurado. Proxmox debe hablar con ese socket. Si no puede, falla.

Decisión: Haz que Proxmox use el socket configurado, o configura rrdcached para proporcionar el socket esperado.

Tarea 7: Comprueba espacio en disco e inodos donde viven los RRD (los gráficos mueren cuando el disco está “lleno”)

cr0x@server:~$ df -h /var/lib/rrdcached /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        30G   30G     0 100% /

cr0x@server:~$ df -i /var/lib/rrdcached
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2      196608 196608     0  100% /

Significado: Te quedaste sin espacio y sin inodos. Esto no es “monitorización rota”, esto es “el sistema se está asfixiando”. Las actualizaciones RRD fallan; los demonios se bloquean; otros servicios seguirán.

Decisión: Libera espacio/inodos inmediatamente y luego repara RRD si hace falta. No sigas reiniciando servicios en un sistema de archivos lleno; solo generarás más logs y dolor.

Tarea 8: Identifica qué consumió tu disco (rápido, sin drama)

cr0x@server:~$ du -xhd1 /var | sort -h
120M    /var/cache
380M    /var/lib
1.2G    /var/log
28G     /var

Significado: El uso de disco se concentra en /var. Ahora profundiza en /var/log y /var/lib.

Decisión: Rota/trunca logs descontrolados, limpia cachés, arregla la causa del aluvión de logs. Luego reinicia los servicios de estadísticas.

Tarea 9: Busca tormentas de logs que también causen agotamiento de inodos

cr0x@server:~$ ls -lh /var/log | tail -n 10
-rw-r----- 1 root adm  12G Dec 23 09:10 syslog
-rw-r----- 1 root adm 8.1G Dec 23 09:09 kern.log
-rw-r----- 1 root adm  55M Dec 23 08:50 pveproxy/access.log

Significado: Syslog y kern.log son enormes. Algo está enviando spam. Arreglar pvestatd sin arreglar el spam es como achicar el agua de un barco dejando el agujero abierto.

Decisión: Detén la fuente de spam; rota o trunca los logs con seguridad; recupera espacio. Luego confirma que pvestatd y rrdcached puedan escribir.

Tarea 10: Verifica propiedad y permisos de los directorios RRD

cr0x@server:~$ ls -ld /var/lib/rrdcached /var/lib/rrdcached/db
drwxr-xr-x 5 root root 4096 Dec 23 08:55 /var/lib/rrdcached
drwxr-xr-x 6 root root 4096 Dec 23 08:55 /var/lib/rrdcached/db

Significado: Propiedad root, lo cual a menudo está mal para el modelo de actualización de rrdcached. Dependiendo de tu configuración, rrdcached espera propiedad por el usuario/grupo rrdcached o permisos de grupo específicos para el socket.

Decisión: Comprueba el usuario en ejecución de rrdcached y corrige la propiedad. Evita chmod 777 recursivo como solución; te lo lamentarás después.

Tarea 11: Confirma el usuario de rrdcached y permisos efectivos

cr0x@server:~$ ps -o user,group,pid,cmd -p $(pidof rrdcached)
USER     GROUP    PID CMD
rrdcached rrdcached 612 rrdcached -l unix:/run/rrdcached/rrdcached.sock -g -w 1800 -z 1800 -f 3600 -j /var/lib/rrdcached/journal/

Significado: El demonio se ejecuta como rrdcached. Necesita acceso de escritura a su journal y directorios de BD.

Decisión: Establece la propiedad correcta a rrdcached:rrdcached para /var/lib/rrdcached (si esa es tu configuración) y asegúrate de que los permisos de grupo coincidan con el grupo de acceso del socket si aplica.

Tarea 12: Corrige la propiedad de directorios de forma segura (solo tras confirmar configuración)

cr0x@server:~$ chown -R rrdcached:rrdcached /var/lib/rrdcached
cr0x@server:~$ systemctl restart rrdcached
cr0x@server:~$ systemctl restart pvestatd
cr0x@server:~$ systemctl is-active pvestatd
active

Significado: Los servicios volvieron. Eso es necesario, no suficiente.

Decisión: Confirma que los gráficos se actualizan verificando timestamps de archivos RRD y los registros de pvestatd.

Tarea 13: Valida actualizaciones RRD (los timestamps deberían avanzar)

cr0x@server:~$ find /var/lib/rrdcached/db -type f -name '*.rrd' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | tail -n 5
2025-12-23 09:14 /var/lib/rrdcached/db/pve2-node/server/cpu.rrd
2025-12-23 09:14 /var/lib/rrdcached/db/pve2-node/server/mem.rrd

Significado: Los archivos RRD están siendo tocados. Es una buena señal de que las actualizaciones se reanudaron.

Decisión: Si los timestamps no avanzan, vuelve a depurar la ruta de socket/escritura.

Tarea 14: Detecta corrupción (RRD “invalid header” es la pista)

cr0x@server:~$ rrdtool info /var/lib/rrdcached/db/pve2-node/server/cpu.rrd | head
ERROR: /var/lib/rrdcached/db/pve2-node/server/cpu.rrd: invalid header (bad magic)

Significado: Ese archivo está corrupto. No generará gráfico. pvestatd puede bloquearse al intentar actualizarlo (según el manejo).

Decisión: Reemplaza el RRD corrupto por uno nuevo (pérdida de datos para esa serie) o restaura desde backups si los tienes.

Tarea 15: Identifica cuán extensa es la corrupción

cr0x@server:~$ find /var/lib/rrdcached/db -type f -name '*.rrd' -print0 | xargs -0 -n1 sh -c 'rrdtool info "$0" >/dev/null 2>&1 || echo "BAD $0"' | head
BAD /var/lib/rrdcached/db/pve2-node/server/cpu.rrd
BAD /var/lib/rrdcached/db/pve2-node/server/loadavg.rrd

Significado: Puedes cuantificar el radio de efecto. Si son solo un par de archivos, reemplázalos. Si son cientos, considera reiniciar todo el árbol RRD tras solucionar el problema de disco.

Decisión: Reemplazo dirigido para corrupción limitada; reinicio completo para podrido a gran escala (tras asegurar la salud del sistema de archivos).

Tarea 16: Comprueba sincronización de tiempo (los gráficos pueden “detenerse” porque el tiempo está mal)

cr0x@server:~$ timedatectl
               Local time: Tue 2025-12-23 09:16:02 UTC
           Universal time: Tue 2025-12-23 09:16:02 UTC
                 RTC time: Tue 2025-12-23 06:12:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Significado: NTP está “activo” pero el reloj no está sincronizado y el RTC deriva. Si el tiempo salta, el comportamiento de RRD se vuelve confuso y los gráficos pueden mostrar huecos.

Decisión: Arregla la sincronización de tiempo antes de asumir que las estadísticas están rotas. El tiempo es una dependencia, no una sugerencia.

Tarea 17: Detecta timeouts de backends de almacenamiento que bloquean la recopilación

cr0x@server:~$ journalctl -u pvestatd -b --no-pager | tail -n 20
Dec 23 09:05:11 server pvestatd[1320]: storage 'nfs-archive' status error: timeout waiting for response
Dec 23 09:05:11 server pvestatd[1320]: unable to update storage statistics

Significado: Un único almacenamiento problemático puede romper o retrasar el bucle de estadísticas. Clásico: tus gráficos mueren porque un montaje NFS está colgado, no porque RRD esté roto.

Decisión: Arregla o deshabilita temporalmente la definición de almacenamiento rota; confirma que pvestatd se estabiliza.

Tarea 18: Verifica el estado de almacenamiento de Proxmox desde CLI (sin conjeturas de la UI)

cr0x@server:~$ pvesm status
Name         Type     Status           Total            Used       Available        %
local         dir     active        29454016        10240000        17600000   34.77%
nfs-archive   nfs     inactive              0               0               0    0.00%

Significado: El almacenamiento está inactivo; pvestatd se quejó por ello. Ahora tienes una razón clara.

Decisión: Si es necesario, arregla el montaje/red. Si está retirado, elimínalo de la configuración. Almacenamientos zombis matan las estadísticas.

RRD y rrdcached: reparar, reiniciar y cuándo aceptar pérdida de datos

Entiende las piezas en movimiento

La tubería suele verse así:

• pvestatd recopila valores periódicamente.
• Los envía a rrdcached vía un socket UNIX.
• rrdcached cachea las actualizaciones y las vuelca a archivos RRD.
• La interfaz web de Proxmox lee los datos RRD y genera los gráficos.

Los fallos se agrupan alrededor de:

• Problemas de socket: ruta incorrecta, permisos, demonio caído, archivo socket obsoleto.
• Permisos de directorio/archivo: rrdcached no puede escribir su journal/BD, o pvestatd no puede conectar.
• Disco lleno / inodos agotados: las escrituras fallan; los journals no se pueden volcar; los demonios se bloquean.
• Corrupción RRD: encabezados inválidos, archivos truncados, errores aleatorios de lectura por problemas de almacenamiento subyacente.
• Descontinuidades de tiempo: las actualizaciones parecen “no mostrarse” porque el tiempo del sistema está mal.

Decidir: recuperar vs reiniciar

RRD no es una base de datos transaccional. Si hay corrupción, las opciones son limitadas:

• Pocos archivos corruptos: borra/reemplaza esos archivos y deja que Proxmox los regenere.
• Corrupción a gran escala: reinicia todo el árbol RRD tras arreglar el problema de disco/FS. Acepta perder el historial; recupera la corrección.
• Dispones de backups/snapshots de /var/lib/rrdcached: restaura el directorio (mejor caso).

Parte opinativa: si el host sufrió un incidente de disco lleno o errores de sistema de archivos y ves múltiples RRD corruptos, deja de intentar preservarlos. No quieres gráficos históricos construidos sobre corrupción silenciosa.

Reparación dirigida: reemplaza sólo series corruptas

Tras detener servicios, puedes mover RRDs corruptos a un lugar seguro y permitir la regeneración. Proxmox recreará los RRD faltantes conforme lleguen datos.

cr0x@server:~$ systemctl stop pvestatd
cr0x@server:~$ systemctl stop rrdcached
cr0x@server:~$ mkdir -p /root/rrd-quarantine
cr0x@server:~$ mv /var/lib/rrdcached/db/pve2-node/server/cpu.rrd /root/rrd-quarantine/
cr0x@server:~$ systemctl start rrdcached
cr0x@server:~$ systemctl start pvestatd
cr0x@server:~$ systemctl is-active pvestatd
active

Qué significa esto: Has sacrificado una serie temporal para que vuelvan las actualizaciones. El archivo nuevo se creará; tu gráfico histórico de CPU se reinicia. Está bien. Querías monitorización, no nostalgia.

Reinicio completo: cuando todo está podrido

Si la mayoría de RRDs están corruptos o el árbol BD está destrozado, reinícialo. Pero solo después de arreglar espacio en disco, integridad del sistema de archivos y sincronización de tiempo—si no, volverás a corromper los nuevos.

cr0x@server:~$ systemctl stop pvestatd
cr0x@server:~$ systemctl stop rrdcached
cr0x@server:~$ mv /var/lib/rrdcached/db /var/lib/rrdcached/db.broken.$(date +%s)
cr0x@server:~$ mkdir -p /var/lib/rrdcached/db
cr0x@server:~$ chown -R rrdcached:rrdcached /var/lib/rrdcached
cr0x@server:~$ systemctl start rrdcached
cr0x@server:~$ systemctl start pvestatd

Qué significa esto: Comienzas desde cero. En minutos, los gráficos de la GUI deberían empezar a poblarse. Si no lo hacen, el problema nunca fue “archivos RRD viejos”—es la tubería o sus dependencias.

Chequeo de cordura: ¿podemos hablar con rrdcached?

Una verificación rápida es ver si el socket existe y es escribible por el grupo de usuario del servicio. No siempre puedes “probar escritura” fácilmente sin conocer nombres RRD, pero sí confirmar socket y permisos.

cr0x@server:~$ stat /run/rrdcached/rrdcached.sock
  File: /run/rrdcached/rrdcached.sock
  Size: 0         	Blocks: 0          IO Block: 4096   socket
Device: 0,21	Inode: 12345       Links: 1
Access: (0777/srwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-12-23 08:55:02.000000000 +0000
Modify: 2025-12-23 08:55:02.000000000 +0000
Change: 2025-12-23 08:55:02.000000000 +0000

Qué significa: El socket existe y es ampliamente escribible (quizá demasiado). Si pvestatd sigue quejándose de conectar, puede que use una ruta diferente o un entorno tipo chroot (raro), o el socket se recrea en otra ubicación tras reinicio.

Broma #1: Cuando los gráficos desaparecen, no es “solo la UI”. Es el sistema diciéndote educadamente que se quedó sin paciencia.

Peculiaridades en clúster y multi-nodo

En un nodo independiente, los problemas de pvestatd suelen ser locales: disco, permisos, socket, corrupción. En un clúster, aparecen dos clases extras de dolor:

• Síntomas divididos: un nodo sin gráficos, otro bien, un tercero actualizando intermitentemente.
• Dependencias cruzadas: definiciones de almacenamiento rotas o deriva de tiempo en un nodo pueden crear comportamiento de UI confuso al alternar entre nodos.

Regla de clúster: confirma si el problema es por nodo

Ejecuta comprobaciones de servicio en cada nodo. No asumas que porque la GUI está en blanco en todas partes es “la GUI”. Puede ser caché del navegador, o que todos los nodos compartan la misma causa raíz (por ejemplo, un cambio de endurecimiento aplicado en todos).

cr0x@server:~$ for n in pve1 pve2 pve3; do echo "== $n =="; ssh $n systemctl is-active pvestatd; done
== pve1 ==
active
== pve2 ==
failed
== pve3 ==
active

Significado: Esto es específico del nodo. Deja de buscar una solución mágica para todo el clúster. Compara el uso de sistema de archivos, la configuración de rrdcached y las definiciones de almacenamiento de pve2 con los otros nodos.

La deriva de tiempo en un clúster es un tipo especial de estupidez

A RRD no le gusta que el tiempo vaya hacia atrás. A los servicios de clúster tampoco. Si un nodo deriva, puede mostrar gráficos con huecos y diagnosticarás mal “estadísticas rotas” cuando en realidad es “tiempo roto”.

cr0x@server:~$ chronyc tracking
Reference ID    : 0A0B0C0D (ntp1)
Stratum         : 3
Last offset     : +0.000842 seconds
RMS offset      : 0.001210 seconds
System time     : 0.000311 seconds fast of NTP time
Leap status     : Normal

Significado: El tiempo es estable. Si ves offsets grandes o “Not synchronised”, arregla eso primero.

Las definiciones de almacenamiento rotas afectan la recopilación

La recopilación de estadísticas de Proxmox suele tocar backends de almacenamiento. Un servidor NFS muerto, una ruta iSCSI atascada o un comando Ceph que cuelga pueden causar que pvestatd bloquee o falle.

Tu mejor movimiento: deja pvesm status limpio. Si el almacenamiento está muerto y no es necesario, elimínalo. Si es necesario, arregla el montaje/red. “Inactivo para siempre” no es inofensivo; es una invitación a timeouts de demonios.

Presión de almacenamiento, permisos y por qué los gráficos mueren primero

¿Por qué desaparecen los gráficos temprano en la caída de un host? Porque son intensivos en escrituras y no críticos para mantener las VMs en funcionamiento. El kernel mantendrá encantado tus cargas mientras los servicios en segundo plano fallan silenciosamente al actualizar el historial.

Incidentes de disco lleno: la reacción en cadena

Cuando root se llena:

• rrdcached no puede volcar journals ni actualizar RRDs.
• pvestatd falla al escribir y sale o reintenta con agresividad.
• El logging puede volverse más ruidoso, lo que usa más disco y empeora la situación.
• Eventualmente otros componentes fallan (actualizaciones de paquetes, caches de autenticación, mensajería del clúster).

Si recuerdas una sola cosa: resuelve espacio/inodos antes de cualquier otra cosa. Todas las demás reparaciones dependen de la capacidad de escribir unos pocos kilobytes.

Permisos: el sabotaje silencioso

Los problemas de permisos suelen aparecer después de:

• “Limpiezas” manuales donde alguien ejecutó chown en /var/lib o restauraciones con propiedad incorrecta.
• Scripts de endurecimiento que ajustan /run o cambian umasks por defecto.
• Mover directorios a sistemas de archivos diferentes y perder ACLs o atributos extendidos.

Un buen enfoque de depuración es tratar /var/lib/rrdcached como un directorio de datos de aplicación: necesita propiedad estable, permisos estables y espacio libre estable. Si lo mantienes en el root junto con todo lo demás, apuestas la historia de monitorización a que la rotación de logs nunca falle. Es una apuesta audaz.

Salud del sistema de archivos: si viste corrupción, no ignores el disco

La corrupción RRD suele ser un síntoma, no la enfermedad. Si hubo un evento de energía, un fallo de disco o un crash del host y ahora los RRD están corruptos, deberías al menos revisar logs del kernel por errores de E/S y verificar SMART. Si no, “arreglarás” los gráficos y luego perderás el nodo.

cr0x@server:~$ dmesg -T | egrep -i 'ext4|xfs|btrfs|I/O error|nvme|ata' | tail -n 15
[Mon Dec 23 08:41:12 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Mon Dec 23 08:41:12 2025] Buffer I/O error on device sda2, logical block 1234567

Significado: Tu sistema de archivos tuvo un mal día. Espera corrupción RRD. No borres archivos RRD y sigas adelante; programa una ventana de mantenimiento para reparar el sistema de archivos y validar el hardware.

Aquí va una cita, parafraseando una idea de un referente en fiabilidad: parafraseando la idea — “La esperanza no es una estrategia; construye sistemas que asuman fallos.” — atribuida a Gene Kranz (idea parafraseada).

Tres microhistorias corporativas desde el frente

1) El incidente causado por una suposición errónea: “Es solo la interfaz web”

Escenario: una empresa mediana con un clúster Proxmox que alimenta servicios internos—runners de CI, algunas bases de datos y muchas VMs “temporales” que se volvieron permanentes. Una mañana, los gráficos desaparecieron en el nodo más ocupado. El ingeniero de guardia supuso que era un problema de navegador o una regresión de UI tras actualizaciones. Reiniciaron pveproxy y pvedaemon porque son los servicios más conocidos.

Los gráficos siguieron en blanco. Escalaron a “Proxmox está roto”, abrieron ticket al proveedor y planearon un reboot en rolling de los nodos para “limpiar el estado”. Mientras tanto, el problema real era el filesystem root al 100% porque el trabajo de backup de una VM estaba generando fallos de autenticación cada pocos segundos y la rotación de logs no daba abasto.

Cuando el primer nodo se reinició, volvió más lento de lo habitual. Servicios que necesitaban escribir durante el arranque tuvieron problemas. Algunas VMs no arrancaron automáticamente. De repente el alcance se amplió: ya no eran solo gráficos; era disponibilidad.

Cuando alguien finalmente ejecutó df -h, la solución fue obvia: detener el spam de logs, truncar los logs con cuidado, recuperar espacio, reiniciar rrdcached y pvestatd. Los gráficos regresaron. El reinicio fue la única acción verdaderamente peligrosa tomada, y fue provocada por asumir “los gráficos son cosa de UI”.

Lección sobre suposiciones erróneas: los gráficos son síntoma de la salud de la ruta de escritura. Cuando desaparecen, tu primer instinto debería ser “¿puede este nodo escribir datos de forma fiable?” y no “¿mi navegador tiene caché?”

2) La optimización que salió mal: “Movamos rrdcached a almacenamiento más rápido”

Otra organización, misma dinámica: equipo orientado al rendimiento, muchos SSDs, deseo de mantener root limpio. Alguien decidió mover /var/lib/rrdcached a un dataset ZFS “rápido” con compresión agresiva y montaje algo exótico. Funcionó en pruebas. Incluso lucía mejor en producción.

Después vino el contraefecto. El dataset se incluyó en snapshots/replicación frecuente. Los archivos RRD son pequeños pero numerosos y se actualizan con frecuencia. La sobrecarga de snapshots no fue catastrófica, pero introdujo picos de latencia suficientes durante ventanas de flush para que rrdcached comenzara a quedarse atrás. Aparecieron timeouts ocasionales. Los gráficos se quedaron desactualizados intermitentemente—justo el tipo de problema que hace que desconfíes de la monitorización.

La siguiente “optimización” fue aumentar los intervalos de escritura de rrdcached para reducir la frecuencia de flush. Eso redujo I/O, sí. También aumentó la cantidad de datos perdidos en un apagado no limpio y amplificó el efecto de “gráficos desfasados”. La gente dejó de revisar los gráficos porque no eran puntuales. La monitorización se volvió decorativa.

La solución fue aburrida: mantener /var/lib/rrdcached en un sistema de archivos local y estable con latencia predecible, excluirlo de políticas de snapshot agresivas y aceptar que los datos RRD no son lo bastante valiosos para replicarlos con la misma pasión que los discos de VM.

Lección de optimización fallida: el backend de monitorización debe ser estable y aburrido. La predictibilidad vence a la astucia.

3) La práctica aburrida pero correcta que salvó el día: “Separar /var y aplicar umbrales”

Un tercer equipo había sufrido apagones por disco lleno antes. Hicieron dos cosas poco glamurosas: pusieron /var en un sistema de archivos dedicado con margen y aplicaron alertas en 70% y 85% con política de escalado. No es sexy. No da para charla de conferencia. Simplemente funciona.

Un día, un cambio de red causó fallos de autenticación repetidos para un montaje de almacenamiento, generando un flujo sostenido de logs. El uso de disco subió. La alerta del 70% se disparó y fue reconocida. El de guardia no “lo arregló más tarde”. Investigó inmediatamente porque el runbook lo ordenaba y porque ya habían visto qué pasa después del 90%.

Se resolvió la causa raíz (credenciales y comportamiento de reintento del montaje), y se rotaron logs. pvestatd nunca falló. Los gráficos nunca desaparecieron. Nadie tuvo que adivinar qué pasó después, porque el historial de series temporales permaneció intacto y aburrido.

Lección de lo aburrido que funciona: separa áreas críticas de escritura, alerta temprano y trata la falta de espacio como un incidente de fiabilidad, no como una tarea de mantenimiento.

Broma #2: El espacio en disco es como la política de oficina—si lo ignoras el tiempo suficiente, terminará convocando una reunión con tu CEO.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: La GUI no muestra gráficos; pvestatd “falló”

Causa raíz: coincidencia o falta de ruta del socket de rrdcached.

Solución: Confirma el socket real con ss -xlpn, alinea la configuración en /etc/default/rrdcached, reinicia rrdcached y luego pvestatd.

2) Síntoma: pvestatd registra “Permission denied” al escribir RRD

Causa raíz: propiedad/modo incorrecto en /var/lib/rrdcached o el directorio journal; a veces por restauraciones o cambios manuales.

Solución: Confirma el usuario de rrdcached con ps, aplica el chown -R correcto en /var/lib/rrdcached, reinicia servicios.

3) Síntoma: Los gráficos se detuvieron aunque los servicios muestran “active”

Causa raíz: disco lleno o agotamiento de inodos causando fallos silenciosos en actualizaciones; o rrdcached retrasado con un journal en crecimiento.

Solución: Comprueba df -h y df -i. Libera espacio/inodos. Luego verifica que los timestamps RRD avanzan.

4) Síntoma: Errores tipo “invalid header (bad magic)”

Causa raíz: archivos RRD corruptos, a menudo tras disco lleno o errores de sistema de archivos.

Solución: Poner en cuarentena RRDs corruptos o reiniciar el árbol RRD; investigar la salud del disco/sistema de archivos.

5) Síntoma: pvestatd falla intermitentemente; logs mencionan timeouts de almacenamiento

Causa raíz: Un backend de almacenamiento roto (NFS colgado, rutas iSCSI con problemas, Ceph lento) bloquea la recopilación.

Solución: Usa pvesm status para identificar storages inactivos. Arregla red/montaje o elimina la configuración de almacenamiento muerto.

6) Síntoma: Gráficos muestran huecos o “planos” extraños entre nodos

Causa raíz: deriva de tiempo o NTP no sincronizado; a veces por suspensión/reanudar del host o RTC defectuoso.

Solución: Usa timedatectl y chronyc tracking. Arregla la sincronización de tiempo; evita grandes saltos manuales.

7) Síntoma: Reiniciar pvestatd “lo arregla” brevemente y vuelve a fallar

Causa raíz: Bucle de reinicio que oculta un problema persistente aguas arriba (disco, permisos, timeouts de almacenamiento). Reinicios son analgésicos, no cirugía.

Solución: Lee el journal para encontrar el primer error y resuelve la dependencia. Deja de oscilar; estabiliza.

Listas de verificación / plan paso a paso

Checklist A: Recuperar gráficos en 15 minutos (ruta segura)

1. Comprueba systemctl status pvestatd y journalctl -u pvestatd -b para el primer error real.
2. Comprueba systemctl status rrdcached y confirma el socket con ss -xlpn | grep rrdcached.
3. Verifica espacio libre e inodos: df -h /, df -i /.
4. Si disco/inodos están llenos, libera espacio primero. Para ello, detén la fuente de spam y rota/trunca logs.
5. Verifica que la propiedad de /var/lib/rrdcached coincida con el usuario en ejecución de rrdcached.
6. Reinicia en orden: systemctl restart rrdcached y luego systemctl restart pvestatd.
7. Confirma actualizaciones RRD: revisa timestamps en /var/lib/rrdcached/db.
8. Si aparece corrupción, pon en cuarentena archivos corruptos individualmente. Si son muchos, reinicia el árbol RRD tras asegurar salud del almacenamiento.

Checklist B: Estabilizar y prevenir recurrencias (ruta madura)

1. Asegura que la sincronización de tiempo sea estable: habilita y verifica chrony/systemd-timesyncd; corrige deriva RTC crónica.
2. Asegura que /var tenga suficiente espacio de reserva; considera un filesystem o dataset separado con umbrales de alerta.
3. Audita la rotación de logs. Confirma que no puedas generar logs multi-GB en pocas horas sin alertas.
4. Revisa definiciones de almacenamiento; elimina storages muertos. “Inactivo” debe ser excepcional, no normal.
5. Si viste errores de sistema de archivos, programa mantenimiento: fsck donde corresponda, pruebas SMART, reemplaza medios dudosos.
6. Documenta la ruta del socket rrdcached y permisos. Evita “symlinks misteriosos” que nadie entiende.

Checklist C: Cuando debes reiniciar datos RRD (sin empeorar)

1. Arregla espacio en disco y verifica salud del sistema de archivos primero.
2. Detén pvestatd y rrdcached.
3. Mueve /var/lib/rrdcached/db a otro lugar (no borres inmediatamente).
4. Crea un directorio db fresco con la propiedad correcta.
5. Inicia rrdcached y luego pvestatd.
6. Verifica que aparezcan nuevos archivos RRD y que los timestamps avancen.

Preguntas frecuentes

1) ¿Necesito reiniciar el nodo Proxmox para arreglar pvestatd?

No. Si un reinicio “lo arregla”, probablemente tuviste un problema transitorio de montaje o estado de servicio. Diagnostica la causa subyacente (espacio, socket, permisos, timeouts de almacenamiento) para que no vuelva.

2) ¿Por qué mis VMs están bien pero faltan gráficos?

Porque la tubería de monitorización no es necesaria para que la virtualización funcione. Es una canaria para la salud de la ruta de escritura y dependencias de servicio. Trátala como una advertencia temprana, no como un fallo cosmético.

3) Reinicié pveproxy y todavía no hay gráficos. ¿Por qué?

Porque pveproxy renderiza la UI pero no genera series temporales. Si pvestatd no puede actualizar RRDs, la UI no tiene nada nuevo que mostrar.

4) ¿Un NFS roto puede realmente romper los gráficos del nodo?

Sí. Si la recopilación de estadísticas intenta consultar el estado del almacenamiento y esa consulta se bloquea o agota el tiempo, el bucle puede fallar o retrasarse. Arregla el montaje, la red o elimina definiciones de almacenamiento muertas.

5) ¿Es seguro eliminar archivos RRD?

Es seguro en el sentido de que no romperás VMs. Perderás gráficos históricos de las series borradas. Si los archivos están corruptos, la eliminación/cuarentena suele ser la vía más rápida para recuperar monitorización.

6) ¿Por qué importa la sincronización de tiempo para los gráficos?

RRD agrupa datos por tiempo. Saltos grandes crean huecos o artefactos de consolidación confusos. En clústeres, la deriva de tiempo también causa comportamientos operacionales extraños. Mantén NTP sano.

7) Mi sistema de archivos no está lleno. ¿Qué más causa “Permission denied”?

Propiedad incorrecta por restauraciones, mover directorios o scripts de endurecimiento que cambian umasks o directorios runtime. Confirma el usuario del servicio y la propiedad del directorio. No soluciones con permisos globalmente escribibles.

8) ¿Cómo confirmo que los gráficos se actualizan sin usar la GUI?

Revisa tiempos de modificación en archivos *.rrd bajo /var/lib/rrdcached/db. Si los timestamps avanzan cada pocos minutos, las actualizaciones fluyen. También puedes comprobar que los registros de pvestatd estén en silencio (de forma positiva).

9) ¿Por qué a veces rrdcached está en ejecución pero falta el socket?

Si el directorio del socket no existía al arrancar, o los permisos impidieron la creación, rrdcached puede no exponer el endpoint esperado. Confirma la ruta del socket en la configuración y que el directorio exista y sea escribible.

10) ¿Debería mover los datos RRD a almacenamiento compartido?

Generalmente no. RRD es pequeño y muy intensivo en escrituras; el almacenamiento compartido introduce latencia y modos de fallo. Mantenlo local y aburrido. Si necesitas centralizar métricas, usa una pila de monitorización adecuada en lugar de intentar “clusterizar” archivos RRD.

Próximos pasos para que esto no vuelva a ocurrir

Restaurar los gráficos es la parte fácil. Mantenerlos fiables es el trabajo.

• Haz visible la presión del disco temprano: alerta sobre uso de espacio e inodos mucho antes del 95%.
• Mantén rrdcached predecible: ruta de socket estable, propiedad correcta, evita relocaciones que añadan latencia.
• Limpia definiciones de almacenamiento muertas: no dejes montajes rotos como “inactivos” durante meses.
• Corrige la sincronización de tiempo permanentemente: NTP estable, RTC sensato, sin saltos manuales en producción.
• Si viste corrupción, investiga hardware: no trates errores RRD como una molestia puramente de software.

Si haces eso, pvestatd será lo que debe ser: ruido de fondo que nunca notas. Ese es el mejor tipo de monitorización.