Logging DYNORS — constat et vision (2026-06)¶

Statut

Note de référence produit + architecture — juin 2026.
Complète Configuration dynors-logging et Observabilité & traçabilité.
Copie workspace : NOTE_CONSTAT_VISION_LOGGING_DYNORS.md.

1. Constat (as-is)¶

Zone	État
`dynors-logging`	`DynorsLogger` → `LoggingProvider` (`console`, `sentry`, `noop`). Provider `console` délègue à SLF4J en interne.
`web-errors`	`RequestIdFilter` → MDC `requestId` + header HTTP.
`dynors-events` (P2)	`EventCorrelation` : `requestId` / `traceparent` dans `DomainEvent.metadata` ; restauration MDC à la consommation.
Ops	Loki + Promtail + Prometheus + Grafana (`dynors-ops/monitoring`) ; Tempo prévu (P4).
Forge	Template `dynors-logging-multi-provider@2.0.0` (P6).
Adoption	Inégale — voir Audit usage modules (UMD-2026-001/003).

Double chemin d’émission : code métier via DynorsLogger et SLF4J direct → stdout → Loki. Changer de sink reste centralisable via LoggingProvider ; merge MDC → DynorsLogger = gap P2.5.

Outils SaaS : Sentry = erreurs ; Datadog/Dynatrace/Splunk = option enterprise coûteuse ; Loki = volume quotidien. En local, la console suffit. Hors local : visibilité sans que tout le monde ouvre les traces.

2. Vision cible¶

Principes¶

API métier unique : DynorsLogger — pas de @Slf4j / LoggerFactory métier.
SLF4J/Logback = transport infra (stdout JSON) et libs tierces uniquement.
Quatre signaux distincts :
Logs → Loki (quotidien)
Métriques → Prometheus / Micrometer (P3 inter-app, P5 bus)
Traces → OTel / Tempo (investigation — pas vue par défaut)
Erreurs → Sentry (exceptions, front)
Audit légal (fiscal, RH, santé) ≠ logs Loki (WORM à part).
Corrélation : requestId (HTTP + bus P2), traceparent (P4), labels tenant, source-app, service, environment.

Modèle « stdout + Grafana LGTM + Sentry errors »¶

Code métier → DynorsLogger (+ MDC)
           → LoggingProvider
           → stdout JSON → Promtail → Loki
           → ERROR → Sentry (optionnel)
Métriques  → /actuator/prometheus → Prometheus
Traces     → OTel → Tempo (rôle restreint)

Changer de fournisseur (Sentry → Datadog…) = nouveau LoggingProvider, pas refonte des apps.

3. Niveaux × environnements¶

Niveau	LOCAL	DEV / INT	RMOA	PROD
ERROR	console	Loki + Sentry	idem	idem + alertes
WARN	console	Loki	Loki	Loki
INFO	console	Loki	Loki	Loki (faits métier support)
DEBUG	console (dev)	TTL court ou off	off sauf couloir debug	off sauf override SRE
Traces	off	pilote	sample faible	sample très faible

info() prod = événements métier (refus paiement, entitlement denied…) — pas bruit technique.
debug() = détail implémentation — jamais requis si INFO/ERROR sont bien posés.

Config injectée SIRRAT Forge (pas de secrets en Git).

4. Qui voit quoi¶

Rôle	Loki	Sentry	Tempo
Dev app	son `service` / couloir	projet app	si droit SRE
Support L1	dashboards + `requestId`	erreurs user-facing	non
Ops / SRE	tous services env	tous projets	oui
Admin tenant	son tenant	son projet	non

90 % du quotidien = Loki + métriques. Traces = investigation incident.

5. Décisions (D1–D6)¶

#	Décision
D1	Code métier : `DynorsLogger` uniquement
D2	Local : console suffit
D3	Hors local : Loki + Sentry erreurs
D4	Traces = investigation, pas vue par défaut
D5	Niveaux gouvernés par env (+ override temporaire SRE) via Forge
D6	Changement sink = `LoggingProvider`, pas les apps

6. Paliers observabilité¶

Palier	Sujet	État
P2	Corrélation bus (`EventCorrelation`)	✅ Livré
P2.5	Merge MDC dans `DynorsLogger` ; stdout JSON	⬜
P3	`InterAppCallMetrics` → Micrometer	⬜
P4	OTel + Tempo	⬜
P5	Métriques bus / lag / DLQ	⬜
P6	Fragment Forge observabilité + logging multi-provider	⬜

Dernière mise à jour : 2026-06-18.