Hacer observables los jobs programados
Un wrapper de ejecución reutilizable hizo visibles los jobs de corta duración sin cambiar su lógica de negocio ni permitir que las fallas de telemetría los hicieran fallar.
Se instrumentaron 24 de 26 entradas activas. Los umbrales de frescura reflejan cada programación; las fallas de telemetría no reemplazan el resultado del job.
Contribución de un vistazo
- Mi responsabilidad
- Wrapper de ejecución, exporter de solo lectura, instrumentación de crontab y reglas según la programación.
- Alcance
- 24 de 26 entradas de cron activas, 16 reglas de Prometheus y un dashboard de 12 paneles.
- Colaboración y límites
- Instrumenté la ejecución de los jobs sin reemplazar su lógica de negocio ni su código de salida real.
- Resultado
- Las marcas de tiempo de finalización persistentes volvieron observables los jobs de corta duración; una falla de monitoreo no anuló el resultado del job.
El problema
Una flota heredada de cron procesaba jobs de negocio, pero no exponía ninguna señal confiable de liveness ni de profundidad de cola. Investigar dudas sobre la entrega implicaba buscar en grandes archivos de log y escribir consultas a la base de datos. Un job muerto podía permanecer invisible porque los procesos de corta duración desaparecen antes de que un scraper los vea.
Mi contribución
Construí un wrapper reutilizable, un exporter de solo lectura de métricas de negocio y un instrumentador idempotente de crontab. El despliegue cubrió 24 de 26 entradas de cron activas y agregó 16 reglas de Prometheus y un dashboard de Grafana de 12 paneles.
Hacer medible el silencio
La señal de salud principal era la marca de tiempo de la última ejecución exitosa. Una ejecución fallida o ausente no debe adelantarla. Los umbrales se agruparon por programación porque una tarea mensual y un procesador que corre cada minuto no pueden compartir el mismo presupuesto de retraso.
Se reutilizó el transporte de Pushgateway existente. Un manifiesto de reemplazo no habría aportado ninguna capacidad útil y arriesgaba cambiar un límite de ingress no relacionado, así que dejé esa infraestructura tal como estaba.
Proteger el job de negocio de su propio monitoreo
El wrapper propagaba el código de salida real del proceso. Un job fallido no actualizaba su marca de tiempo de éxito. Cuando el gateway no estaba accesible, un job de negocio exitoso seguía siendo exitoso. Un proceso reemplazado que recibía SIGTERM se manejaba por separado de una falla de la aplicación, de la misma forma en que funcionaban los procesadores existentes que corrían cada minuto.
Resultados y medición
El despliegue preservó la cantidad de entradas activas del crontab, verificó la ruta de la VM al gateway, validó las 16 reglas con promtool y revisó el procesamiento de negocio después del cambio. Las pruebas cubrieron el éxito, un código de salida de error, SIGTERM y un gateway no disponible.
La cobertura fue parcial a propósito: dos entradas activas quedaban fuera del modelo de scripts del wrapper. También se mantuvieron distintos el acuse de recibo del proveedor externo y la entrega real visible para el cliente; este dashboard no prueba que un sistema externo haya mostrado cada resultado.
La lección
Instrumentar jobs heredados es útil cuando se preserva su comportamiento. Diseña la ruta de fallo de la telemetría de forma tan deliberada como su ruta de éxito.
Decisiones y próximos pasos
Una mirada retrospectiva al enfoque y sus límites. La próxima mejora es una propuesta, no un resultado entregado.
Alternativa y justificación
Hacer scraping de un proceso efímero puede no captarlo en absoluto. Persistir las señales de finalización preserva la visibilidad después de la salida.
Contrapartida
Una tarea mensual y una tarea que corre cada minuto necesitan presupuestos de frescura distintos. La telemetría no debe convertirse en una nueva dependencia del job de negocio.
Lo que mejoraría a continuación
Próxima mejora: revisar las dos entradas sin instrumentar y ejercitar las alertas de ejecución ausente contra cada clase de programación.