Te recomendamos que pruebes esta resolución en un ambiente controlado antes de enviarlo a producción, un saludo.
Solución:
Solución 1:
Mi enfoque común es así:
- No genere ninguna salida estándar cuando su aplicación cron’ed se complete correctamente.
- 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.
Solucion 2:
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 que sea más fácil para Nagios (Icinga) verificar, por ejemplo, si la última marca de tiempo escrita tiene más de n horas (más cualquier lógica que necesite), sabemos que algo salió mal.
Solucion 3:
Además de lo anterior:
- Llame a “logger” junto con escribir en stderr cuando algo salga mal. Configure syslog para reenviar adicionalmente a un host central, también conocido como “loghost”. (Logger utilizará la función “user.notice” de forma predeterminada, pero puede cambiarla).
Solucion 4:
Hay un par de técnicas que puede 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 los correos cron, puede dirigirlos a un sistema de tickets.
El sistema que propone para registrar información en un lugar “compatible con 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 se puede iniciar en un modo compatible con la red. Por ejemplo, puede configurarlo para que un esclavo pueda iniciar sesión en un maestro:
[[email protected] ~]# echo "hello world from slave" | logger -p local1.info
[[email protected] ~]# 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:
[[email protected] ~]# cat /etc/syslog.conf | grep local1
local1.* @192.168.1.3
[[email protected] ~]# cat /etc/sysconfig/syslog | grep SYSLOGD_OPTIONS
SYSLOGD_OPTIONS="-m 0 -r"
[[email protected] ~]# cat /etc/syslog.conf | grep local
local1.* /var/log/myapp
(La primera línea de configuración redirige local1. * Los avisos de registro a @ 192.168.1.3 (“maestro”). El indicador -r de la segunda línea SYSLOGD_OPIONS activa el soporte de red. Por último, la tercera línea de configuración dirige los mensajes de local1. * Recibidos en “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 verá los registros a menos que algo haya salido mal.
Si elige seguir la ruta del estilo syslog, también considere syslog-ng: http://freshmeat.net/projects/syslog-ng/.
Por supuesto, puede obtener lo mejor de ambas técnicas utilizando ambas. Por ejemplo, sysloging tanto de los fallos como de los éxitos, y simplemente enviando correos para los fallos.
Solucion 5:
Publiqué una respuesta similar a una pregunta en StackOverflow (https://stackoverflow.com/questions/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 menciona el OP en su comentario es la necesidad de estar informado cuando un trabajo comienza a tardar demasiado en ejecutarse.
Tenía la misma necesidad y descubrí que herramientas similares no admitían fácilmente este tipo de supervisión. Cronitor resuelve esto permitiéndole activar opcionalmente un evento de inicio y un evento de finalización para realizar un seguimiento de la duración.
El seguimiento de la duración era imprescindible para mí porque tenía un cronjob que estaba programado cada hora, pero con el tiempo comencé a tardar más de una hora en ejecutarse. ¡Esperamos que te sea útil!
valoraciones y reseñas
Si guardas alguna suspicacia y capacidad de ascender nuestro crónica eres capaz de ejecutar una ilustración y con placer lo analizaremos.