Surveiller une tâche cron ou un script

Gardez un œil sur les scripts de sauvegarde, les tâches cron et les tâches planifiées qui doivent s’exécuter selon un horaire — et soyez alerté dès que l’une d’elles cesse silencieusement de fonctionner. Cet article s’adresse à toute personne qui dépend de l’exécution régulière d’une tâche et souhaite savoir si ce n’est pas le cas.

#Vue d’ensemble

• La plupart des moniteurs contactent quelque chose chez vous pour le vérifier. Un moniteur heartbeat fonctionne dans l’autre sens : votre tâche appelle InfraNest à chaque fois qu’elle se termine.
• Si l’appel n’arrive pas à temps, InfraNest vous alerte — c’est le moyen de détecter une tâche qui a cessé de s’exécuter silencieusement.
• Vous pouvez configurer cela automatiquement si l’agent InfraNest tourne sur le serveur, ou manuellement pour tout le reste, y compris les workflows GitHub Actions.

#Surveiller une tâche cron sur un serveur avec l’agent

Si l’agent InfraNest tourne sur le serveur, vous n’avez rien à configurer manuellement :

1. Ouvrez le serveur et allez dans Workloads. Sous Scheduled jobs, vous verrez chaque tâche cron et chaque timer systemd présent — quand chacune s’exécute, en tant que quel utilisateur, et quand elle s’exécutera la prochaine fois.
2. À côté d’une de vos tâches, sélectionnez Watch this job. InfraNest crée immédiatement le moniteur heartbeat, en attendant la tâche aussi souvent que son horaire l’indique, avec une heure de tolérance pour une tâche nocturne.
3. Modifiez une ligne sur le serveur : placez infranest-agent run --job "NAME" -- devant la commande. InfraNest vous montre la ligne avant et après. Par exemple :

# avant
15 3 * * * root /opt/acme/backup.sh
# après
15 3 * * * root infranest-agent run --job "Nightly backup" -- /opt/acme/backup.sh

C’est tout. Votre tâche s’exécute exactement comme avant, en tant que le même utilisateur, et se termine avec son propre code de sortie. Après chaque exécution, l’agent indique à InfraNest quand elle a commencé, combien de temps elle a pris et comment elle s’est terminée — aucun jeton ne figure dans votre crontab.

• En cas d’échec, le moniteur passe en panne et sa page affiche le code de sortie ainsi que les 20 dernières lignes de la sortie de la tâche, avec les mots de passe et les clés masqués. Ajoutez --no-output pour n’envoyer que le code de sortie.
• Si elle ne s’exécute pas du tout, le moniteur passe en panne une fois le délai de grâce écoulé, comme pour tout heartbeat.
• InfraNest ne modifie jamais votre crontab. L’agent se contente de le lire.

NoteInfraNest n’affiche la ligne complète que si vous avez activé les lignes de commande pour le serveur, car les lignes cron contiennent souvent des mots de passe. Sinon, il n’affiche que la partie à placer devant votre commande.

Les crontabs propres à vos utilisateurs ne sont pas listées : seul root peut les lire, et l’agent ne s’exécute jamais en tant que root. Les tâches dans /etc/crontab, /etc/cron.d et les dossiers cron.daily, hourly, weekly et monthly le sont. Un script dans l’un de ces dossiers, ou un timer systemd, ne peut pas être encapsulé de cette façon — utilisez plutôt l’URL de ping ci-dessous.

Si Scheduled jobs indique que l’agent n’a pas de dossier pour les rapports de tâches, relancez l’installeur de l’agent avec --upgrade ; il crée le dossier dans lequel les rapports sont déposés.

Si une fenêtre de maintenance doit démarrer pendant qu’une tâche est en cours d’exécution, Scheduled jobs vous avertit et propose de déplacer la fenêtre après celle-ci.

#En configurer un manuellement

1. Allez dans Monitors et sélectionnez Add.
2. Choisissez Heartbeat / Cron monitor comme type.

3. Donnez-lui un nom que vous reconnaîtrez dans une alerte — « Sauvegarde nocturne de la base de données » vaut mieux que « tâche 1 ».
4. Réglez l’intervalle de vérification sur la fréquence à laquelle la tâche est censée s’exécuter.
5. Réglez une période de grâce — le temps supplémentaire qu’InfraNest accorde avant de la considérer en retard. Une sauvegarde qui prend habituellement quatre minutes mais parfois huit a besoin d’une période de grâce confortablement supérieure à ce dépassement.
6. Sélectionnez Create.

Vous ne saisissez pas d’URL pour ce type — InfraNest en crée une pour vous lors de l’enregistrement.

#Faire en sorte que votre tâche se signale

Ouvrez le moniteur et vous verrez son URL de ping, ainsi qu’une ligne de commande prête à coller. Ajoutez cette ligne à la fin de votre script ou de votre tâche cron, afin qu’elle ne s’exécute que si la tâche a réellement réussi :

0 3 * * *  /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://your-infranest-url/api/heartbeat/your-uuid

Le && est important : il signifie que l’appel n’a lieu que si la sauvegarde elle-même s’est terminée avec succès. Une tâche en échec reste alors silencieuse, et c’est ce silence qui déclenche l’alerte.

Utilisez Copier plutôt que de ressaisir l’URL — l’identifiant qu’elle contient est propre à ce moniteur.

#Signaler la durée d’exécution de la tâche

Ajoutez ?duration= suivi de la durée d’exécution de la tâche en secondes à l’URL de ping, et le moniteur affichera Last run took à côté du dernier ping. Une tâche qui prend progressivement plus de temps chaque nuit devient alors facile à repérer avant qu’elle ne dépasse sa période de grâce. Par exemple, dans un script :

start=$(date +%s)
/usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 "https://your-infranest-url/api/heartbeat/your-uuid?duration=$(( $(date +%s) - start ))"

Les décimales sont acceptées (?duration=4.25). Si la valeur n’est pas un nombre, l’appel compte quand même — seule la durée d’exécution est omise.

#Depuis un workflow GitHub Actions

Si votre sauvegarde, votre renouvellement ou votre synchronisation nocturne s’exécute comme un workflow GitHub Actions planifié, le même moniteur fonctionne — le workflow appelle en dernière étape.

1. Dans votre dépôt sur GitHub, ouvrez Settings → Secrets and variables → Actions et ajoutez un secret de dépôt nommé HEARTBEAT_URL, avec l’URL de ping comme valeur.
2. Ajoutez cette étape à la fin de la tâche :

      - name: Check in with InfraNest
        run: curl -fsS -m 10 --retry 3 "$HEARTBEAT_URL"
        env:
          HEARTBEAT_URL: ${{ secrets.HEARTBEAT_URL }}

GitHub ignore les étapes restantes dès que l’une d’elles échoue, donc l’appel n’a lieu que si tout ce qui le précède a réussi — le même effet que le && ci-dessus.

Cela permet aussi de détecter quelque chose que GitHub ne signale pas clairement : dans un dépôt public, GitHub désactive les workflows planifiés après 60 jours sans aucune activité dans le dépôt. Le workflow cesse de s’exécuter, rien n’échoue, et c’est l’absence d’appel qui déclenche l’alerte.

TipGitHub peut démarrer les workflows planifiés avec plusieurs minutes de retard lorsqu’il est très sollicité. Accordez au moniteur une période de grâce qui tienne compte de cela en plus de la durée d’exécution propre de la tâche.

#Ce qui se passe ensuite

• Chaque appel marque le moniteur Actif et enregistre l’heure comme son dernier ping.
• Un moniteur tout juste créé reste en attente jusqu’à ce que sa première fenêtre soit passée, ce qui vous laisse le temps de connecter l’appel sans être alerté à ce sujet.
• Si rien n’arrive dans l’intervalle plus la période de grâce, le moniteur passe en panne et ouvre un incident, ce qui déclenche vos destinations d’alerte habituelles.
• L’appel suivant résout l’incident et vous alerte qu’il est de retour — vous n’avez pas à le fermer manuellement.

#Astuces

• Mettre en pause un moniteur heartbeat est sans risque : l’URL de ping continue de répondre normalement, donc une tâche qui l’appelle encore ne commencera pas à signaler des échecs. InfraNest arrête simplement de surveiller jusqu’à ce que vous repreniez.
• Traitez l’URL de ping comme un secret. Quiconque la possède peut signaler votre tâche comme fonctionnelle — ce qui masquerait un véritable échec.

#Dépannage

• Aucun ping reçu pour l’instant sur le moniteur signifie qu’InfraNest n’a reçu aucun signal de la tâche. Exécutez la ligne curl manuellement depuis la même machine : si cela fait passer le moniteur au vert, le problème vient de votre script, pas d’ici.
• Si la machine ne peut pas accéder à Internet en sortie, l’appel ne peut pas arriver — autorisez le HTTPS sortant vers InfraNest.
• Un moniteur qui alerte chaque nuit à la même heure a généralement une période de grâce plus courte que le pire temps d’exécution réel de la tâche.