Playbook Monitoring

Statut	Actif — v1.0 — 2026-06-27
Priorité	P1
Obligatoire V1	Non (health check basique oui)
Responsable	Sylvain
Voir aussi	Playbook Release · Playbook Backup · DevOps Monitoring

Philosophie

Le monitoring a une règle simple : être alerté avant l'utilisateur.

Un monitoring trop complexe n'est pas maintenu. On démarre avec le minimum utile et on ajoute au fil des incidents réels.

Services surveillés

Service	URL / point de contrôle	Criticité
API Laravel	GET /api/v1/health	P0
Site public (dmv-public)	Page d'accueil	P0
Mon Espace (dmv-workspace)	Page d'accueil	P0
Workers Supervisor	supervisorctl status	P1
Base de données	Connexion PostgreSQL / Supabase	P0
Sauvegardes	Présence d'un dump récent (< 25h)	P0

Health check API

L'API expose /api/v1/health. Ce endpoint doit retourner 200 quand tout fonctionne.

Vérification minimale attendue :

{
  "status": "ok",
  "database": "connected",
  "timestamp": "2026-06-27T10:00:00Z"
}

Ce endpoint est utilisé dans les scripts de déploiement (deploy.sh) et doit rester simple — pas de logique métier.

Métriques importantes

API

• Disponibilité — uptime > 99,5 %
• Latence P95 — < 500 ms sur les routes principales
• Taux d'erreur 5xx — < 0,1 %

Workers

• Process actifs — tous les workers Supervisor doivent être RUNNING
• Jobs en échec — zéro job en état FAILED dans la queue

Disque

• Espace libre — alerte si < 20 % restant
• Logs Laravel — rotation configurée, pas de croissance incontrôlée

Sauvegardes

• Dernière sauvegarde — moins de 25 heures
• Intégrité — checksum valide (vérifié par le script de backup)

Alertes

Minimum à configurer dès V1

• Uptime API (via UptimeRobot, Better Uptime, ou équivalent) — notification Telegram ou email
• Alerte disque via cron (df -h | awk ...) — email si < 20 %

À ajouter progressivement

• Erreurs Laravel critiques (niveau error et critical dans les logs)
• Jobs Supervisor en échec
• Échec des sauvegardes quotidiennes
• Latence anormale (si métriques disponibles)

Canal d'alerte

Un seul canal par défaut (email ou Telegram). Ne pas fragmenter les alertes sur plusieurs canaux au risque de toutes les ignorer.

Procédures en cas d'incident

API down (5xx ou timeout)

1. Vérifier le health check : curl https://api.monvillage.fr/api/v1/health
2. Vérifier les logs Nginx : sudo tail -n 100 /var/log/nginx/error.log
3. Vérifier PHP-FPM : sudo systemctl status php8.4-fpm
4. Vérifier les workers : sudo supervisorctl status
5. Si base de données : vérifier la connexion Supabase
6. Si non résolu en 15 min : rollback via le playbook release

Worker en échec

sudo supervisorctl status
sudo supervisorctl restart dmv-api-worker:
sudo tail -n 50 /var/log/supervisor/dmv-api-worker.log

Disque plein

df -h
du -sh /srv/dmv/api/storage/logs/
# Vider les logs anciens si la rotation ne fonctionne pas
find /srv/dmv/api/storage/logs/ -name "*.log" -mtime +30 -delete

Outils actuels

Outil	Usage actuel
Logs Nginx	Disponibles dans /var/log/nginx/
Logs Laravel	Dans storage/logs/, rotation quotidienne
Logs Supervisor	Dans /var/log/supervisor/
Script backup	Vérifie l'intégrité post-sauvegarde
UptimeRobot	À configurer — monitoring uptime externe

Évolution

Ce document évolue au fil des incidents. Après chaque incident significatif :

1. Documenter la cause racine ici
2. Ajouter l'alerte manquante
3. Mettre à jour la procédure si nécessaire