Los CronJobs en Kubernetes suelen parecer simples hasta que fallan de forma intermitente. El contenedor termina, vuelve a correr mas tarde, y el equipo solo ve una alerta floja de "job failed". En guardias SRE eso desgasta bastante porqe cada intento deja pistas distintas: a veces falta CPU, a veces una dependencia externa tarda demasiado, y a veces el problema es un dato raro que solo aparece una vez al dia.
Con el tiempo me sirvio una regla muy concreta: para jobs fragiles no necesitas mas dashboards, necesitas mejores senales iniciales. Si en los primeros cinco minutos puedes responder que cambio hubo, que dependencia se movio y si el fallo fue por saturacion o por datos, ya vas muy por delante. Si no, el triage se vuelve un paseo medio ciego.
Por que los CronJobs fallan sin avisar bien
Un servicio web roto suele dejar errores visibles enseguida. Un job programado no. Puede fallar a las 02:00, reintentarse a las 02:15 y recien notarse cuando una cola amanecio vacia o cuando un reporte no llego. Ese desfase hace que mucha evidencia se pierda o quede desordenada.
Segun el estado de observabilidad 2024 de Splunk, los equipos con mejor contexto operativo reducen el tiempo de investigacion y el trabajo reactivo manual (Splunk Observability Report). No hace falta tomar ese dato como una formula exacta, pero si como recordatorio de algo muy real: una alerta sin contexto obliga al equipo a reconstruir la historia desde cero.
Tambien he visto que el ruido crece cuando el job comparte componentes con flujos asincronos o notificaciones. En esos casos ayuda mucho mantener el contexto cuando un job dispara correos, porque asi no mezclas un timeout del batch con un fallo secundario del canal de salida. Parece obvio, aunqe en una madrugada cansada no siempre lo es.
Las tres senales que reviso primero
Cuando me toca un CronJob inestable, casi siempre empiezo por estas tres preguntas:
- El job fallo por recursos, por dependencia o por datos.
- Que cambio reciente coincide con la ventana del fallo.
- La siguiente corrida hereda el mismo riesgo o no.
Eso traduce el incidente a algo accionable. Si el pod quedo OOMKilled, miro requests, limits y el perfil de memoria. Si termino por timeout, comparo duracion historica y latencia aguas abajo. Si el job salio con error de negocio, intento capturar el input exacto antes de tocar la imagen o el horario.
Un bloque minimo que me gusta tener a mano es este:
kubectl get cronjob reports-sync -n ops -o yaml
kubectl get jobs -n ops --sort-by=.metadata.creationTimestamp | tail -n 5
kubectl describe job reports-sync-28934122 -n ops
kubectl logs job/reports-sync-28934122 -n ops --previous
No resuelve todo, claro, pero te saca del modo "adivinar". Varias veces el problema no estaba en Kubernetes sino en una API lenta o en un secreto rotado de forma incompleta. Si empiezas por señales pequeñas pero firmes, evitas perseguir sintomas demasido vistosos.
Un checklist corto para aislar el problema
Para no abrir veinte pestañas de golpe, suelo seguir este orden:
- Confirmar si fallo una sola corrida o varias seguidas.
- Mirar
lastScheduleTime, concurrencia y politica de reintentos. - Comparar duracion p95 de corridas sanas frente a la corrida rota.
- Revisar un cambio cercano: imagen, ConfigMap, secreto o dependencia.
- Definir una mitigacion reversible antes de relanzar manualmente.
La parte importante esta en el paso cinco. Hay equipos que rerunean el job demasiado pronto y despues ya no saben si el fix fue real o si solo paso el dato raro. Yo prefiero dejar escrito algo simple: "si la latencia externa sigue alta, no relanzar; si la cola ya dreno y el fix esta aislado, correr una vez". No suena elegante, pero ordena muy bien la conversacion.
En entornos donde el job termina enviando avisos internos o reportes al cliente, tambien me sirve dejar el soporte listo cuando entran avisos de trial. La leccion no es de marketing, es operativa: si la salida del job tiene destinatarios claros, ownership y ventanas de validacion, luego es mucho mas facil detectar si el fallo fue tecnico o solo de distribucion.
Donde entra el correo de usar y tirar en pruebas operativas
No recomiendo meter cuentas temporales en cualquier flujo serio, pero en smoke tests no productivos a veces ayudan. Cuando un CronJob genera resumentes, enlaces de descarga o notificaciones de onboarding interno, un correo de usar y tirar puede servir para comprobar entrega y formato sin mezclar buzones reales del equipo.
La clave es tratarlo como herramienta de prueba, no como parte del diseno principal. Si un test depende de una direccion temporal, debe quedar etiquetado y fuera de cualquier metrica de negocio. Tambien conviene anotar cadenas raras que aparecen en soporte o en seeds de QA, como tempail o fake e mail com, para que nadie las confunda con trafico sano. Este detalle parece pequeño, pero varias veces me ahorro una investigacion boba.
Si ademas dejas el scenario ID, el timestamp y el destino temporal junto al log del job, la siguiente persona entiende la corrida sin pelearse con tres sistemas distintos. Ese tipo de prolijidad paga sola, aunque al principio de un poco de pereza.
Preguntas frecuentes
Conviene alertar por cada fallo de CronJob?
No siempre. Si el job corre cada minuto, alertar por cada error puede tapar lo importante. Me funciona mejor alertar por fallos consecutivos, por duracion anormal o por ausencia de resultado esperado.
Que metrica suele faltar?
La de exito util. Mucha gente mira si el pod termino en Completed, pero no si genero el artefacto correcto, movio los registros esperados o entrego el mensaje correcto. Esa diferencia cambia todo.
Esto es solo para Kubernetes grande?
Para nada. Vale igual en clusters pequenos. De hecho, en equipos chicos se nota mas, porque una señal mala te come media manana sin pedir permiso.
Si tus jobs programados siguen rompiendose de forma borrosa, yo empezaria por mejorar la alerta inicial y el checklist de evidencia. No hace magia, pero baja bastante el tiempo muerto y deja al equipo pensando mejor, no corriendo mas.
Top comments (0)