Skip to content

Auditoría de capacidad, térmica y estabilidad — 19 octubre 2026

Revisión autorizada por Ramon y coordinada con agentes. Lecturas SSH 23:02–23:05 CEST sin stress, scrub, test SMART, reinicios, migraciones, cambios RAM ni despertar equipos. Cambios locales de monitorización preparados por este agente; el coordinador realiza su revisión y despliegue. No se declara aplicado por el mero cambio local.

Hallazgo nuevo prioritario: térmica de pmx 51

  • /proc/cmdline incluye thermal.off=1; persiste en /etc/default/grub.d/99-thermal-off.cfg con GRUB_CMDLINE_LINUX_DEFAULT="thermal.off=1". Nacimiento/mtime 1 agosto 2026,16:58 CEST.
  • Kernel del arranque 21:58:55 confirma ACPI: thermal: thermal control disabled. La documentación del kernel define el parámetro como desactivación del control térmico ACPI. Esto no demuestra que se hayan desactivado las protecciones térmicas de hardware del procesador.
  • Sensores de CPU 78–81°C durante las muestras; core_throttle_countCPU 0 aumenta: 155967 a 23:02:37 →156330 a 23:03:13, +363 en 36 s. Exporter confirma el contador package 156336 poco después, junto a temperatura 81°C. No se atribuyen todos los eventos a esa temperatura puntual: la señal de limitación puede tener otra causa.
  • Sensor acpi_fan responde N/A e I/Oerror; no prueba un ventilador físicamente parado. Gobernador powersave, frecuencia instantánea~2,8 GHz. Los trips ACPI publicados están entre 103,05 y 110,05°C; no se consideran umbrales operativos seguros nuevos.
  • No hay motivo documentado del parámetro en las fuentes revisadas, historial Git deinfra/docs ni memoria local. Otra sesión conserva el mismo cmdline, sin explicar su introducción. No retirar un posible workaround antiguo ni reiniciar a ciegas.

Acción concreta siguiente: comprobar físicamente giro/ruido, rejillas y flujo de aire, polvo y contacto/disipación con equipo fuera de servicio si necesita apertura. Buscar antecedente del cambio 1 agosto; preparar recuperación del fichero GRUB antes de una ventana donde se pueda restaurar la consola local. Solo entonces evaluar restablecer control ACPI y comprobar temperatura, contador y estabilidad bajo carga habitual; este informe no ordena un stress ni reproduce el cambio de arranque.

RAM y presupuesto N-1: sin nuevo recorte

Muestra 23:02 CEST:

Medida pmx 50 pmx 51
Mem Total Mi B 29177 31875
Mem Available Mi B 13877 13752
Swap usada Mi B 186 0
PSI memoria full 300 0% 0%
ARC actual aproximado Mi B 1157 2106
ARC máximo Mi B 1536 3984
memory_throttle_countZFS 0 0

normalidad23:02 devuelve NORMAL:14 HAstarted,14 réplicas OK,quórum 3, parejas Caddy/DNSactivas y 28 invitados con copia PBS<26 h. Sin embargo 10 HA migrables consumen 10770 Mi B RAM+swap y el destino tiene 13646 Mi B disponibles; tras reserva 2048 Mi B el margen es +828 Mi B, sin crédito balloon. Sigue estrecho para picos. Los límites migrables son 19328 Mi B; lectura actual no acredita capacidad simultánea de esos máximos. Exclusiones estrictas 110/172/217/218 y recursos sin HA permanecen como ya documentó la revisión anterior.

VM 208 21:03:08 UTC: disponible 2445 Mi B, swap 3476 Mi B, PSI memoria full 10=1,49%, full 300=0,33%; IO full 10=7,83%, full 300=6,73%. No OOM. El host mantiene PSImemoria 0 y sus contadorespswpin/out no aumentaron entre las dos lecturas; no confundir su estado con el del invitado. La copia sigue pudiendo presionar al invitado aunque el host esté holgado. No reducir más RAM ahora ni cambiar ARC para fabricar margen; conservar seguimiento y procedimiento degradado existente.

Almacenamiento y estabilidad

  • Ambos pools ONLINE, cero READ/WRITE/CKSUM, sin errores de datos conocidos. pmx 50:854 Gi B total,~649 Gi B asignados,76%ocupación,75%fragmentación; pmx 51:222 Gi B,129 Gi B,57%ocupación,56%fragmentación. Fragmentación no justifica borrar snapshots ni ejecutar scrub. pmx 50 tiene ~178 Gi B disponibles a nivel ZFS, distinto de~205 Gi BFREE físico del pool.
  • /pmx 50:17%,75 Gi B libres; pmx 51:41%,22 Gi B libres. PBS ocupa 301 Gi B en su dataset; la proyección y reserva ya tienen propietario en el trabajo de copias. No se duplicó su sistema de monitorización.
  • SMART pasivo de los tres discos PASSED. NVMe 50:41°C,10%used, media/data integrityerrors 0;72 unsafe shutdowns históricos.427 errorentries: entrada reciente Invalid Field in Command, no error de integridad de medio. King Dian 51:40°C,0 sectores pendientes/reasignados/no corregibles/CRC, vida restante declarada 94%; VICK:33°C y sin fallo SMART. Valoresvendor no sustituyen prueba de restauración ni certifican hardware sano.
  • pmx 50 arranca 20:55:11 CEST y llevaba~2 h 7 m encendido. Causa previa reportada hardware watchdog timer expired; sin volcado en /var/crash ni pstore. Kernel 7.0.14-19,APSToff,max_cstate 1 yboost 0 permanecen. Kdumpready y journal-stream/pulso-tx activos. Sin nuevo MCE/OOM/timeout NVMe/error IO en el journal del arranque consultado. Dos horas sin fallo no resuelven los cuelgues.
  • pmx 50 CPU~51,5°C,DIMM 50,8/51°C; no reproduce los máximos históricos 89°C. No se reintentó UMA 512 M ni se alteró BIOS. El diagnóstico físico de 50 y un memtest completo fuera de servicio siguen pendientes tras asegurar las copias.

Corrección de monitorización preparada

Fuente mantenida: ansible/roles/observability_collector/templates/alerts.yml.j2.

  1. HighMemoryUsage y LowMemoryAvailable conservan nombres, umbrales y tiempos; usan Mem Available directo. La fuente seguía sumando todo ARC como crédito adicional, pudiendo ocultar disponibilidad baja; se alinea el criterio con normalidad.
  2. Grupoproxmox_thermal: aviso si package-throttle>6 eventos/min sostenido 10 m; aviso CPU>=85°C sostenido 10 m. Usa métricas nativas ya recogidas, sin cron/daemon ni activar colector nuevo. Agrupa porhost y filtra jobproxmox-nodes: los exporters LXC exponen countersdel mismohost y no deben duplicar avisos. Chips CPU concretos contrastados en Prometheus 217. No alerta missing por asumir que AMD exporta el contador Intel, ni usa DIMM/NVMecomo CPU.
  3. Render fallaba por cuatro expresiones Prometheus sin escape Jinja, corregidas sin cambiar el texto efectivo. Runtime contenía 8 alertas ausentes de fuente: gruposarr-salud yhomelab_rutas. Reconciliadas exactamente, conservando lógica,etiquetas,tiempos y anotaciones. Evita perderlas en un despliegue futuro.

Validación conpromtool 3.15.0 del contenedor Prometheus, usando solo temporales propios retirados después: 83 reglas válidas y 6 escenarios unitarioscorrectos. Cobertura:esperafor,burst/reset/histórico/LXC,sensor CPUvs DIMM,temperatura normal, ARCenorme+Mem Availablebajo y memoria sana. YAMLrenderizado y candidato selectivo son exactamente equivalentes porgrupo; solo cambia su orden.

Pruebas versionadas: ansible/roles/observability_collector/tests/proxmox-thermal-alerts.test.yml. Artefactos locales revisables en/tmp/homelab-capacity-alerts-20261019. más rendered.yml,runtime.yml,selective.yml,test.yml ydiff. El coordinador decide/aplica reloadsin reinicio tras validar el staging.

Actualización del coordinador: aplicado en CT217 mediante escritura conservando inode y HUP, sin reinicio. Las 83 reglas terminaron evaluadas y saludables; reloadConfigSuccess=true, lastConfigTime 2026-10-19T21:07:02Z. Hash final <REDACTED>. Recuperación y detalle del primer rollback por validación prematura en coordinación.

Prioridades siguientes

  1. Revisar físicamente térmica 51 y recuperar el antecedentethermal.off antes de tocar arranque. Alertar ya con datos existentes sirve para observarlo.
  2. Resolver estabilidad 50 con evidencia y una ventana posterior a la copia; mantener diagnóstico remoto y no asignarle nuevas cargas para aprovechar un margen instantáneo. RAMadicional requiere reemplazar ambos DIMM y hardware compatible; no es una optimización de software pendiente de ejecutar.
  3. Registrar N-1 con carga caliente; +828 Mi Bno acredita holgura. Evitar nuevos recortes VM 208 con reclaim/IOen curso. Mantener procedimientosdegradados acotados y exclusiones HAexplícitas, sin parar sitios de propiedad no aclarada.