Funciones / Tareas programadas
Una tarea cron que deja de ejecutarse no falla en voz alta: falla en silencio, y te enteras el día en que necesitas lo que producía. Monitorizar tareas cron convierte ese silencio en una alerta haciendo que la tarea informe, y avisándote cuando el informe no llega.
Una entrada de cron se pierde en una migración de servidor y la copia nocturna se detiene en silencio. No se rompe nada, no salta ninguna alerta y el sitio sigue respondiendo 200 durante meses, hasta la mañana en que alguien necesita restaurar, que es el día más caro posible para enterarse.
Todas las demás comprobaciones aquí funcionan haciendo una pregunta y leyendo la respuesta. Ninguna puede ver esta. Un servidor al que le han borrado el script de copia de seguridad es un servidor completamente sano, y pasará cualquier comprobación de disponibilidad que le apuntes durante todo el tiempo que quieras seguir apuntándosela.
Esta es la única comprobación de aquí que funciona al revés. Tu tarea llama a una URL cuando termina y te avisamos cuando esa llamada no llega.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://owlkeeper.com/ping/TU-TOKEN
Esa línea es toda la integración. Añade un curl al final de la tarea que ya ejecutas. No hay nada que instalar, ningún agente y ninguna biblioteca que mantener.
Dos detalles de esa línea merecen ser deliberados:
&& en lugar de ;. Con && el aviso solo se envía si el script terminó
con código cero. Una copia que falla a medias y sale con 1 nunca informa, así
que te enteras. Con ; el aviso se envía igualmente y has construido un
monitor que confirma que cron funciona, no que la copia funcionó.-fsS. Falla en silencio ante un error HTTP, no dice nada cuando todo va
bien, pero sigue imprimiendo los errores reales. Sin esto, curl escribe una
barra de progreso en la salida de cron y recibes un correo cada noche.Una tarea que tarda cuatro minutos no va tarde a los cuatro minutos. Tú decides cuánto margen tiene una ejecución antes de contar como perdida. Esa distinción es la diferencia entre un monitor que conservas y uno que silencias en la tercera semana.
No se informa de nada hasta que una ejecución se ha perdido de verdad. Configurar un monitor por la tarde para una tarea que se ejecuta a las tres de la mañana no te alerta esa misma noche: una tarea que nunca ha informado no va tarde, es nueva.
No «la tarea está caída», sino «la última ejecución fue hace nueve horas», que es la diferencia entre una pregunta y una respuesta.
Se avisa una vez, no cada noche. Una tarea detenida sigue detenida hasta que alguien la arregla. Te enteras cuando se rompe, no cada mañana hasta que lo hagas. Cuando vuelve a informar, recibes un aviso de recuperación y el incidente se cierra solo.
Como no se solicita nada desde este lado, no hay ninguna conexión entrante que permitir. Una tarea en un servidor de compilación, un portátil, el servidor de un cliente detrás de un NAT corporativo o un contenedor que solo existe noventa segundos informa exactamente igual que una en un servidor público.
Una tarea puede informar de su propia duración añadiéndola al aviso:
INICIO=$(date +%s%3N)
/usr/local/bin/import.sh
curl -fsS "https://owlkeeper.com/ping/TU-TOKEN?ms=$(( $(date +%s%3N) - INICIO ))"
Una tarea que informa de su propia duración obtiene un historial de ella, así que la semana en que empezó a tardar cuatro veces más se ve antes de que empiece a fallar.
El parámetro es opcional. Un aviso sin él es un aviso perfectamente válido.
No. Tu planificador se queda exactamente como está. Esto vigila si lo que debía ejecutarse se ejecutó de verdad, que es una pregunta distinta de si el planificador sigue vivo.
Entonces avisará y no te enterarás. Un latido demuestra que un script llegó a su
última línea, no que hiciera algo que mereciera la pena. Para una copia de
seguridad, lo honesto es un aviso al final del script más una comprobación dentro
de él de que el archivo recién escrito tiene un tamaño plausible, y hacer que el
script falle si no lo tiene, para que el && nunca se dispare.
Pueden, y casi siempre es un error. Cada token es la identidad de una tarea; apuntar dos a la misma significa que cualquiera satisface la ventana de la otra, y la alerta no puede decirte cuál se detuvo.
El token es toda la credencial, así que trátalo como tal. Aparece en tu crontab y en ningún otro sitio: nunca se muestra en una página de estado, y el endpoint tiene un límite de peticiones muy por encima de cualquier frecuencia de cron razonable.
Cualquiera de los dos. curl usa GET por defecto y una tarea que envía su
duración puede preferir POST; se aceptan ambos.