Los CronJobs de Kubernetes suelen fallar de maneras bastante poco dramaticas: una imagen no existe, un secreto expiro, un endpoint externo responde lento. El problema serio empieza despues, cuando la alerta por correo llega sin contexto, duplicada o enlazando al panel equivocado. He visto ese patron varias veces y siempre cuesta mas de lo que deberia.
Por eso me gusta tratar estas alertas como un contrato operativo. No basta con confirmar que "salio un email". Hay que verificar que el mensaje explica que job fallo, en que cluster, que intento estaba corriendo y donde mirar primero. Si no, el on-call abre la bandeja, frunce la cara y pierde minutos que valen bastante.
Donde se rompen las alertas de CronJobs
En equipos pequeños el flujo suele nacer simple: el job falla, una lambda o un worker manda el correo y asunto resuelto. Pero con el tiempo aparecen detalles raros:
- reintentos que envian dos mensajes para el mismo fallo
- links que apuntan a staging por variables heredadas
- asuntos genericos como "Job failed"
- plantillas que no incluyen namespace, region o ventana horaria
La parte incomoda es que muchas de estas fallas no rompen el pipeline. El job sigue fallando "bien", solo que la alerta deja de servir. Y ese tipo de degradacion pasa facil a produccion si nadie la prueba de forma aislada.
Tambien ayuda pensar en como la gente busca estas incidencias despues. En notas internas he visto terminos como temp org mail o tempail cuando alguien intenta recordar que herramienta usaron para pruebas. Son errores humanos, claro, pero conviene tenerlos presentes en documentacion y busquedas.
El contrato minimo que conviene validar
Para mi, una alerta util de CronJob deberia responder cinco preguntas sin hacer scroll raro:
- Que CronJob o workload fallo.
- En que cluster o namespace ocurrio.
- Que timestamp o ventana de ejecucion corresponde al fallo.
- Cual fue la razon corta o el primer sintoma observable.
- Donde revisar logs, eventos o dashboards.
Si tu flujo ya usa bandejas temporales para otras pruebas, puedes reciclar esa disciplina. Este articulo sobre aislar bandejas efimeras por ejecucion muestra bien por que separar inboxes por corrida evita confusiones. Y si quieres que la alerta tenga mas valor para guardias reales, tambien sirve esta idea de hacer que los correos operativos den contexto real.
Cuando necesito una bandeja descartable para validar el flujo de punta a punta, suelo apoyarme en un servicio de throwaway email porque me permite atar un inbox a una sola corrida sin mezclar mensajes viejos. No es la unica opcion, pero el principio si importa.
Un flujo simple para probarlas sin ruido
Mi regla es aburrida a proposito: una ejecucion, una bandeja, una decision. Algo asi:
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
INBOX="cronjob-$RUN_ID@example.test"
trigger_failure_notice \
--cluster "prod-saigon-1" \
--namespace "billing" \
--cronjob "invoice-retry" \
--reason "image pull backoff" \
--recipient "$INBOX"
wait_for_message "$INBOX" 120
assert_message_count "$INBOX" 1
assert_subject_contains "$INBOX" "invoice-retry"
assert_body_contains "$INBOX" "prod-saigon-1"
assert_link_host "$INBOX" "grafana.example.com"
No intento emular todo el incidente. Valido el contrato minimo y guardo un poco de contexto:
run_id- cluster y namespace
- nombre del CronJob
- destinatario usado
- host del enlace principal
- latencia hasta recibir el mensaje
Ese set pequeño ya separa varios bugs que se parecen entre si. Si el correo llega tarde pero correcto, sabes que el emisor existe y toca revisar cola o proveedor. Si llega dos veces con el mismo run_id, casi seguro tienes reintentos mal cerrados. Si el asunto viene bien pero el enlace apunta a otro entorno, el fallo esta en la plantilla o en las variables de despliegue. Suena obvio, pero no siempre se mira por ese orden y aveces eso alarga la investigacion sin necesidad.
Tambien me sirve registrar si la alerta menciona un siguiente paso claro. "Ver logs del job" ayuda. "Failure detected" no ayuda casi nada. Parece detalle de redaccion, pero en operacion real reduce el tiempo de interpretacion, y eso ya paga el test.
La checklist que deja dormir mejor al on-call
Antes de dejar este flujo en CI o en pre-release, reviso esta lista:
- el mensaje pertenece a la corrida actual
- no hay correos duplicados para un solo fallo
- asunto y cuerpo nombran CronJob, cluster y namespace
- el motivo del fallo se entiende sin abrir otros sistemas
- el enlace principal apunta al entorno correcto
- la marca de tiempo usa el formato del equipo
No hace falta una suite gigante. Seis checks legibles suelen ganar a veinte asserts fragiles. Lo importante es que otra persona pueda leer la prueba medio dormida y entender que protege.
Preguntas frecuentes
Conviene ejecutar esto en cada cambio?
Si cambias plantillas, rutas de alertas, variables de entorno o politicas de reintento, yo diria que si. Si el cambio no toca nada de correo, puede bastar con una corrida programada.
Hace falta validar el HTML completo?
Normalmente no. Prefiero revisar campos con impacto operativo: asunto, contexto del job, enlace principal y timestamps. El resto se puede mirar aparte.
Cual es la mejora mas visible?
Menos tiempo perdido interpretando alertas mediocres. Cuando el correo llega claro, el equipo actua antes y discute menos. No parece glamuroso, pero si se nota un monton.
Top comments (0)