Revisión adicional: automatismos, recursos y observabilidad — 19 octubre 2026

Lecturas 22:13–22:18 CEST. Alcance: VM208, Vera, servicios de observa CT217, Prometheus, contratos existentes y estado de los dos nodos. No se despertaron productos lazy/Bazzite, ejecutaron backups, scrub, IA, pruebas de carga o failover. No se enviaron notificaciones. La contraseña Synology queda fuera del alcance.

Se leyeron skill operaciones, referencia de acceso, instrucciones de documentación, revisiones de simplificación 20260916 y remediación 20261019. Los tres cron rotos, doble scrub ZFS y doble backup de viajes ya corregidos no se repiten como novedades.

Corrección aplicada: propietario de Jellyfin en las alarmas

Prometheus tenía 44 targets up, pero dos alertas críticas ContenedorImprescindibleCaido en VM208: jellyfin y onepacerr. La primera era un inventario desactualizado: Jellyfin está en HA CT220 y su probe existente blackbox-https-external, instance=https://jellyfin.monxas.casa, devuelve probe_success=1. Un scrape up por sí solo no acreditaría disponibilidad; se comprobó la métrica probe.

Se ha retirado exclusivamente jellyfin de /home/monxas/scripts/contenedores-esperados.txt. El monitor conserva los otros 42 nombres y las reglas generales de fallo y created. No se borraron contenedores antiguos ni se cambió su estado. Fuente importada a scripts/monitoring/.

Además se corrigió la publicación del script existente contenedores_caidos.sh: PUT reemplaza el grupo Pushgateway en lugar de POST, que conservaba la serie Jellyfin retirada. Curl usa fail/show-error para propagar errores HTTP. Es necesaria esa sustitución para que cambiar el inventario retire la métrica.

• Dos pruebas aisladas pasan: runtime esperado/caído, created antiguo no-lazy, exclusión lazy individual y sustitución PUT; inventario ausente falla sin publicar.
• bash -n correcto. El timer y su frecuencia permanecen iguales.
• Ejecución real: vigilados=42 caidos=1 created_viejos=1, ambos últimos onepacerr.
• Pushgateway y consulta instantánea Prometheus ya no contienen la serie Jellyfin local; conservan onepacerr=0 y plundrio-onepacerr=1. La alerta previa puede conservarse durante su evaluación/retención configurada: a las22:18 ya estaba resuelta en Prometheus. No se borraron alertas manualmente.
• Rollback de los dos archivos: VM208 /home/monxas/backups/docker-estado-20261019/*.before.

Mejoras pendientes concretas

1. Resolver el contrato operativo de onepacerr

onepacerr (ghcr.io/eltharynd/onepacerr:latest) está en created desde 21:02CEST, no tiene label lazy y declara restart unless-stopped. Es un organizador/pipeline conectado a Jellyfin. plundrio-onepacerr es un cliente torrent distinto, monxas/plundrio-fixed:env-key-replacer-20260920, running/healthy.

La migración preservó su estado dormido anterior; eso no demuestra intención permanente de inactividad. Queda pendiente confirmar el uso previsto antes de arrancar un pipeline que podría organizar medios o retirar sus alarmas. Se conservan su critical y el aviso created; no se los clasifica como falsos positivos. Impacto: recuperar la función si se espera activa, o definir una política explícita que permita distinguir una pausa intencional de una caída real.

2. Reconciliar el colector de contratos con los propietarios y entorno actuales

Último informe existente: 21:23CEST, tres fallos y 26 elementos sin verificar. RunWisp registra seis ejecuciones fallidas de service_contracts en 24h; no se lanzó de nuevo el colector en esta revisión.

• Audiobookshelf: fallo genérico de colector RuntimeError; contrato todavía lifecycle=always de VM208. Se confirmó propietario actual CT218: /opt/personal/musica/compose.yaml, Docker audiobookshelf running/healthy desde el reinicio. Es un contrato local obsoleto, no evidencia de caída actual. Prioridad1: reconciliar contratos multihost con fuente central, sin eliminar esta cobertura hasta disponer de equivalente en el nuevo propietario. El colector actual restringe probes a VM208; no se rediseña en esta intervención.
• Hunter y scanner: diferencia de entorno CF_API_TOKEN entre Compose resuelto y runtime. Solo se comprobaron nombres de campos y booleanos, nunca sus valores. Ambos contenedores están running/healthy y tienen token presente, lo cual no acredita que el valor sea correcto ni que el contrato sea falso positivo.
• Los recibos funcionales de septiembre con caducidad 30 días han vencido. Los elementos sin verificar no equivalen a 26 averías. Renovarlos mediante flujo real cuando corresponda; no ampliar plazos o estampar fechas para volver el panel verde.

Impacto: restaurar un comprobador fiable y localizar diferencias reales sin recrear todos los servicios ni sobrescribir código propio.

3. Atender una causa de indexación que genera tres avisos

Las APIs nativas actuales de Prowlarr, Radarr y Sonarr notifican IndexerLongTermStatusCheck: MySpleen indisponible durante más de seis horas. Las tres alertas ArrSaludWarning se corresponden con ese mismo origen. No es el antiguo problema AllowedHosts ya corregido.

Revisar autenticación/disponibilidad del indexer con su propietario y mantener las otras fuentes activas. Si es transitorio, observar recuperación; no desactivar reglas globales, borrar indexers o alterar los perfiles equilibrados del usuario. Impacto: recuperar la fuente afectada y agrupar la explicación del incidente. No se probaron descargas ni se alteraron credenciales de trackers.

4. Vigilar presión y crecimiento de VM208 con sus métricas existentes

En la muestra: raíz 148GiB usados de 194GiB (80%), 39GiB disponibles. Docker: 62.34GB en imágenes, 9.153GB reclamables de 91 imágenes, 82 aún referenciadas; contenedores 779MB, volúmenes 1.153GB, build cache cero. No hay evidencia de una gran caché de compilación que justifique una limpieza general. /var/log 428MB y backups locales 6GiB no son el volumen dominante observado.

RAM invitado 7.7GiB, disponible 2.55GiB, swap 2.8GiB y PSI memoria full aproximadamente 1–2% durante la muestra. vmstat muestra swap-in puntual, swap-out cero en tres intervalos y CPU mayormente ociosa; no demuestra presión sostenida ni que todo el swap sea inactivo. La copia inicial de originales estaba en curso, por lo que no debe atribuirse toda esta muestra a carga habitual.

Reutilizar Prometheus para observar varios ciclos de uso real, crecimiento de raíz y presión PSI; dimensionar tras esa evidencia. Evaluar imágenes antiguas individualmente conservando las necesarias para rollback, nunca prune -a indiscriminado. No se ha liberado espacio ni reducido memoria.

Estado y límites

VM208, pmx51, Vera y observa: cero unidades systemd fallidas en la consulta. Vera: MemoryHigh=MemoryMax=4GiB, 2.46GiB de cgroup, sin reinicios, PSI0 y swap0. Los contenedores activos VM208 no mostraban OOMKilled; am-flask y am-worker1 sumaban un reinicio cada uno, el resto cero. Eso no acredita todos sus workflows.

Prometheus: 44 targets up; 62,876 series en head. Las métricas consultadas de rechazo Loki/drop Promtail no estaban expuestas: no se deduce cero pérdidas. Además de los avisos anteriores existe RemotePulseHostDown de mac-mini-carmelo; se conserva sin intervenir en equipos de Carmelo, fuera de alcance. La alerta Dependabot estaba pending, no firing; no se aplican actualizaciones por lote.

No se declara estabilidad N-1 por el margen frío posreinicio ni se repite la activación Intel ya verificada. La revisión ofrece evidencia puntual, no una certificación de todas las aplicaciones o de carga máxima concurrente.