¿Técnicas para monitorear tareas cron?

¿Existen buenas técnicas para monitorear tareas cron en un clúster?

Estamos comenzando a usar cron para iniciar tareas a intervalos diarios. Algunas ideas para verificar la información:

1. Agregue un manejo especial de aplicaciones que registre información en algún lugar "consciente de la red", como un DB
2. Cree un sistema de archivo de registro que transfiera el registro cron periódicamente a un punto central para procesar / consultar (junto con otros posibles archivos de registro)

Me pregunto si la gente ha tenido éxito al hacer cosas por separado para cron frente a otras cosas, o si las tareas se integraron en un enfoque completamente diferente. Me estoy inclinando hacia el # 2, pero me gustaría saber qué personas más experimentadas podrían probar.

Además de las otras respuestas:

• deje que el trabajo escriba una marca de tiempo en un archivo cuando finalice junto con el valor de retorno del trabajo real
• propagar el valor de retorno a la persona que llama original

Usamos el primero para facilitar la verificación de Nagios ( Icinga ), por ejemplo, si la última marca de tiempo escrita es anterior a n horas (más cualquier lógica que necesite), sabemos que algo salió mal.

Mi enfoque común es así:

• No produzca ningún stdout cuando su aplicación cron'ed se complete con éxito.
• No canalice ninguna salida a / dev / null.
• Produzca una salida stderr significativa cuando algo salga mal.
• Establezca una dirección $ MAILTO en el crontab para enviar esa salida de error al equipo requerido.

Además de lo anterior:

• Llame al "registrador" junto con la escritura en stderr cuando algo sale mal. Configure syslog para reenviar adicionalmente a un host central, también conocido como "loghost". (El registrador utilizará la función "user.notice" de forma predeterminada, pero puede cambiarlo).

Hay un par de técnicas que podría usar para monitorear cronjobs.

Para recibir alertas de fallas de cronjob:

• Utilice la función MAILTO = estándar de cron. Si un cronjob produce una salida en STDERR, se enviará por correo a la dirección que elija.
• Para rastrear y manejar correos cron, puede dirigirlos a un sistema de tickets.

El sistema que propone registrar información en un lugar "consciente de la red" suena como syslog . syslog proporciona un método simple para crear registros, normalmente administra archivos como / var / log / messages. Puede realizar personalizaciones básicas, como elegir qué archivos reciben los mensajes de registro.

Syslog puede iniciarse en un modo de reconocimiento de red. Por ejemplo, puede configurarlo para que un esclavo pueda iniciar sesión en un maestro:

[root@slave ~]#  echo "hello world from slave" | logger -p local1.info

[root@master ~]# tail /var/log/myapp
Jun 29 13:07:01 192.168.1.2 logger: hello world from slave

Para una distribución basada en Red Hat, una configuración de ejemplo es la siguiente:

[root@slave ~]# cat /etc/syslog.conf | grep local1
local1.*                                                @192.168.1.3

[root@master ~]# cat /etc/sysconfig/syslog | grep SYSLOGD_OPTIONS
SYSLOGD_OPTIONS="-m 0 -r"

[root@master ~]# cat /etc/syslog.conf | grep local
local1.* /var/log/myapp

(La primera línea de configuración redirige los avisos de registro local1. * A @ 192.168.1.3 ("maestro"). El segundo indicador -r de la línea SYSLOGD_OPIONS activa el soporte de red. Por último, la tercera línea de configuración dirige los mensajes locales1. * Recibidos en el "maestro" en un archivo).

El enfoque de syslog es mejor solo para registrar errores / información. Los archivos de registro tienen menos visibilidad que el correo electrónico, por lo que probablemente no mirará los registros a menos que algo haya salido mal.

Si elige seguir la ruta de estilo syslog, considere también syslog-ng: http://freshmeat.net/projects/syslog-ng/ .

Por supuesto, puede obtener lo mejor de ambas técnicas utilizando ambas. Por ejemplo, syslog'ing tanto fallas como éxitos, y simplemente enviar por correo las fallas.

Publiqué una respuesta similar a una pregunta en StackOverflow ( /programming/21025495/system-for-monitoring-cron-jobs-and-automated-tasks )

Cronitor ( https://cronitor.io ) fue una herramienta que construí exactamente para este propósito. Básicamente se reduce a ser una baliza de seguimiento que utiliza solicitudes http como pings.

Sin embargo, una de las necesidades que el OP menciona en su comentario es la necesidad de ser informado cuando un trabajo comienza a demorarse demasiado.

Tenía la misma necesidad y descubrí que herramientas similares no admitían fácilmente este tipo de monitoreo. Cronitor resuelve esto permitiéndole activar opcionalmente un evento de inicio y un evento de fin para realizar un seguimiento de la duración.

El seguimiento de la duración fue imprescindible para mí porque tenía un cronjob programado cada hora, pero con el tiempo comenzó a tardar más de una hora en ejecutarse. ¡Esperamos que te sea útil!

Todavía está bajo un desarrollo bastante pesado en el momento en que escribo esto, pero me gustaría mirar https://github.com/jamesrwhite/minicron . Fue desarrollado para resolver los problemas que usted describe. Con una ligera modificación en el comando que ejecuta, puede registrar el estado de salida y salida de los trabajos y enviar esos datos de vuelta a un servidor central en tiempo real y puede enviar alertas por correo electrónico, SMS y PagerDuty cuando falla un trabajo (estado de salida> 0) o no se ejecuta cuando debería.

Descargo de responsabilidad: soy el desarrollador trabajando en ello.

Esto parece un caso de uso clásico para AlertGrid .

No requiere instalación, todo lo que necesita hacer para aprovechar los beneficios de esta herramienta es:

1. envíe la señal a AlertGrid cada vez que su trabajo cron termine su trabajo (esto puede hacerse mediante API extremadamente simple, la señal es solo una solicitud HTTP). También puede enviar algunos parámetros como execution_time!
2. configurar reglas de notificación como las siguientes:

si my_job no respondió en X minutos (horas en su caso) -> envíe SMS al administrador

o

if execute_time> 60 segundos -> envíe un correo electrónico a las personas interesadas

En realidad eso es todo. Puede administrar las reglas de notificación con un agradable editor visual. No tiene que modificar el código fuente o algunos archivos de configuración si algo cambió. Es una solución centralizada, por lo que puede beneficiarse de la gestión de reglas desde un solo lugar.

Espero que esto ayude a alguien. Se proporciona una cuenta gratuita para que pueda probar y usar AlertGrid si está interesado. Soy uno de los miembros del equipo de AlertGrid. No dude en preguntar si tiene alguna pregunta.

Sus trabajos cron ya están registrados a través de syslog. Esos datos pueden enviarse a un servidor central utilizando syslogd, otro servicio estándar.

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ tiene detalles sobre cómo configurar esto.

Yo uso http://cronrat.com simplemente agregue && curl "... su cronrat url" a sus trabajos cron. La mejor característica que me gusta es que no necesita configurar nada después de crear la cuenta inicial. Cada alerta está en funcionamiento en el momento en que la usa. por lo tanto, puedo usar cualquier herramienta automatizada para comenzar mi trabajo que aún no existe, a diferencia de algunos servicios donde primero necesito configurar el trabajo.

He creado Power Cron después de estas necesidades precisas. Necesitaba una vista centralizada de mis trabajos cron y una noción de dependencia entre los trabajos de diferentes miembros del clúster.

También necesitaba más información de la que podía encontrar en los registros, y agregué perfiles de trabajo.

Creamos PushMon, http://www.pushmon.com , para esto. Digamos que su trabajo diario se ejecuta a las 3 a.m. y normalmente termina a las 4 a.m. Puede configurar un horario PushMon de "antes de las 4:00 AM todos los días". O un horario un poco más avanzado como "antes de las 4:00 a.m. todos los días en 1 hora" Todo lo que necesita hacer es "hacer ping" a la URL de PushMon cada vez que se ejecuta su trabajo, y lo alertará de los pings faltantes. Si sabe con certeza que ha ocurrido un error, como cuando detecta una excepción que no puede manejar, puede usar la función de alerta a pedido.

Healthchecks ( https://github.com/healthchecks/healthchecks/ ) es un servicio y tablero de instrumentos construido exactamente para monitorear trabajos cron. Se está utilizando en producción, se mantiene y acepta contribuciones de código.

Funciona de manera similar a Cronitor, Dead Man's Snitch y amigos: configura su trabajo cron para hacer una solicitud HTTP / HTTPS a una URL especial y única justo antes de que finalice. Healthchecks recibe y registra estos pings. Comprueba constantemente si los pings llegan a los intervalos esperados. Cuando detecta un problema, le envía una notificación. Los métodos de notificación admitidos son correo electrónico, webhooks, Slack, Telegram, Discord, SMS, Pushover, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

Puede configurar todo esto y hospedarse usted mismo, pero, como con cualquier servicio web, se requiere un esfuerzo para configurar el nombre de dominio, el certificado, configurar el proxy inverso HTTP, configurar copias de seguridad de la base de datos, etc. Una forma razonablemente fácil de obtener correr es usar esta versión adaptada de Heroku: https://github.com/iphoting/healthchecks . Sé de personas que ejecutan este proyecto ellos mismos y lo usan para monitorear cientos de servicios.

Descargo de responsabilidad: soy el autor y también ejecuto Healthchecks como un servicio alojado en https://healthchecks.io