Techniques pour surveiller les tâches cron?

Existe-t-il de bonnes techniques pour surveiller les tâches cron sur un cluster?

Nous commençons à utiliser cron pour lancer des tâches à intervalles quotidiens. Quelques idées pour vérifier les informations:

1. Ajoutez une gestion d'application spéciale qui enregistre les informations dans un endroit "sensible au réseau", comme une base de données
2. Construire un système de fichier journal qui transfère périodiquement le journal cron à un point central pour le traitement / interrogation (avec d'autres fichiers journaux possibles)

Je me demande si les gens ont réussi à faire les choses séparément pour cron par rapport à d'autres choses, ou si les tâches ont été complètement intégrées dans une approche différente. Je penche vers le n ° 2, mais j'aimerais savoir ce que des gens plus expérimentés pourraient essayer.

En plus des autres réponses:

• laisser le travail écrire un horodatage dans un fichier lorsqu'il se termine avec la valeur de retour du travail réel
• propager la valeur de retour à l'appelant d'origine

Nous utilisons le premier pour faciliter la vérification par Nagios ( Icinga ), par exemple si le dernier horodatage écrit est plus ancien que n heures (plus la logique dont vous avez besoin) - nous savons que quelque chose s'est mal passé.

Mon approche commune est donc:

• Ne produisez pas de sortie standard lorsque votre application cron se termine avec succès.
• Ne dirigez aucune sortie vers / dev / null.
• Produisez une sortie stderr significative en cas de problème.
• Définissez une adresse $ MAILTO dans la crontab pour envoyer cette sortie d'erreur à l'équipe requise.

En plus de ce qui précède:

• Appelez "logger" et écrivez à stderr lorsque quelque chose ne va pas. Configurez syslog pour transférer en plus vers un hôte central, alias "loghost". (Logger utilisera la fonction "user.notice" par défaut, mais vous pouvez la changer.)

Il existe quelques techniques que vous pouvez utiliser pour surveiller les tâches cron.

Pour recevoir des alertes d'échecs de cronjob:

• Utilisez la fonction standard MAILTO = de cron. Si un cronjob produit une sortie sur STDERR, il sera envoyé à l'adresse de votre choix.
• Pour suivre et traiter les e-mails cron, vous pouvez les diriger vers un système de ticket.

Le système que vous proposez de consigner des informations dans un endroit "sensible au réseau" ressemble à syslog . syslog fournit une méthode simple pour créer des journaux, il gère normalement des fichiers tels que / var / log / messages. Vous pouvez effectuer des personnalisations de base, comme choisir les fichiers qui recevront les messages de journal.

Syslog peut être démarré dans un mode compatible réseau. Par exemple, vous pouvez le configurer pour qu'un esclave puisse se connecter à un maître:

[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

Pour une distribution basée sur Red Hat, un exemple de configuration est le suivant:

[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 première ligne de configuration redirige les notifications de journal local1. * Vers @ 192.168.1.3 ("master"). Le deuxième indicateur -r de la ligne SYSLOGD_OPIONS active la prise en charge du réseau. Enfin, la troisième ligne de configuration dirige les messages local1. * Reçus sur "master" dans un fichier).

L'approche syslog est meilleure uniquement pour les erreurs / informations de journalisation. Les fichiers journaux ont moins de visibilité que les e-mails, vous ne pourrez donc probablement pas consulter les journaux à moins que quelque chose se soit mal passé.

Si vous choisissez de suivre la route de style syslog, pensez également à syslog-ng: http://freshmeat.net/projects/syslog-ng/ .

Bien sûr, vous pouvez tirer le meilleur parti des deux techniques en utilisant les deux. Par exemple, syslog, à la fois les échecs et les succès, et juste l'envoi de messages d'échecs.

J'ai posté une réponse similaire à une question sur StackOverflow ( /programming/21025495/system-for-monitoring-cron-jobs-and-automated-tasks )

Cronitor ( https://cronitor.io ) était un outil que j'ai construit exactement à cet effet. Cela se résume à être une balise de suivi qui utilise les requêtes http comme pings.

Cependant, l'un des besoins que l'OP mentionne dans son commentaire doit être informé lorsqu'un travail commence à prendre trop de temps à exécuter.

J'avais ce même besoin et j'ai constaté que des outils similaires ne prenaient pas facilement en charge ce type de surveillance. Cronitor résout ce problème en vous permettant de déclencher éventuellement un événement de début et un événement de fin afin de garder une trace de la durée.

Le suivi de la durée était un must have pour moi car j'avais un cronjob qui était programmé toutes les heures, mais avec le temps, j'ai commencé à prendre plus d'une heure à exécuter. J'espère que vous le trouverez utile!

Il est encore en développement assez lourd au moment où j'écris ceci, mais j'encourage à jeter un œil à https://github.com/jamesrwhite/minicron . Il a été développé pour résoudre les problèmes que vous décrivez. Avec une légère modification de la commande que vous exécutez, il peut enregistrer l'état de sortie et de sortie des travaux et renvoie ces données à un serveur central en temps réel et peut envoyer des alertes par e-mail, SMS et PagerDuty lorsqu'un travail échoue (état de sortie> 0) ou ne s'exécute pas quand il le devrait.

Avertissement: je suis le développeur qui y travaille.

Cela ressemble à un cas d'utilisation classique pour AlertGrid .

Il ne nécessite pas d'installation, tout ce que vous devez faire pour profiter de cet outil est de:

1. envoyez Signal à AlertGrid chaque fois que votre tâche cron a terminé son travail (cela peut être fait par une API extrêmement simple, le signal est juste une requête HTTP). Vous pouvez également envoyer des paramètres comme execution_time!
2. configurer des règles de notification comme suit:

si my_job n'a pas répondu dans X minutes (heures dans votre cas) -> envoyer un SMS à l'administrateur

ou

si execution_time> 60 secondes -> envoyer un e-mail aux personnes intéressées

En fait, c'est tout. Vous pouvez gérer les règles de notification à l'aide d'un bel éditeur visuel. Vous n'avez pas à modifier le code source ou certains fichiers de configuration si quelque chose a changé. C'est une solution centralisée, vous pouvez donc bénéficier de la gestion des règles à partir d'un seul endroit.

J'espère que cela aide quelqu'un. Un compte gratuit est fourni afin que vous puissiez tester et utiliser AlertGrid si vous êtes intéressé. Je fais partie de l'équipe AlertGrid - n'hésitez pas à demander si vous avez des questions.

Vos tâches cron sont déjà enregistrées via syslog. Ces données peuvent être envoyées à un serveur central à l'aide de syslogd, un autre service standard.

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ a des détails sur la façon de configurer cela.

j'utilise http://cronrat.com ajoutez simplement && curl "... votre URL cronrat" à vos tâches cron. La meilleure fonctionnalité que j'aime est que vous n'avez rien à configurer après avoir créé un compte initial. Chaque alerte est opérationnelle dès la minute où vous l'utilisez. par conséquent, je peux utiliser des outils automatisés pour démarrer mes travaux qui n'existent pas encore, contrairement à certains services où je dois d'abord configurer le travail.

J'ai créé Power Cron après ces besoins précis. J'avais besoin d'une vue centralisée sur mes tâches cron et d'une notion de dépendance entre les tâches des différents membres du cluster.

J'avais également besoin de plus d'informations que ce que je pouvais trouver dans les journaux et d'un profil de travail supplémentaire.

Nous avons construit PushMon, http://www.pushmon.com , pour cela. Supposons que votre travail quotidien se déroule à 3 heures du matin et se termine normalement à 4 heures du matin. Vous pouvez configurer un programme PushMon de "avant 4 h 00 tous les jours". Ou un horaire un peu plus avancé comme "avant 4 h 00 tous les jours en 1 heure". Tout ce que vous avez à faire est de "cingler" l'URL PushMon à chaque exécution de votre travail, et il vous alertera des pings manquants. Si vous savez avec certitude qu'une erreur s'est produite, comme lorsque vous détectez une exception que vous ne pouvez pas gérer, vous pouvez utiliser la fonction d'alerte à la demande.

Healthchecks ( https://github.com/healthchecks/healthchecks/ ) est un service et un tableau de bord conçus exactement pour surveiller les tâches cron. Il est utilisé en production, est maintenu et accepte les contributions de code.

Il fonctionne de la même manière que Cronitor, Dead Man's Snitch et ses amis: vous configurez votre tâche cron pour effectuer une demande HTTP / HTTPS vers une URL spéciale et unique juste avant la fin. Healthchecks reçoit et enregistre ces pings. Il vérifie constamment si les pings arrivent aux intervalles attendus. Lorsqu'il détecte un problème, il vous envoie une notification. Les méthodes de notification prises en charge sont le courrier électronique, les webhooks, Slack, Telegram, Discord, SMS, Pushover, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

Vous pouvez tout configurer et vous héberger, mais, comme avec tout service Web, il faut un certain effort pour configurer le nom de domaine, le certificat, configurer le proxy inverse HTTP, configurer des sauvegardes de base de données, etc. Un moyen raisonnablement facile d'obtenir courir consiste à utiliser cette version adaptée à Heroku: https://github.com/iphoting/healthchecks . Je connais des gens qui gèrent eux-mêmes ce projet et l'utilisent pour surveiller des centaines de services.

Avertissement: je suis l'auteur et j'exécute également Healthchecks en tant que service hébergé sur https://healthchecks.io