Heartbeat Monitoring pour Applications

Le heartbeat (qu'on pourrait traduire, littéralement - mais pas très élégamment - par « ping de vie ») est un mécanisme de surveillance qui repose sur un principe simple mais puissant : votre application envoie régulièrement un signal à un service de monitoring pour prouver qu'elle est vivante et fonctionne correctement. L'absence de ce signal déclenche une alerte, permettant de détecter des pannes qui passeraient autrement inaperçues.

Contrairement au monitoring HTTP classique qui teste la disponibilité d'une URL depuis l'extérieur, le heartbeat est émis depuis l'intérieur de votre application. Cette approche "inside-out" permet de surveiller des processus qui n'exposent pas d'interface HTTP : crons, workers de queue, scripts batch, synchronisations de données. Si le processus ne s'exécute pas ou plante avant de terminer, aucun ping n'est envoyé et vous êtes alerté.

Cette technique est particulièrement efficace pour les processus qui s'exécutent périodiquement et dont l'échec peut passer inaperçu pendant des jours : sauvegardes automatiques, imports de données, génération de rapports, nettoyage de fichiers temporaires. Le heartbeat garantit que vous serez alerté si un de ces processus critiques cesse de fonctionner.

Comment Fonctionne le Heartbeat

Le mécanisme du heartbeat repose sur quatre composants qui travaillent ensemble pour garantir une surveillance fiable de vos processus.

• Signal périodique : Votre application ou script envoie un simple appel HTTP (GET ou POST) à une URL unique fournie par MoniTao. Ce signal peut être envoyé à intervalle fixe (toutes les minutes pour un service) ou après chaque exécution réussie (pour un cron quotidien).
• Attente configurée : MoniTao connaît la fréquence attendue de vos pings. Si vous configurez un heartbeat quotidien, le système attend un ping toutes les 24 heures. Une période de grâce configurable permet d'absorber les variations normales de timing.
• Détection d'absence : Si le ping n'arrive pas dans le délai configuré (intervalle + période de grâce), MoniTao passe le job en statut "late", puis "failed". C'est l'absence de signal qui déclenche l'alerte, pas une erreur active.
• Alerte immédiate : Dès que le statut passe en "failed", vous recevez une notification via vos canaux configurés : email, SMS, webhook, Slack. L'alerte indique le nom du job, l'heure du dernier ping, et le retard constaté.

Quand Envoyer le Heartbeat

Le positionnement du ping dans votre code est crucial pour garantir une surveillance efficace. Voici les différentes situations et les bonnes pratiques associées.

• Fin d'exécution réussie : Le cas le plus courant est d'envoyer le ping à la toute fin d'un job ou script, uniquement si l'exécution s'est terminée avec succès. Placez l'appel après toutes les opérations critiques et après la vérification du résultat. Si une erreur survient, le ping n'est pas envoyé et vous êtes alerté.
• Boucle de service : Pour un service long-running (worker de queue, daemon), envoyez un ping à intervalle fixe (toutes les 1-5 minutes) dans la boucle principale. Cela prouve que le service est vivant et traite des messages. Si le processus se bloque ou meurt, les pings cessent.
• Après validation métier : Pour certains jobs, l'exécution technique peut réussir mais le résultat métier être incorrect (0 enregistrements traités, fichier vide généré). Ajoutez une validation avant le ping : vérifiez que des données ont bien été traitées, que le fichier de backup a une taille raisonnable.
• Jobs avec démarrage conditionnel : Certains jobs ne s'exécutent que si une condition est remplie (données à traiter, heure spécifique). Dans ce cas, pingez même quand il n'y a rien à faire - cela prouve que le job s'est exécuté et a vérifié la condition. Sinon, vous ne saurez pas distinguer "pas de travail" de "job pas lancé".

Exemples d'Intégration par Langage

Voici des exemples complets d'intégration du heartbeat dans différents langages et contextes. Tous les exemples incluent une gestion des erreurs appropriée et des bonnes pratiques.

Bash / Shell (Crontab)

#!/bin/bash
# Backup script avec heartbeat

PING_URL="https://ping.monitao.com/p/VOTRE_TOKEN"

# Exécuter le backup
/usr/bin/mysqldump -u root -p'password' mydb > /backup/db.sql
RESULT=$?

# Ping uniquement si le backup a réussi
if [ $RESULT -eq 0 ]; then
    # Vérifier que le fichier n'est pas vide
    if [ -s /backup/db.sql ]; then
        curl -fsS --retry 3 --max-time 10 "$PING_URL" > /dev/null
        echo "Backup OK, ping envoyé"
    else
        echo "Fichier backup vide, pas de ping"
        exit 1
    fi
else
    echo "Erreur backup, pas de ping"
    exit 1
fi

Ce script vérifie non seulement le code de retour de mysqldump mais aussi que le fichier généré n'est pas vide. Le curl utilise --retry 3 pour réessayer en cas d'échec réseau temporaire, et --max-time 10 pour éviter de bloquer indéfiniment.

PHP (Laravel / Symfony)

generateReports();

            // Validation: au moins quelques rapports générés
            if ($count === 0) {
                $this->warn('Aucun rapport généré');
                // On ping quand même car le job s'est exécuté
            }

            // Ping avec métriques
            Http::timeout(10)->retry(3)->post(
                'https://ping.monitao.com/p/VOTRE_TOKEN',
                ['duration' => $this->executionTime, 'count' => $count]
            );

            $this->info("Terminé: {$count} rapports");

        } catch (\Exception $e) {
            report($e);
            // Pas de ping = alerte MoniTao
            return 1;
        }
    }
}

L'exemple Laravel utilise le client HTTP intégré avec retry automatique. Les métriques (durée, nombre d'éléments) sont envoyées avec le ping pour un monitoring enrichi. L'exception interrompt le script avant le ping.

Python

import requests
import sys
from datetime import datetime

PING_URL = "https://ping.monitao.com/p/VOTRE_TOKEN"

def ping_monitao(duration_ms=None, status="success"):
    """Envoie un ping à MoniTao avec retry"""
    payload = {"status": status}
    if duration_ms:
        payload["duration"] = duration_ms

    for attempt in range(3):
        try:
            response = requests.post(
                PING_URL,
                json=payload,
                timeout=10
            )
            if response.ok:
                return True
        except requests.RequestException:
            continue
    return False

def main():
    start = datetime.now()
    try:
        # Votre logique métier
        process_data()
        sync_database()
        generate_reports()

        # Calcul durée et ping
        duration = (datetime.now() - start).total_seconds() * 1000
        ping_monitao(duration_ms=duration)
        print(f"Terminé en {duration:.0f}ms")

    except Exception as e:
        print(f"Erreur: {e}", file=sys.stderr)
        # Pas de ping = alerte
        sys.exit(1)

if __name__ == "__main__":
    main()

Le script Python inclut une fonction réutilisable avec retry intégré. La durée d'exécution est calculée et envoyée avec le ping, permettant de suivre les tendances de performance dans l'historique MoniTao.

Node.js

const https = require('https');

const PING_URL = 'https://ping.monitao.com/p/VOTRE_TOKEN';

async function pingMonitao(metrics = {}) {
    return new Promise((resolve) => {
        const data = JSON.stringify(metrics);
        const url = new URL(PING_URL);

        const req = https.request({
            hostname: url.hostname,
            path: url.pathname,
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'Content-Length': data.length
            },
            timeout: 10000
        }, (res) => resolve(res.statusCode < 400));

        req.on('error', () => resolve(false));
        req.write(data);
        req.end();
    });
}

async function main() {
    const start = Date.now();
    try {
        await processQueue();
        await syncData();

        const duration = Date.now() - start;
        await pingMonitao({ duration, items: processedCount });
        console.log(`Done in ${duration}ms`);

    } catch (error) {
        console.error('Error:', error.message);
        process.exit(1);
    }
}

main();

L'exemple Node.js utilise le module https natif sans dépendance externe. La fonction pingMonitao retourne une promesse et peut être facilement intégrée dans n'importe quel script async/await.

Bonnes Pratiques d'Implémentation

Ces recommandations vous aideront à tirer le meilleur parti du heartbeat tout en évitant les pièges courants.

• Pingez à la fin, pas au début : Le ping doit toujours être la dernière action de votre script, après toutes les opérations critiques. Pinger au début ou au milieu donne une fausse assurance : le job peut échouer après le ping sans que vous soyez alerté.
• Gérez les timeouts : Ajoutez toujours un timeout à votre appel HTTP (5-10 secondes). Un problème réseau ne doit pas bloquer votre script principal. Si le ping échoue après les retries, loggez l'erreur mais laissez le script terminer normalement.
• Utilisez les retries : Un problème réseau temporaire peut faire échouer le ping. Configurez 2-3 retries automatiques avec un court délai entre chaque tentative. Cela améliore considérablement la fiabilité sans impact significatif sur la durée.
• Envoyez des métriques : Profitez du ping pour envoyer des données utiles : durée d'exécution, nombre d'éléments traités, statut détaillé. Ces métriques enrichissent l'historique et permettent de détecter des dégradations progressives.
• Testez le système complet : Après l'intégration, testez toute la chaîne : exécutez le script manuellement, vérifiez que le ping apparaît dans MoniTao, puis arrêtez le script et vérifiez que l'alerte est bien reçue dans le délai configuré.

Erreurs Courantes à Éviter

Ces erreurs fréquentes peuvent réduire l'efficacité de votre surveillance ou générer des fausses alertes.

• Ping avant validation : Pinger avant d'avoir vérifié le résultat est dangereux. Votre backup peut créer un fichier vide, votre import peut traiter 0 lignes, votre rapport peut être corrompu. Validez le résultat avant de déclarer le succès via le ping.
• Ignorer le "succès vide" : Si votre job ne fait rien quand il n'y a pas de données (0 emails à envoyer, 0 fichiers à traiter), vous devez quand même pinger. Sinon, vous ne distinguerez pas "rien à faire" de "job pas exécuté". Pingez pour prouver que le job a tourné.
• Ping synchrone bloquant : Sans timeout, votre script peut rester bloqué indéfiniment si le serveur de ping ne répond pas. Cela peut causer des retards en cascade ou des processus zombies. Ajoutez toujours un timeout de 5-10 secondes.
• Période de grâce trop courte : Si votre job prend habituellement 5 minutes mais peut parfois en prendre 10, une période de grâce de 1 minute générera des fausses alertes. Analysez la variabilité de vos jobs et configurez une marge suffisante.

Cas d'Usage Concrets

Le heartbeat s'applique à de nombreuses situations. Voici les cas les plus courants avec leurs spécificités d'implémentation.

Workers de Queue

Les workers qui traitent des messages de queue (Redis, RabbitMQ, SQS) sont des candidats idéaux pour le heartbeat. Un worker peut mourir silencieusement (OOM, crash, conteneur évincé) sans que personne ne s'en aperçoive. Envoyez un ping toutes les 1-5 minutes dans la boucle principale du worker. Si le worker meurt, les pings cessent et vous êtes alerté avant que la queue ne se remplisse dangereusement.

Crons de Backup

Les sauvegardes sont critiques mais leur échec est souvent silencieux : le cron ne s'exécute pas, le script plante, l'espace disque est insuffisant. Créez un heartbeat quotidien avec une période de grâce de 4-6 heures. Pingez après avoir vérifié l'intégrité du backup (fichier non vide, checksum valide). Vous saurez immédiatement si une sauvegarde n'a pas eu lieu.

Synchronisations de Données

Les jobs de synchronisation entre systèmes (CRM ↔ ERP, base de données ↔ data warehouse) doivent s'exécuter régulièrement pour maintenir la cohérence. Un arrêt de sync non détecté cause des divergences qui s'accumulent et deviennent coûteuses à corriger. Pingez après chaque cycle de synchronisation réussi, en incluant le nombre d'enregistrements synchronisés dans les métriques.

Heartbeat avec MoniTao

MoniTao simplifie la mise en place de heartbeats avec une interface intuitive et des fonctionnalités avancées pour tous vos besoins de surveillance.

• Création de heartbeat en un clic avec URL de ping unique et sécurisée
• Configuration flexible : intervalles de 1 minute à 30 jours, période de grâce personnalisable
• Réception et stockage des métriques envoyées avec chaque ping (durée, count, status)
• Historique complet des pings avec graphiques de tendance et détection d'anomalies

Questions Fréquentes sur le Heartbeat

Surveillez Tous Vos Processus avec le Heartbeat

Le heartbeat est une technique simple mais extrêmement efficace pour surveiller les processus qui ne peuvent pas être testés de l'extérieur. En quelques lignes de code, vous pouvez transformer n'importe quel script, cron ou worker en processus surveillé, avec une alerte garantie en cas d'arrêt inattendu.

Avec MoniTao, l'intégration du heartbeat prend moins de 5 minutes. Créez un heartbeat, copiez l'URL, ajoutez un appel HTTP à la fin de votre script, et vous êtes protégé contre les pannes silencieuses. Ne découvrez plus vos problèmes quand il est trop tard - surveillez proactivement avec le heartbeat.

Prêt à dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs