Alertes d'Échec de Cron

Un cron qui échoue représente un risque métier direct. Contrairement au cron silencieux qui cesse de s'exécuter, le cron en échec s'exécute bien mais rencontre un problème : exception non gérée, timeout, ressource indisponible. Sans alerting approprié, ces échecs passent inaperçus pendant des heures, voire des jours.

Les conséquences d'un échec non détecté varient selon la criticité du cron : backup incomplet, données client non synchronisées, rapports non générés, factures non envoyées. Chaque minute de retard dans la détection augmente l'impact potentiel et complique la résolution.

MoniTao offre deux mécanismes complémentaires pour détecter les échecs : l'absence de ping (le cron ne signale pas son succès) et l'endpoint /fail (le cron signale explicitement son échec). Ensemble, ils garantissent une couverture complète des scénarios de défaillance.

Types d'Échecs de Cron

Les échecs de cron se manifestent de différentes manières, chacune nécessitant une approche de détection adaptée :

• Échec avec code de retour : Le script termine avec exit 1 ou un code non-zéro. Le plus facile à détecter car explicite. Utilisez && pour conditionner le ping au succès.
• Exception non capturée : Une erreur dans le code (PHP, Python, etc.) interrompt l'exécution. Le script ne termine pas proprement, donc pas de ping de succès.
• Timeout : Le cron dépasse son temps d'exécution normal et est interrompu par le système. Le ping de fin n'est jamais envoyé.
• Échec partiel : Le script termine avec succès (exit 0) mais une partie de la logique métier a échoué. Plus difficile à détecter sans validation explicite.

Causes Fréquentes d'Échec

Comprendre les causes communes permet de mieux anticiper et diagnostiquer les problèmes :

• Ressources épuisées : Disque plein, mémoire insuffisante, connexions database saturées. Le cron démarre mais ne peut pas terminer son travail.
• Dépendances externes : API tierce en panne, service cloud indisponible, firewall bloquant. Le cron est fonctionnel mais ses dépendances ne le sont pas.
• Données invalides : Fichier d'entrée corrompu, format inattendu, données manquantes. Le cron reçoit des données qu'il ne peut pas traiter.
• Problèmes de concurrence : Locks de base de données, conflits avec d'autres processus, deadlocks. Le cron attend indéfiniment une ressource.

Stratégies de Détection des Échecs

MoniTao propose plusieurs approches pour détecter les échecs de cron :

• Ping conditionnel (&&) : Le plus simple : ./script.sh && curl URL. Le ping n'est envoyé que si le script retourne 0. Tout échec = pas de ping = alerte.
• Endpoint /fail explicite : Appelez /fail au lieu de /ping quand vous détectez un problème dans votre script. L'alerte est immédiate, sans attendre le timeout.
• Wrapper script : Un script enveloppe qui capture les erreurs, les log, et signale le statut approprié à MoniTao. Réutilisable pour tous vos crons.
• Validation métier : Au-delà du code de retour, validez que la logique métier a fonctionné (nombre d'enregistrements, fichiers créés) avant de ping succès.

Wrapper Script Complet

Voici un wrapper shell robuste qui gère tous les scénarios d'échec :

#!/bin/bash
# wrapper.sh - Wrapper universel pour crons avec MoniTao
# Usage: ./wrapper.sh "commande" "https://api.monitao.com/ping/token"

COMMAND=$1
MONITAO_URL=$2
LOG_FILE="/var/log/cron/$(date +%Y%m%d_%H%M%S).log"

# Exécuter la commande et capturer la sortie
echo "[$(date)] Démarrage: $COMMAND" >> "$LOG_FILE"
$COMMAND >> "$LOG_FILE" 2>&1
EXIT_CODE=$?
echo "[$(date)] Terminé avec code: $EXIT_CODE" >> "$LOG_FILE"

# Signaler à MoniTao selon le résultat
if [ $EXIT_CODE -eq 0 ]; then
    curl -fsS --max-time 10 "$MONITAO_URL" \
        -d "{\"status\": \"success\", \"duration\": \"$(tail -1 $LOG_FILE)\"}" \
        -H "Content-Type: application/json"
else
    # Remplacer /ping par /fail dans l'URL
    FAIL_URL=$(echo "$MONITAO_URL" | sed 's/\/ping\//\/fail\//')
    curl -fsS --max-time 10 "$FAIL_URL" \
        -d "{\"status\": \"failed\", \"exit_code\": $EXIT_CODE}" \
        -H "Content-Type: application/json"
fi

exit $EXIT_CODE

Ce wrapper capture la sortie du cron dans un fichier log, vérifie le code de retour, et signale le statut approprié à MoniTao. En cas d'échec, il utilise l'endpoint /fail pour une alerte immédiate. Utilisez-le ainsi dans votre crontab : 0 * * * * /path/to/wrapper.sh "/path/to/script.sh" "URL"

Configuration des Alertes

Optimisez vos alertes pour une réponse efficace aux échecs :

• Alerte immédiate sur /fail : L'endpoint /fail déclenche une alerte instantanée, sans attendre le timeout. Idéal pour les échecs critiques nécessitant une intervention rapide.
• Délai sur absence de ping : Si le cron ne ping pas, l'alerte arrive après l'intervalle + période de grâce. Configurez une grâce courte pour les crons critiques.
• Escalade des alertes : Configurez des niveaux d'escalade : email immédiat, puis Slack après 15 minutes sans réponse, puis SMS après 1 heure.
• Contexte de l'alerte : Incluez des informations utiles dans le payload /fail (code d'erreur, message, dernières lignes de log) pour faciliter le diagnostic.

Bonnes Pratiques de Gestion des Échecs

Adoptez ces pratiques pour une gestion robuste des échecs de cron :

• set -e dans bash : Ajoutez set -e en début de script pour arrêter l'exécution à la première erreur. Empêche l'exécution partielle et les états incohérents.
• Try/catch applicatif : Dans les scripts PHP, Python, etc., encapsulez la logique dans un try/catch global. Capturez l'exception, loguez-la, et signalez /fail.
• Logs systématiques : Loguez le début, la fin, et les étapes clés de chaque cron. En cas d'échec, les logs permettent de localiser rapidement le problème.
• Tests de non-régression : Testez régulièrement vos alertes en forçant un échec. Vérifiez que l'alerte arrive dans le délai attendu et contient les informations utiles.

Questions Fréquentes

Réagir Rapidement aux Échecs

Les échecs de cron sont inévitables : dépendances externes, ressources épuisées, données invalides. Ce qui fait la différence, c'est la vitesse de détection et de réaction. Un échec détecté en 5 minutes peut souvent être corrigé avant tout impact utilisateur. Un échec détecté après 24 heures laisse des traces durables.

Combinez le ping conditionnel (&&) pour les échecs implicites avec l'endpoint /fail pour les échecs explicites. Encapsulez vos crons dans un wrapper qui log, détecte, et signale. Avec MoniTao, transformez chaque échec en opportunité d'amélioration rapide plutôt qu'en incident client.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs