Reinicio pmx50 — observabilidad y alcance — 20 octubre 2026¶
Investigación de solo lectura, coordinada con root. No se ordenó reinicio, reparación, movimiento HA, arranque/parada de invitados, copias, URLs de producto ni sesiones Sablier. Al detectarse el incidente se suspendió la auditoría amplia TLS/tiempo; desde entonces este agente consultó únicamente series y reglas existentes de Prometheus en CT217. Diagnóstico del host/journal a cargo de root; estado de copias/VM208 a cargo del agente correspondiente.
Resultado observado¶
pmx50 reinició con boot_time 20oct00:03:01CEST. El exporter del host estuvo inaccesible unos30s entre muestras; VM208 tardó aproximadamente2min en recuperar los probes de aplicación observados. A00:05:14CEST los probes Wallet por VIP y ambosCaddy vuelven a éxito, cAdvisor208 es accesible y las dos alertas Wallet están inactive. No se acredita recuperación de todos los servicios ni integridad de bases/copias por ese resultado.
Línea temporal de muestras reales¶
Horas Europe/Madrid,20oct. Se extrajeron muestras crudas con el selector de rango de Prometheus; no se interpretan timestamps interpolados como eventos. Resolución de scrape15s: el cambio ocurrió entre la muestra previa y la primera con el valor nuevo, no necesariamente en el milisegundo mostrado.
| Señal | Última muestra correcta | Primera muestra caída | Primera muestra recuperada |
|---|---|---|---|
| node-exporter pmx50 | 00:02:30.323 | 00:02:45.323 | 00:03:15.323 |
| cAdvisor VM208 | 00:02:28.122 | 00:02:43.122 | 00:04:58.122 |
| Wallet backend208 | 00:02:36.428 | 00:02:51.428 | 00:04:36.428 |
| Wallet vía VIP.250 | 00:02:37.355 | 00:02:52.355 | 00:04:37.355 |
| Wallet vía Caddy.40 | 00:02:33.543 | 00:02:48.543 | 00:04:48.543 |
| Wallet vía Caddy.41 | 00:02:33.751 | 00:02:48.751 | 00:04:48.751 |
La primera consulta con query_range/step15s había situado los cambios del host aproximadamente00:02:52→00:03:22; la tabla anterior precisa las muestras reales. node_boot_time_seconds cambió1792436109→1792447381: arranque previo19oct20:55:09CEST, nuevo20oct00:03:01CEST. pmx51 mantuvo up1 y su boot_time1792439931 sin cambio.
A00:04:22: los probes existentes vía VIP/.40/.41 daban HTTP502; el probe directo backend208 devolvía código0. Esto sitúa el fallo observado detrás del frontend: el Caddy secundario sí respondió, pero no podía servir ese backend. No prueba por sí solo qué nodo poseía la VIP ni que se ensayara un failover HA completo.
A00:05:14: backend200 y víaVIP/.40/.41 HTTP401, que es el estado esperado del health-probe de instalación sin credencial. probe_success1 en los cuatro, probe_http_ssl1 en los tres TLS y métricas de expiración nuevamente presentes. TripWalletLocalRouteUnavailable/PublicRouteUnavailable ya inactive; TLSCertExpiringSoon inactive y todas esas reglas healthok. Estas son lecturas de probes ya programados; este agente no emitió sus GET ni llamó al exporter /probe para forzarlos.
Alcance corroborado por el coordinador¶
Root consultó PVE a00:03:50 y comunicó los28invitados running por autostart: VM208uptime13s,PBS18622s,Caddy27028s. pmx51 no había reiniciado. No se repitieron lecturas directas al host50 por este agente. PBS running en PVE es solo estado del invitado; no demuestra salud de PBS, finalización de copias ni restauración.
Root informa que el journal anterior se corta a00:02:14 sin secuencia de shutdown. La causa del bloqueo requiere su diagnóstico del host; Prometheus por sí solo no identifica el mecanismo de reset. La muestra NTP previa 00:02:14 mostraba sincronización/LeapNormal, sin que se cambiara la hora.
Evidencia posterior del host, aportada por root¶
El kernel del arranque00:03:03 informa: Previous system reset reason [0x02000800]:
hardware watchdog timer expired. Esto acredita el mecanismo del reset por
watchdog de hardware, sin identificar por qué el sistema dejó de alimentarlo.
Root verificó SP5100TCO con bootstatus32,timeout10,active,nowayout0. El único FD abierto sobre /dev/watchdog pertenece a watchdog-mux PID1492 y el módulo por defecto es sp5100_tco. nmi_watchdog/hardlockup_panic/softlockup_panic ya estaban activados, watchdog_thresh5 y kexec_crash_loaded1; no se cambiaron en esta ronda.
pstore vacío; /var/crash solo contenía kdump_lock0B y kexec_cmd330B, sin vmcore. El journal anterior termina00:02:14 sin orden de apagado ni warningOOM reciente. Host a00:07:47 llevaba4min y systemstate running. No se hicieron retunings, reinicios de prueba ni acciones de recuperación manual. El agente de diagnóstico separado investiga firmware/captura; este informe no atribuye la causa a RAM, TLS,NTP,temperatura o una mutación concreta sin evidencia.
Historial y hueco verificable de monitorización¶
changes(node_boot_time_seconds{instance="pmx-50.lan:9100"}[24h]) devuelve11. Al expandir el histórico, son saltos de49s a55827s de boot_time, no jitter±1s. Boot_times UTC del19oct:08:40:07,17:13:04,17:19:17,17:23:39,17:24:28,17:30:58, 17:31:49,17:39:28,18:52:30,18:55:09,22:03:01. No se clasifican los11como incidentes inesperados: root debe cruzarlos con mantenimientos/journal.
Las reglas cargadas no consumían node_boot_time_seconds ni node_timex_*. Así, un reinicio breve recuperado puede dejar las alertas de disponibilidad inactive sin conservar una alerta específica de reinicio. Los probes Wallet sí detectaron la ventana y pasaron por pending; a00:05 ya habían recuperado. Propuesta para revisión: una regla warning de arranque reciente para los dos PVE usando la métrica ya existente, con tratamiento explícito de mantenimiento planificado; y otra de pérdida sostenida de sincronización a partir de timex. Después de la revisión se autorizó e implementó la regla de cambio de arranque que se documenta abajo. La propuesta NTP permanece sin implementar. No se enviaron notificaciones ni alertas sintéticas como prueba.
No se deduce disponibilidad de una aplicación de up{job=blackbox}=1: ese up solo acredita la recolección del exporter; el resultado del target está en probe_success/status_code. Tampoco una réplica Caddy mantiene disponible por sí sola el backend alojado en VM208 durante un reinicio de su host.
Límites y siguiente lectura¶
No se han revisado logs/DB de aplicaciones, fsck, SMART, copias ni restauraciones. No hay evidencia aquí de pérdida de datos, pero tampoco validación de integridad post-crash. Continuar con el diagnóstico del host a cargo de root, el estado de copias en el agente asignado y observar las ejecuciones naturales de contratos. No reejecutar trabajos ni despertar productos para mejorar artificialmente la foto de disponibilidad. Datos TLS/NTP previos en night-tls-time-20261020.md.
Alerta de cambio de arranque aplicada tras revisión¶
Fuente: ansible/roles/observability_collector/templates/alerts.yml.j2, grupo
pequeño proxmox_boot, alerta ProxmoxBootTimeChanged,severitywarning,for0m.
Expresión: diferencia entre max/min de node_boot_time_seconds{job="proxmox-nodes"}
en15min superior a30s. No dice «unplanned» ni identifica causa. Ignora jitter1s,
excluye duplicados LXC de otrosjobs y conserva señal durante15min aunque el
servicio vuelva antes de otros umbrales. Sin muestra anterior no puede probar
un reinicio: la disponibilidad/up se evalúa aparte, nunca como OK global.
Pruebas reales con promtool3.15.0 ya instalado, ejecutadas sobre ficheros temporales que no cargó Prometheus ni enviaron alertas: checkrules84correcto, suite nueva4escenarios (evento observado/gap, estable+jitter1s, duplicadoLXC, sin historial con up0) y suite previa térmica/memoria6escenarios, ambasSUCCESS. Los temporales del contenedor se limpiaron al terminar. No se añadió servicio, daemon, canal ni receptor.
Se comparó el render con las83reglas del runtime: mismas reglas/expresiones, labels,for y grupos previos, más una regla nueva. Única diferencia previa admitida por root: texto PBS06:25→07:00, que ya estaba corregido en fuente.
Despliegue selectivo enCT217, con CAS del hash previo, backup0600/dir0700, escritura in-place+fsync conservando el inode1029537 de alerts.yml (bind mount individual), owner/groupmonxas/mode0664, comprobación promtool de archivo y configuración reales y HUP, sin restart. prometheus.yml no se modificó.
| Elemento | SHA256 |
|---|---|
| Fuente antes | <REDACTED> |
| Fuente actual | <REDACTED> |
| Runtime antes | <REDACTED> |
| Render/runtime actual | <REDACTED> |
| prometheus.yml intacto | <REDACTED> |
Backup runtime:
CT217:/root/rollback-proxmox-boot-20261020T221000Z/alerts.yml.before,0600,
directorio0700, hash del runtime previo comprobado. Copias fuente/runtime
previas locales en /tmp/pmx50-boot-rule-20261020/, directorio0700/backup0600.
ReloadConfigSuccesstrue,lastConfigTime22:11:21UTC. Se esperaron dos evaluaciones
distintas:22:11:23.523 y22:11:38.524UTC,84reglas con healthok. La nueva regla
está firing para pmx50 por el evento real; no se simuló evento ni se comprobó
entrega de una notificación. ContainerID sigue
<REDACTED>,RestartCount0,
StartedAt20:00:13UTC, confirmando ausencia de restart.
Rollback selectivo: bajo lock del archivo y CAS de hash actual, reescribir el backup en el mismo inode,fsync,comprobar hash935a...,promtoolcheck y HUP. Conservar owner/group/modo existentes y comprobar dos evaluaciones sanas. No usar rename ni sustituir prometheus.yml,Alertmanager,receivers,claves o hostsPVE. La reversión elimina la detección específica del reinicio. No se ejecutó rollback.
Este cambio observa el síntoma y preserva la señal; no repara la causa del watchdog. No hay commit/push por este agente; publicación a cargo de root.