Un dead man's switch est un mécanisme qui se déclenche quand un signal attendu s'arrête. En monitoring, cela signifie : "Si vous n'avez pas de mes nouvelles, quelque chose ne va pas." Ce pattern est essentiel pour les jobs critiques qui ne doivent jamais échouer silencieusement.
Qu'est-ce qu'un Dead Man's Switch ?
Le terme vient des mécanismes de sécurité dans les trains et les machines. Si l'opérateur devient incapacité, le switch se déclenche car il arrête de le maintenir activement.
En monitoring logiciel :
Check traditionnel : "Êtes-vous vivant ?" Dead man's switch : "Manifestez-vous régulièrement, sinon je supposerai que vous êtes mort."
Le système attend des manifestations régulières. Le silence indique un échec.
Quand Utiliser le Dead Man's Switch
Jobs Planifiés Critiques
Jobs où l'échec a des conséquences sérieuses :
- Traitement financier - Paiements, réconciliation
- Sauvegardes de données - Base de données, système de fichiers
- Rapports de conformité - Soumissions réglementaires
- Scans de sécurité - Évaluations de vulnérabilités
Services Toujours Actifs
Processus qui ne devraient jamais s'arrêter :
- Workers de queue
- Processeurs de flux
- Processus daemon
- Services en arrière-plan
Systèmes Distants
Systèmes sans accès direct au monitoring :
- Appareils IoT
- Nœuds edge computing
- Systèmes air-gapped
- Logiciels déployés chez les clients
Implémenter le Dead Man's Switch
Implémentation Basique
import requests
import schedule
def heartbeat():
requests.get("https://monitor.example.com/ping/token")
def job_critique():
# Faire le travail important
traiter_paiements()
# Signaler la completion
heartbeat()
# Exécuter toutes les 5 minutes
schedule.every(5).minutes.do(job_critique)
Avec Gestion des Erreurs
def job_critique():
try:
traiter_paiements()
heartbeat() # Pinguer uniquement en cas de succès
except Exception as e:
log_erreur(e)
# Ne pas pinguer - laisser le switch se déclencher
raise
Directives de Configuration
Fréquence de Check
À quelle fréquence le job doit-il pinguer ?
| Fréquence du Job | Fréquence du Ping |
|---|---|
| Chaque minute | Chaque minute |
| Toutes les 5 minutes | Toutes les 5 minutes |
| Horaire | Horaire |
| Quotidien | Quotidien |
| Hebdomadaire | Hebdomadaire |
Période de Grâce
Combien de temps attendre avant d'alerter ?
Formule : Durée attendue + tampon + latence réseau
Exemples :
- Job de 1 minute → grâce de 3 minutes
- Job de 5 minutes → grâce de 10 minutes
- Job de 30 minutes → grâce de 45 minutes
- Job de 2 heures → grâce de 2.5 heures
Bonnes Pratiques
1. Pingez Uniquement en Cas de Succès
Ne pingez jamais quand le job échoue. L'absence de ping est le signal.
2. Utilisez des Réessais pour les Pings
curl --retry 3 --retry-delay 5 $PING_URL
3. Testez le Flux Complet
Vérifiez régulièrement :
- Job réussit → ping reçu → pas d'alerte
- Job échoue → pas de ping → alerte déclenchée
- L'alerte atteint les bonnes personnes
4. Documentez Tout
Maintenez la documentation de :
- Ce que chaque moniteur surveille
- Planning attendu et période de grâce
- Qui est alerté
- Procédures de réponse
Conclusion
Le monitoring dead man's switch est le filet de sécurité pour vos jobs critiques. Quand le monitoring actif échoue (parce que le service est down), le monitoring passif capte le silence.
Pour tout job où l'échec a des conséquences, implémentez un dead man's switch. Le coût de la configuration est de quelques minutes ; le coût d'un échec silencieux est des heures d'indisponibilité et de perte de données.
