Health Check Global
1. Quoi ? — Définition et contexte
Section intitulée « 1. Quoi ? — Définition et contexte »Le workflow Health Check Global surveille la santé des conteneurs Docker toutes les 5 minutes. Il détecte les conteneurs en état unhealthy ou arrêtés inopinément et notifie les admins via Telegram.
Méthode de détection
Section intitulée « Méthode de détection »| Méthode | Outil | Status |
|---|---|---|
| Docker ps filtré | SSH + CLI | Actuel (production) |
| Prometheus cAdvisor | container_health_status | Non fonctionnel (Docker 29+) |
| HTTP endpoints | Curl vers /healthz | Spécifié, non implémenté |
Services surveillés
Section intitulée « Services surveillés »| Service | Stack | Critical |
|---|---|---|
| Caddy | security | Oui |
| CrowdSec | security | Oui |
| N8N | n8n | Oui |
| N8N-Postgres | n8n | Oui |
| Redis | n8n | Oui |
| N8N Workers | n8n | Non |
| Odoo | odoo | Oui |
| Odoo-Postgres | odoo | Oui |
| Qdrant | ai | Non |
| Claude-Ollama | ai | Non |
| Prometheus | monitoring | Non |
| Grafana | monitoring | Non |
2. Pourquoi ? — Enjeux et motivations
Section intitulée « 2. Pourquoi ? — Enjeux et motivations »Problèmes résolus
Section intitulée « Problèmes résolus »| Problème | Sans health check | Avec health check |
|---|---|---|
| Container crash | Découvert par un utilisateur | Alerte en 5 minutes |
| Service unhealthy | Pas de visibilité | Détection automatique |
| Downtime prolongé | Pas de notification | Intervention rapide |
Pourquoi SSH au lieu de Prometheus ?
Section intitulée « Pourquoi SSH au lieu de Prometheus ? »| Méthode | Avantage | Inconvénient |
|---|---|---|
| SSH + docker ps | Fonctionne toujours | Pas d’historique Prometheus |
| cAdvisor metrics | Historique, graphes | Bug Docker 29+ |
3. Comment ? — Mise en œuvre technique
Section intitulée « 3. Comment ? — Mise en œuvre technique »Architecture actuelle
Section intitulée « Architecture actuelle »Un sub-workflow Docker Health Check with Retry (jDN2QV3nEMGacrCvgEBBV) wrap ce check avec une politique de retry (2 tentatives espacées de 30s) avant de notifier, ce qui filtre les faux positifs sur les containers en cours de redémarrage.
Commande de détection
Section intitulée « Commande de détection »docker ps -a \ --filter "health=unhealthy" \ --filter "status=exited" \ --format jsonCette commande retourne :
- Les conteneurs avec healthcheck échoué (
health=unhealthy) - Les conteneurs arrêtés inopinément (
status=exited)
Configuration N8N
Section intitulée « Configuration N8N »Node SSH Docker Health :
Type: SSHHost: localhostCommand: docker ps -a --filter "health=unhealthy" --filter "status=exited" --format jsonParse Results (Code) :
const output = $json.stdout;if (!output || output.trim() === '') { return [{ json: { count: 0, containers: [] } }];}
const containers = output.trim().split('\n') .filter(line => line) .map(line => JSON.parse(line)) .map(c => ({ name: c.Names, status: c.State, health: c.Status }));
return [{ json: { count: containers.length, containers: containers }}];Format de notification
Section intitulée « Format de notification »{ "source": "health_check", "type": "health_issue", "severity": "critical", "title": "2 container(s) en problème", "message": "Containers détectés:\n- n8n-worker-1 (unhealthy)\n- redis (exited)", "container": "n8n-worker-1", "containers": ["n8n-worker-1", "redis"], "timestamp": "2026-01-20T10:00:00.000Z"}Exemple de notification Telegram
Section intitulée « Exemple de notification Telegram »🚨 HEALTH CHECK ALERT
2 container(s) en problème
Containers détectés:❌ n8n-worker-1 (unhealthy)❌ redis (exited)
Stack affecté: n8n-stack
[🔄 Restart] [📋 Logs] [🔇 Mute 1h]Commandes utiles
Section intitulée « Commandes utiles »# Voir les conteneurs unhealthydocker ps -a --filter "health=unhealthy"
# Voir les conteneurs arrêtésdocker ps -a --filter "status=exited"
# Health d'un conteneur spécifiquedocker inspect --format='{{.State.Health.Status}}' n8n
# Logs des health checks Dockerdocker inspect --format='{{range .State.Health.Log}}{{.Output}}{{end}}' n8n4. Et si ? — Perspectives et limites
Section intitulée « 4. Et si ? — Perspectives et limites »Limites actuelles
Section intitulée « Limites actuelles »| Limite | Impact | Mitigation |
|---|---|---|
| Pas d’HTTP checks | Détecte état Docker, pas applicatif | Prévu en évolution |
| Pas de rapport quotidien | Pas de vue historique | Dashboard Grafana |
| 5min intervalle | Latence détection max 5min | Acceptable pour usage perso |
Scénarios d’évolution
Section intitulée « Scénarios d’évolution »Si besoin de HTTP checks :
- Ajouter des checks curl vers /healthz de chaque service
- Différencier Docker healthy vs HTTP répondant
- Alertes plus précises
Si besoin de rapport quotidien :
- Agréger les incidents sur 24h
- Calculer uptime par service
- Envoyer digest à 8h
Si cAdvisor redevient fonctionnel :
- Migrer vers métriques Prometheus
- Supprimer le check SSH
- Historique et graphes natifs
Troubleshooting
Section intitulée « Troubleshooting »| Problème | Vérification |
|---|---|
| Faux positifs | Conteneurs sans healthcheck retournent “none” |
| SSH timeout | Credential SSH valide ? Port 22 accessible ? |
| Pas de notification | Workflow actif ? Notification Hub ok ? |
| Trop d’alertes | Ajuster les filtres dans docker ps |
Pages liées
Section intitulée « Pages liées »Workflows
Section intitulée « Workflows »- Notification Hub — Routage notifications
- Docker Auto-Updates — Mises à jour images
Infrastructure
Section intitulée « Infrastructure »- Monitoring Stack — Prometheus & Grafana
- Security Stack — Caddy & CrowdSec