Skip to content

Frescura del checker PBS — 20 de octubre de 2026

Hueco y evidencia

Revisión de fuentes, sin ejecutar checker, POST, jobs, reload ni consultas a hosts. El coordinador acreditó a las 05:02 CEST que Pushgateway conservaba el grupo exacto pbs_sync_check, último POST 1792386059.237 (19 oct, 07:00:59 CEST) y contador 0. Las nuevas gauges de colección/evaluación/completado aún no existían: helper instalado a las 23:47 sin POST; primer export natural previsto a las 07:00. Su ausencia antes de ese primer ciclo no demuestra un fallo nuevo.

La configuración Prometheus usa honor_labels: true: la etiqueta seleccionable es job="pbs_sync_check", conservada del grupo publicado, no job="pushgateway". La regla crítica existente sólo observa pbs_syncjob_consecutive_failures >= 2. Si el checker deja de ejecutarse o su POST falla, el grupo puede seguir exponiendo un contador antiguo aunque el scrape de Pushgateway funcione. No se encontró una regla fuente equivalente de frescura de este checker.

Reglas añadidas: 87 previas conservadas, 89 tras aplicar

Se añaden únicamente dos warnings con for: 10m al grupo backup:

  • PBSSyncCheckStale: último push_time_seconds{job="pbs_sync_check"} superior a 26 h o ausencia del grupo. La señal builtin cubre también el esquema antiguo; mide aceptación del último POST, que puede publicar un resultado fallido.
  • PBSSyncCheckUnhealthy: colección o evaluación igual a 0; último completado positivo con edad superior a 26 h; o ausencia de cualquiera de los tres campos nuevos después del primer ciclo acordado. Ese gate es el 20 oct a las 07:20 CEST, epoch 1792473600, calculado con Europe/Madrid. La ausencia empieza entonces a contar sus diez minutos; no exige exportar antes de las 07:00. Un cero real de colección/evaluación sí puede advertirse antes del gate.

No se modifica la crítica ni su umbral. Tampoco se considera que el timestamp del último completado sea el del último éxito: puede corresponder a una tarea fallida. La señal continua de edad evita esperar a dos evaluaciones diarias para advertir que ya no hay ningún completado dentro de 26 h.

El checker acepta último sync completado con status OK y edad <= 26 h; no exige que haya arrancado el sync de las 06:00 de hoy. Ejemplo: un completado de ayer a las 06:30 aún es aceptable hoy a las 07:00; sin nuevos completados, mañana a las 07:00 sería el primer rechazo y pasado mañana a las 07:00 el segundo (48 h 30 min y 72 h 30 min desde aquel completado). El warning continuo de edad cruza a 26 h y espera 10 min, sin cambiar la política del checker. No demuestra restore, integridad de datos o ejecución de una programación concreta.

Validación fuente y fixtures

El snippet scripts/pbs-sync-check/alerts.yml coincide con las dos reglas de la plantilla Jinja. Render local con StrictUndefined, sin secretos ni contexto HA. Comparación en RAM antes/después: las 87 reglas previas permanecen semánticamente idénticas; candidato 89. Seis contratos locales pasan y git diff --check pasa.

Los 12 casos de pbs-sync-alerts.test.yml usan el motor promtool, sin una evaluación PromQL reimplementada en Python: esquema antiguo antes del primer export; nuevo sano; error de colección/API; primer check fallido; completado que envejece entre checks; POST viejo; grupo ausente; cada uno de los tres campos ausente; etiqueta job ajena; y recuperación. El driver sólo prepara una copia aislada de las dos reglas y rebasa exclusivamente el gate 1792473600 a 3600 para simular el reloj sin millones de pasos. Conserva el umbral real de 26 h.

python scripts/pbs-sync-check/test_alerts.py --write-promtool-rules DIRECTORIO_PRIVADO_NUEVO
promtool test rules DIRECTORIO_PRIVADO_NUEVO/pbs-sync-alerts.test.yml
python scripts/pbs-sync-check/test_alerts.py --write-full-rules ARCHIVO_NUEVO.rules.yml
promtool check rules ARCHIVO_NUEVO.rules.yml

El coordinador descargó promtool oficial 3.15.0 para darwin-arm64 y verificó SHA256 <REDACTED> contra el digest GitHub API y sha256sums.txt de la release. Sus cinco contratos iniciales y los 12 fixtures con promtool real pasaron. El sexto contrato, añadido después, verifica el render completo de 89 reglas y su escritura exclusiva; los seis contratos locales pasan. La ejecución CI se acredita abajo.

Job CI separado: ejecución acreditada

El workflow existente original-backups-tests.yml incorpora un job pbs-alerts con Python 3.12, Jinja2 3.1.6 y PyYAML 6.0.3. Mantiene intacto el job unitario y añade triggers para los tres archivos de alertas PBS y la plantilla completa. El driver con Jinja/PyYAML queda fuera de tests/, conservando la suite PBS stdlib existente. El job comprueba contratos, sintaxis de las 89 reglas renderizadas y los 12 fixtures aislados con promtool real, sin Docker del homelab ni secretos.

Se verificaron mediante urllib los assets de la release oficial Prometheus 3.15.0: el archivo linux-amd64 tiene SHA256 <REDACTED>, coincidente entre digest GitHub API y sha256sums.txt descargado. El job fija ese hash, exige que aparezca exactamente en el checksum oficial y valida el archivo antes de extraer únicamente promtool. YAML, conservación del job previo, paths y sintaxis bash pasan localmente; no se ejecutó el binario Linux en macOS.

El run 39363058376 terminó SUCCESS en los tres jobs: suites stdlib en Python 3.10 y 3.12 y job pbs-alerts, con seis contratos, sintaxis completa de 89 reglas y 12 fixtures promtool reales en Linux. No se confunde esa prueba aislada con una notificación real ni con ejecución del checker PBS.

Aplicación posterior por el coordinador

A 03:46:19.553640 UTC / 05:46:19.553640 CEST, el coordinador incorporó sólo las dos reglas al archivo ya cargado en CT217. Comparación semántica: las 87 reglas previas permanecen idénticas y el total es 89. Promtool nativo validó las 89 antes de la recarga, que respondió HTTP 200, sin restart de Prometheus.

  • SHA previo: <REDACTED>.
  • SHA aplicado: <REDACTED>.
  • Inode 1029537, UID/GID 1000:1000 y modo 0664 conservados; escritura sobre el mismo archivo para preservar el bind existente.
  • Rollback privado: /root/rollback-pbs-sync-alerts-20261020-r_awla9l, directorio 0700, copia previa 0600 y recibo persistido con fsync.

La operación no ejecutó sync, backup, POST de métricas ni notificaciones de prueba. Dos lecturas posteriores de la API local de reglas acreditan 89 reglas con health=ok y ambos warnings nuevos inactive/ok. La primera, del coordinador a las 07:04:06 CEST, tenía lastEvaluation 07:04:02.250 CEST. La segunda, a las 07:05:27.757501 CEST, tras revalidar CT217 running en proxmox2, mostró lastEvaluation 07:05:17.2496522 para Stale y 07:05:17.249794275 para Unhealthy. Son evaluaciones distintas; no se deduce su salud sólo del HTTP 200 de reload. La ausencia de campos nuevos aún tenía gate a las 07:20 en esas muestras.

Una ampliación fuente posterior del mismo workflow añade los paths del drill pbs_restore_drill.py y tests/test_pbs.py a push y pull_request, y su suite sintética al job unitario en ambas versiones Python. El run 39372960508 terminó SUCCESS, incluidas las 16 pruebas del drill en Python 3.10 y 3.12 y el job promtool. Después, el run 39373278716 acreditó también las suites sintéticas Paperless de workspace (12 pruebas) y verificación de export (3) en ambas versiones, con el resto de jobs SUCCESS. Estos ensayos locales de fixtures no ejecutan restores de producción.

Ciclo natural y precisión de la métrica

El seguimiento PBS acredita el sync natural de 06:00 a 06:38:28 CEST, status OK, y checker de 07:00:31 a 07:00:32, RC 0. Las cuatro métricas nuevas ya estaban presentes, con colección/evaluación 1 y contador 0. Ninguna se publicó manualmente para probar las reglas.

Se detectó un defecto de precisión: :g reducía el epoch de fin 1792471108 a 1792470000. La edad del warning podía desplazarse 18 min 28 s en este caso; no era un sync adicional ni un fallo de la selección interna. El fix fuente conserva el número mediante representación round-trip, incluidas fracciones, con 19 pruebas locales correctas. La fuente 4e83af8 pasó el run 39373304025 en los tres jobs, incluidas las 19 pruebas PBS en Python 3.10 y 3.12 y promtool.

El coordinador instaló el helper a las 07:09:46.968412 CEST, tras revalidar CT186 y CAS del helper previo 4ebcd… al nuevo a54a…, mediante rename/fsync y compilación nativa Python 3.13.5 sin ejecutar el módulo. Shim, contador, unidades y timer permanecieron intactos; servicio inactive/MainPID 0 antes y después. El informe PBS conserva hashes completos, metadatos y rollback específico del helper en /root/rollback-pbs-check-precision-20261020-_31zchsn.

No se forzó POST ni se modificaron reglas para ocultar el valor previo: 1792470000 sigue publicado. La publicación precisa queda pendiente del checker natural del 21 de octubre a las 07:00 CEST. La instalación no se presenta como un nuevo sync ni como una evaluación externa del dato corregido.