SIRH/doc/error-tracking.md

Error tracking (GlitchTip)

Les erreurs backend (Symfony) sont remontées vers GlitchTip (instance interne MALIO, compatible SDK Sentry), org malio, projet sirh-api. Prod uniquement, inerte sans DSN.

Frontend hors périmètre (les erreurs front partent du navigateur RH ; ajout futur possible via un proxy nginx /ingest).

Contrainte réseau & transport

GlitchTip est sur le réseau interne (bloqué par Sophos). SIRH tourne sur un VPS OVH public. Le container PHP joint GlitchTip via un tunnel Tailscale monté sur le host de prod.

Fichiers concernés

Fichier	Rôle
config/packages/sentry.yaml	conf backend (prod-only, DSN runtime, 4xx ignorés, release = app.version, handler Monolog ERROR+)
config/bundles.php	SentryBundle enregistré ['prod' => true]
config/packages/monolog.yaml	handler sentry (service) en when@prod
.env	bloc documenté SENTRY_DSN (vide → inerte)

Activation (runbook)

1. Tailscale sur le host prod OVH :

   curl -fsSL https://tailscale.com/install.sh | sh
   sudo tailscale up            # ou --authkey tskey-auth-XXXX (headless)
   tailscale status && tailscale ip -4
   

2. Vérifier l'accès à GlitchTip depuis le host :

   tailscale ping <glitchtip-tailnet>
   curl -sS -o /dev/null -w "%{http_code}\n" http://<glitchtip-IP-tailnet>:<port>/_health/
   

3. Routage container → tailnet : pointer SENTRY_DSN sur l'IP tailnet de GlitchTip (le container ne résout pas MagicDNS). Repli si non routé : sidecar tailscale/tailscale
   • network_mode: service:tailscale.
4. Créer le projet GlitchTip sirh-api (plateforme php-symfony) dans l'org malio, récupérer le DSN (Settings → Client Keys).
5. Injecter le DSN dans l'env_file serveur (pas dans l'image), puis redéployer :

   SENTRY_DSN=http://<clé>@100.x.y.z:<port>/<id-sirh-api>
   

   docker compose up -d
   docker compose exec php php bin/console cache:clear --env=prod
   

Tester l'envoi

Le bundle sentry/sentry-symfony fournit une commande qui envoie un événement de test et confirme s'il est bien parti vers GlitchTip. Elle n'existe qu'en prod (bundle prod-only) et nécessite SENTRY_DSN défini.

# Sur le serveur, dans le container PHP (SENTRY_DSN doit être dans l'env) :
docker compose exec php sh -lc "APP_ENV=prod php bin/console sentry:test"

Sortie attendue : Sending test message... done. → une Issue de test apparaît dans le projet sirh-api côté GlitchTip. Si l'envoi échoue (Message not sent), le problème est réseau (Tailscale/route/port) ou DSN, pas applicatif.

Pré-check connectivité depuis le host prod (ex. IP tailnet GlitchTip 100.111.223.34) :

tailscale ping 100.111.223.34
curl -sS -o /dev/null -w "%{http_code}\n" http://100.111.223.34:<port>/_health/   # 200 attendu

Alternative sans commande dédiée : déclencher un throw new \RuntimeException('glitchtip test') temporaire dans un endpoint, ou un $logger->error('glitchtip test') (niveau ERROR+ → Issue).

CA HTTPS (conditionnel)

Uniquement si le DSN cible l'HTTPS interne logs.malio-dev.fr (cert auto-signé) : baker la CA racine MALIO dans deploy/docker/Dockerfile.prod (stage production). Recommandé : préférer l'endpoint HTTP via le tailnet (déjà chiffré par WireGuard) → pas de CA.

Design détaillé : docs/superpowers/specs/2026-06-28-glitchtip-backend-error-tracking-design.md.