Supervision et journaux

La supervision doit détecter quatre catégories de panne : indisponibilité du processus, rupture web–backend, dégradation d’une intégration externe et erreur fonctionnelle persistante.

Niveaux de contrôle

Niveau	Exemple	Ce qu’il prouve
processus	conteneur démarré	le runtime existe
santé	GET /api/health, GET /healthz	le serveur HTTP répond
dépendance	appel web vers le backend	le réseau et la configuration sont corrects
fonctionnel	connexion, lecture, formulaire	le parcours complet fonctionne
métier	demande créée mais e-mail en échec	la donnée et les effets secondaires sont distingués

Un health check ne doit être ni une requête métier coûteuse ni une preuve complète de disponibilité. Complétez-le par des sondes synthétiques peu fréquentes et sans écriture réelle.

Signaux à surveiller

Infrastructure

• état et nombre de redémarrages des conteneurs ;
• CPU, mémoire, espace disque et inodes ;
• taille et croissance du volume pb_data ;
• saturation réseau et durée des builds ;
• expiration des certificats et échecs ACME.

HTTP

• taux de 2xx, 4xx, 5xx par service ;
• latences médiane et percentiles élevés ;
• erreurs de proxy 502/504 ;
• échecs de connexion back-office et réponses 401/403 inhabituelles ;
• endpoints ou domaines les plus affectés.

Fonctions asynchrones

• synchronisations iCalendar en échec ou trop anciennes ;
• notifications et e-mails en erreur, avec possibilité de relivraison ;
• imports médias bloqués et variantes non générées ;
• flux SSE interrompus de manière répétée ;
• exécutions IA failed/started anormalement anciennes, quotas et timeouts.

Les enregistrements métier sont parfois le meilleur signal : une demande de contact est persistée avant la tentative SMTP. Une panne d’e-mail ne doit donc pas être confondue avec une perte de la demande.

Journalisation sûre

Consignez : horodatage UTC, niveau, service, environnement, SHA, route ou capability, identifiant de corrélation, durée et code d’erreur normalisé.

Ne consignez jamais :

• en-tête Authorization, cookie ou token d’invitation ;
• clé API ou mot de passe SMTP ;
• secret TOTP, code de récupération ou URL iCalendar complète ;
• corps contenant des données personnelles sans masquage ;
• prompt, source ou génération IA complète ;
• snapshot de base dans une issue ou une conversation.

Lors d’un partage, remplacez les identifiants sensibles par des valeurs stables mais non réversibles afin de corréler les événements sans divulguer la donnée.

Alertes utiles

Une alerte doit indiquer environnement, service, symptôme, heure de début, lien vers les logs et première action. Évitez les seuils qui se déclenchent sur un seul échec transitoire.

Priorisez :

1. backend ou web indisponible plusieurs minutes ;
2. volume presque plein ou non inscriptible ;
3. certificat proche de l’expiration ou renouvellement en échec ;
4. absence de backup récent ;
5. hausse durable de 5xx ou de latence ;
6. file fonctionnelle bloquée (e-mail, calendrier, média, IA).

Tableau de bord minimal

• version/SHA de chaque application et dernier déploiement ;
• disponibilité sur 24 heures et 30 jours ;
• requêtes, erreurs et latence par service ;
• CPU, mémoire, disque et redémarrages ;
• récence/état du backup ;
• certificat le plus proche de l’expiration ;
• compteurs d’échecs des intégrations.

Après un déploiement

Pendant la fenêtre d’observation, comparez les signaux à la période précédente. Une absence d’alerte ne clôt pas la validation : effectuez un parcours public et back-office, puis cherchez explicitement les nouveaux warnings de démarrage, migrations, clés manquantes et appels backend échoués.