Hay comandos que no miras nunca hasta que los necesitas. zpool events -v es uno de ellos. No aparece en las guías bonitas de instalación de Proxmox, no queda especialmente bien en una captura y casi nadie lo enseña cuando presume de pool ZFS sano. Pero cuando algo acaba de pasar y no sabes si ha sido un scrub, un cambio de configuración, un fallo temporal o una alarma que ya desapareció, puede darte una pista muy buena.
Yo lo uso como lectura de primera respuesta. No como sentencia final. Si ZFS ha hecho ruido, miro zpool status, miro journalctl, miro Proxmox y luego miro eventos. A veces el evento confirma algo obvio. Otras veces te da una línea temporal que no tenías.
El comando base es este.
| |
La opción -v muestra más detalle. Sin ella, la salida puede quedarse demasiado corta para investigar. Si solo quiero lo último, uso tail.
| |
No cambia nada. Solo lee eventos que ZFS tiene registrados en memoria. Eso lo hace cómodo para usarlo incluso cuando estás en modo prudente.
la captura de este post#
La captura usa una salida saneada. El pool se llama pve-zfs, que es un nombre genérico habitual. Los identificadores no corresponden a mi laboratorio real y no hay rutas, IPs ni hostnames privados.
Esta es la salida saneada que usé para generar la captura:
| |
Aquí no hay drama. Se ve un scrub_start, luego un scrub_finish con errors = 0 y después un config_sync. Eso ya me permite reconstruir una parte de la mañana. Hubo scrub, terminó limpio y ZFS sincronizó configuración después.
Parece poco. Cuando estás diagnosticando algo raro, poco y ordenado es mejor que mucho ruido.
qué es realmente zpool events#
zpool events muestra eventos generados por ZFS. No es un histórico eterno. No es tu sistema de monitorización. No sustituye a backups, alertas ni logs persistentes. Es una cola de eventos que te ayuda a ver qué ha pasado recientemente en ZFS.
Esa limitación es importante. Si reinicias, si limpias eventos o si ha pasado demasiado tiempo, puede que no encuentres lo que buscas. Por eso no lo uso como única fuente de verdad. Lo uso como una linterna rápida.
En una incidencia real suelo mirar en este orden.
| |
La combinación importa. zpool status me dice el estado actual del pool. zpool events me da eventos recientes. journalctl -k me enseña mensajes del kernel que pueden incluir I/O, discos o controladoras. Los logs de Proxmox me ayudan a entender si había tareas, backups o acciones desde la interfaz.
Un solo comando rara vez explica todo. Pero un comando bueno en el momento adecuado te ahorra mucho tanteo.
scrub_start y scrub_finish#
Los eventos de scrub son de los más fáciles de leer.
| |
ZFS empezó un scrub. Bien. No significa que haya un problema, solo que empezó una revisión.
Luego puedes ver algo como esto.
| |
Eso me gusta verlo. errors = 0 no convierte el pool en inmortal, pero sí confirma que ese scrub terminó sin errores detectados. Si justo después alguien te dice que una VM iba lenta a esa hora, ya tienes una posible explicación. Un scrub puede meter carga de disco. No siempre es el culpable, pero lo metes en la cronología.
Aquí es donde mucha gente se lía. Un scrub sano puede degradar rendimiento mientras corre. No porque algo esté roto, sino porque estás leyendo mucho del pool para verificar datos. Si tienes discos modestos y VMs activas, se nota.
Por eso me gusta cruzar eventos con quejas de rendimiento. Si la lentitud empezó a las 08:15 y el scrub empezó a las 08:14, no hace falta invocar espíritus.
config_sync y cambios que parecen invisibles#
config_sync es menos sexy, pero también útil.
| |
Puede aparecer cuando ZFS sincroniza cambios de configuración del pool. Por sí solo no me dice todo. No me cuenta una historia completa. Pero si estoy investigando por qué algo cambió, me da una marca temporal para mirar alrededor.
Después suelo ir a zpool history.
| |
zpool events me dice que hubo un evento. zpool history puede decirme qué comando se ejecutó. Si el cambio vino de una acción humana o de una herramienta, muchas veces aparece ahí. Si vino de una operación interna, igual no hay una explicación tan directa.
La clave es no pedirle a un comando lo que no puede dar. zpool events no es detective privado. Es el vecino que vio pasar un coche a cierta hora. Útil, pero no suficiente para condenar a nadie.
errores de I/O y eventos más feos#
En salidas reales, si hay problemas de disco, puedes ver eventos más desagradables. Fallos de vdev, errores de checksum, dispositivos que desaparecen o eventos relacionados con fault management. No voy a inventar una salida dramática aquí porque prefiero no normalizar copiar y pegar alarmas sin contexto.
Lo que sí hago cuando veo eventos feos es bajar velocidad.
Primero miro estado.
| |
Luego miro kernel.
| |
Después miro discos por identificador, no solo por nombres tipo sda o sdb. Los nombres pueden cambiar. Los seriales y rutas por id suelen ser más seguros para entender qué está pasando.
Y si hay errores reales, no empiezo borrando snapshots ni reiniciando a lo loco. Esa es la clase de reflejo que convierte un aviso recuperable en una tarde de restauraciones.
cuándo limpio eventos con zpool events -c#
Existe este comando.
| |
Limpia eventos previos. Lo uso poco, pero tiene sentido en una investigación controlada. Por ejemplo, si acabo de revisar todo, quiero reproducir una acción concreta y necesito que la salida posterior sea limpia.
El flujo sería algo así.
| |
No lo hago si estoy en medio de una incidencia que todavía no he documentado. Limpiar eventos antes de capturar lo que ha pasado es como borrar la pizarra antes de hacer la foto. Muy ordenado, muy absurdo.
Si vas a limpiar, guarda antes la salida.
| |
En un homelab personal igual parece excesivo. Hasta que un día te preguntas qué narices pasó a las 02:00 y agradeces tener un archivo cutre con la evidencia.
eventos frente a logs persistentes#
Una cosa que no conviene olvidar: zpool events no es mi archivo histórico. Para eso prefiero logs del sistema, monitorización y alguna forma de alertas. En Proxmox, journalctl y las tareas del nodo suelen dar bastante contexto. Si tienes Prometheus, Grafana o alertas de SMART, mejor.
zpool events brilla en el momento cercano al incidente. Acaba de pasar algo, entras por SSH, quieres una lectura rápida de ZFS. Ahí funciona muy bien.
Para mirar la semana pasada, no me fiaría solo de esto. Buscaría en logs persistentes y en el historial de Proxmox. Si tengo una alerta de monitorización con hora exacta, uso esa hora para recortar journalctl.
| |
No hace falta complicarse. Hora concreta, logs concretos, menos ruido.
cómo lo meto en mi checklist de storage#
Mi checklist corto cuando ZFS hace algo raro en Proxmox queda así.
| |
No siempre ejecuto todo. Si el primer comando ya muestra un disco degradado, voy por ahí. Si el pool está sano pero hubo una queja de rendimiento, miro eventos y iostat. Si el problema coincide con un scrub, ya tengo una explicación candidata.
Lo importante es tener una ruta. Cuando no tienes ruta, empiezas a abrir pestañas, mirar dashboards y tocar cosas sin método. Es muy humano. También es una forma bastante eficiente de liarla.
un caso típico de homelab#
Situación: una VM se pone lenta durante media hora. La web de Proxmox no muestra nada escandaloso cuando miras, porque llegas tarde. La VM ya va normal. Nadie sabe si fue disco, CPU, backup o magia negra.
Yo haría esto.
| |
Si veo un scrub que empezó justo antes y terminó cuando volvió la normalidad, ya tengo una pista fuerte. Si veo eventos de dispositivo, subo la prioridad. Si no veo nada en ZFS, dejo de culpar al pool y miro Proxmox tasks, backups, red o la propia VM.
Esa última parte es importante. Un buen diagnóstico también sirve para descartar. No todo problema raro en un nodo Proxmox es ZFS. A veces ZFS está tranquilamente haciendo su trabajo y nosotros estamos buscando culpable porque nos molesta no entender la causa en treinta segundos.
qué no haría al ver eventos#
No reiniciaría el nodo como primera medida. Reiniciar puede ocultar síntomas y cerrar la ventana para ver eventos recientes. A veces hace falta, pero no debería ser el reflejo inicial.
No reemplazaría discos solo porque aparece una línea que no entiendo. Primero leo zpool status -v, SMART y kernel logs.
No borraría snapshots pensando que todos los problemas de ZFS vienen de snapshots. Los snapshots pueden afectar espacio y gestión, sí. Pero convertirlos en culpable universal es pereza técnica con camiseta de diagnóstico.
Y no limpiaría eventos sin guardarlos si el incidente importa. Es una tontería pequeña, pero duele cuando luego quieres reconstruir la secuencia.
mi lectura rápida#
Cuando abro zpool events -v, busco esto.
- Eventos de scrub y horas exactas
- Errores asociados a dispositivos o vdevs
- Cambios de configuración cerca del problema
- Eventos repetidos que indiquen algo intermitente
- Relación temporal con quejas de rendimiento o tareas de Proxmox
No busco una novela. Busco pistas. Si encuentro una, tiro del hilo con comandos más específicos.
cierre#
zpool events -v es una herramienta pequeña, pero muy útil cuando estás cerca del momento del fallo. En Proxmox me ayuda a reconstruir qué hizo ZFS antes de que yo llegara con cara de sospecha. A veces confirma que todo fue un scrub. A veces apunta a un disco. A veces no dice nada, y eso también sirve para dejar de culpar al storage.
Lo mejor que puedes hacer con ZFS cuando algo huele raro es mirar antes de tocar. zpool events -v encaja justo ahí. No arregla el problema, pero te pone una linterna en la mano. Y en un homelab, muchas noches eso ya es media victoria.