El trabajo programado que dejó de correr y nadie notó
Un proceso periódico que se cayó y estuvo días sin ejecutarse. Nada falló, nada avisó: simplemente dejó de pasar algo que tenía que pasar. Por qué la ausencia es el tipo de falla más difícil de detectar.
Un error tiene la cortesía de aparecer: hay una excepción, un registro, un código de estado. La falla más difícil es la contraria: algo que tenía que ocurrir y no ocurrió.
Un trabajo periódico que dejó de correr no genera ningún evento. No hay error que buscar. Y se descubre por la consecuencia —un resumen que no llegó, datos que quedaron viejos—, que puede tardar días en ser evidente.
Por qué se caen sin avisar
| Causa | Qué se ve | Qué no se ve |
|---|---|---|
| El proceso que los ejecuta murió | Nada | Ninguna ejecución desde hace días |
| El contenedor se recreó sin el servicio de tareas | Todo lo demás funciona | La tarea ya no está declarada |
| La tarea corre y falla siempre | Un error en un registro que nadie lee | Que el efecto nunca se produce |
| Corre pero no hace nada | Ejecución exitosa | Que la consulta devuelve vacío por un cambio de datos |
La cuarta es la más insidiosa. Un proceso de limpieza que dejó de encontrar archivos por un cambio de ruta reporta éxito todos los días, y el disco se llena igual.
La forma de detectar una ausencia
No se puede alertar sobre un error que no existe. Lo que se alerta es la falta de la señal de vida.
Cómo funciona
- Cada ejecución exitosa registra una marca: un archivo con la fecha, una fila, un aviso a un servicio.
- Una comprobación independiente verifica que esa marca sea reciente: si la tarea es diaria, que no tenga más de un día y pico.
- Si está vieja o no existe, se avisa. Eso cubre las cuatro causas de la tabla a la vez.
- La comprobación no puede vivir en el mismo proceso que ejecuta la tarea: si muere, se lleva al vigilante.
Que el resultado quede escrito
La otra mitad es poder responder “¿cuándo corrió por última vez y qué hizo?” sin entrar a buscar.
Tres cosas mínimas por tarea
- Envolver la ejecución en algo que registre inicio, fin, código de salida y duración, en un lugar común para todas.
- Capturar la salida. Una tarea programada que escribe en la nada pierde justo el mensaje que hace falta el día que algo anda mal.
- Un inventario de tareas: cuáles existen, con qué frecuencia, qué hacen y qué pasa si una no corre. En un servidor con varias aplicaciones, sin esa lista nadie sabe qué debería estar pasando.
Antes de seguir, predecí
Dos problemas que aparecen después
Lo que suele romperse cuando la tarea sí corre
- Solapamiento. Si una ejecución tarda más que el intervalo, empiezan a correr dos a la vez. Según lo que hagan, eso duplica efectos o se traba. Se resuelve con un bloqueo por tarea.
- La zona horaria. Una tarea programada a una hora del servidor que está en otra zona corre en un momento distinto del esperado, y los resúmenes diarios abarcan un período corrido.
Más a fondo · nivel seniorIdempotencia también acá
Una tarea periódica va a correr dos veces alguna vez: por un reintento, por un solapamiento o porque alguien la ejecutó a mano para probar. Si eso duplica un cobro, un correo o una fila, el problema no es la ejecución doble sino el diseño. Las tareas que se pueden repetir sin consecuencias son las que se pueden operar sin miedo, y eso vale más que cualquier protección contra la repetición.
El log de una tarea que no corre
Buscá en el log
El resumen diario no llegó durante cinco días y nadie lo notó. ¿Qué línea muestra por qué la tarea dejó de ejecutarse?
debug 1info 8warn 1error 111 de 11
El contenedor se recreó y arrancó con un perfil que no incluye el servicio de tareas. No hay ningún error en ninguna parte: el proceso que ejecutaba los trabajos periódicos simplemente no está, y lo que no corre no escribe nada. Por eso una falla de ausencia no se detecta leyendo logs sino comprobando lo contrario: que cada tarea haya dejado un registro de su última ejecución exitosa, y alertar cuando ese registro envejece.
Detectar lo que no pasa
Cierre
Autoevaluación
¿Lo entendiste?
Práctica