Alertas candidatas para publicación del dump de Immich

20 de octubre de 2026. La preparación partió de 86 alertas candidatas frente a 84 del runtime. Tras la autorización y el despliegue selectivo descritos al final, en esa fase quedaron 86 alertas cargadas, sin restart ni notificaciones de prueba. Estado vigente02:16CEST: una regla posterior de expectativa eleva el total a87, con dos evaluaciones sanas; el publisher está habilitado en RunWisp; primera ejecución automática prevista11:10, todavía sin acreditar. Las métricas reflejan la última ejecución, anterior a la activación.

Se añaden dos reglas severity: warning, ambas con for: 10m, al grupo nas-originals de scripts/original-backups/alerts.yml y a su fuente Ansible ansible/roles/observability_collector/templates/alerts.yml.j2:

• OriginalsDumpPublicationFailed: publicación habilitada y métrica de fallo igual a 1. Incluye los fallos upstream que ya expone el hook.
• OriginalsDumpPublicationStale: publicación habilitada, último éxito conocido mayor que cero y antigüedad superior a 26 horas. El valor cero nunca produce una historia de éxito ficticia ni esta alerta stale.

No se añaden etiquetas de generación, rutas ni datos privados. Desactivar el hook silencia estas dos reglas incluso conservando el éxito anterior. Las señales de ausencia del colector/job de originales permanecen en las reglas anteriores; ausencia de métricas o ausencia de primer éxito no se presenta como respaldo sano. RunWisp ya conserva el fallo global del job y estas reglas candidatas completan la telemetría específica del dump. Ninguna regla afirma restauración de base de datos o coherencia con medios.

Verificación aislada

Se compararon ambas fuentes con HEAD: quitando exactamente las dos reglas nuevas, su contenido anterior es idéntico byte por byte. La cuenta del template pasa de 84 a 86. Se renderizó únicamente el grupo nas-originals, sin variables privadas ni render completo, y se comprobó igualdad semántica con el snippet.

La presunción inicial de un promtool local cacheado no quedó acreditada. La coordinación autorizó usar el proceso existente del contenedor Prometheus. El inventario de PVE confirmó CT217 ejecutándose en proxmox2; allí se verificó promtool 3.15.0, revisión <REDACTED>.

Se creó exclusivamente /tmp/dump-publication-alerts-review-20261020 dentro del contenedor existente, modo 0700, con dos ficheros propios modo 0600: alerts.rules.yml (snippet envuelto en groups) y alerts.test.yml (fixture versionado). No se tocó ningún fichero montado o cargado de configuración. Resultados:

• promtool check rules: 10 reglas del snippet correctas; este resultado no se presenta como validación de un render completo de las 86 candidatas.
• promtool test rules: SUCCESS, seis escenarios de dump-publication-alerts.test.yml: disabled con éxito antiguo, fallo habilitado antes/después de diez minutos, éxito mayor de 26 horas con espera de diez minutos, nunca publicado, éxito nuevo que resuelve fallo/stale y métricas ausentes sin afirmación de salud.
• git diff --check: limpio.

Los dos ficheros y el directorio temporales del contenedor se eliminaron exactamente al terminar. No hubo restart, reload, container nuevo, pull, cambios de horarios ni instalación de herramientas. Esta fase de pruebas no activó alertas ni probó la entrega de notificaciones. El despliegue autorizado posterior se registra a continuación; la activación del publisher sigue siendo independiente.

Despliegue selectivo autorizado, 20 de octubre a las 00:54 CEST

La coordinación autorizó incorporar únicamente estas dos reglas. Se revalidó CT217 ejecutándose en proxmox2 y el bind mount individual desde /home/monxas/appdata/prometheus/alerts.yml a /etc/prometheus/alerts.yml. La precondición del fichero se cumplió: 84 reglas, hash <REDACTED>. La comparación estructural confirmó que el candidato añade sólo las dos reglas y conserva semánticamente las otras 84.

El candidato completo pasó promtool check rules /dev/stdin: 86 reglas correctas antes de escribir. Se guardó rollback privado 0700/0600/fsync en CT217:/root/rollback-immich-dump-alerts-20261019T225443Z/alerts.yml.before, hash del baseline a020156.... Bajo flock del propio fichero y CAS de hash/inode se escribió in-place y se hizo fsync, conservando el inode 1029537, uid/gid 1000:1000 y modo 0664. Se comprobó de nuevo el fichero real con promtool: 86 reglas correctas antes del reload.

Se hizo exclusivamente POST http://127.0.0.1:9090/-/reload; no HUP, restart, contenedor nuevo ni cambio de receptores. Resultado:

Comprobación	Resultado
Hash runtime de las 86 reglas	<REDACTED>
reloadConfigSuccess	true
lastConfigTime	2026-10-19T22:54:43Z
Evaluaciones distintas de las nuevas reglas	22:54:54Z y 22:55:09Z
Estado	86 reglas health=ok; las dos nuevas inactive, sin lastError
prometheus.yml intacto	<REDACTED>
Contenedor intacto	<REDACTED>, RestartCount 0, StartedAt 2026-10-19T20:00:13.735970114Z

En esa fase00:54, el backend y helper de VM208 estaban instalados pero RunWisp aún no tenía el flag; las cinco métricas daban cero. Posteriormente se habilitó y cargó el flag mediante reload, conservando las19 tareas y la ejecución11:10. Los ceros siguen describiendo la ejecución anterior; no acreditan publicación ni deben convertirse en éxito artificial.

Rollback: exigir CAS del hash 3f0ec3... y flock, reescribir alerts.yml.before en el mismo inode, fsync, validar las 84 reglas con promtool y hacer el mismo POST de configuración. Mantener owner/modo/configuración/receptores intactos y comprobar evaluaciones sanas. No utilizar rename para este bind mount. El rollback no se ejecutó. No se enviaron eventos o notificaciones de prueba y no se cambió ningún horario.