105 lines
4.1 KiB
Markdown
105 lines
4.1 KiB
Markdown
|
# ADR-OBS-001 — Loki comme backend de logs de référence
|
|||
|
|
|
|||
|
|
**Version :** 1.0
|
|||
|
|
**Date :** 25 janvier 2026
|
|||
|
|
**Cycle de Réalignement Boréal :** CRB-3
|
|||
|
|
**Statut :** Adopté (référence vivante)
|
|||
|
|
**Portée :** Fédération (C3), Pivot (C5), Membres affiliés, Tenants (C6–C8)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. Contexte
|
|||
|
|
|
|||
|
|
L’Alliance Boréale requiert une capacité de **journalisation** (logs) commune, interopérable et auditable, compatible avec :
|
|||
|
|
|
|||
|
|
- La séparation **Fédération / Pivot / Tenants**
|
|||
|
|
- Le principe **adjacent-only** (aucun flux ne saute une couche)
|
|||
|
|
- La **portabilité** des tenants (export/rejeu possible, preuves de fonctionnement)
|
|||
|
|
|
|||
|
|
Les logs sont un intrant critique pour :
|
|||
|
|
|
|||
|
|
- la résilience opérationnelle (diagnostic, incident, détection)
|
|||
|
|
- la conformité (preuves, audits, traçabilité)
|
|||
|
|
- la gouvernance (ΔLog et boucles de rétroaction)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. Décision
|
|||
|
|
|
|||
|
|
**Grafana Loki** est adopté comme **backend de logs de référence** pour l’architecture de référence Alliance Boréale.
|
|||
|
|
|
|||
|
|
Cela signifie :
|
|||
|
|
|
|||
|
|
1. **Référence technologique**
|
|||
|
|
|
|||
|
|
- Loki est l’implémentation de référence pour l’ingestion, le stockage, la rétention et la requête de logs.
|
|||
|
|
|
|||
|
|
1. **Référence d’intégration**
|
|||
|
|
|
|||
|
|
- Les flux logs des tenants (C6–C8) et des services pivot (C5) transitent via le **Pivot (C5)** vers la **capacité observabilité fédérée (C3)**, conformément à l’adjacent-only.
|
|||
|
|
|
|||
|
|
1. **Référence d’agent**
|
|||
|
|
|
|||
|
|
- **Grafana Alloy** est l’agent de collecte/expédition recommandé par défaut.
|
|||
|
|
- Les alternatives sont tolérées uniquement si elles respectent le contrat de la politique `POL-OBS-LOG-001`.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. Alternatives considérées
|
|||
|
|
|
|||
|
|
### A) Stack “full-text” (indexation complète)
|
|||
|
|
|
|||
|
|
- Avantage : recherche textuelle plus directe.
|
|||
|
|
- Inconvénients : coût/complexité plus élevés, risques de dérives (indexation incontrôlée, PII), difficile à rendre “facile aux petits”.
|
|||
|
|
|
|||
|
|
### B) “Un Loki par membre” (décentralisé)
|
|||
|
|
|
|||
|
|
- Avantage : simplicité locale, autonomie.
|
|||
|
|
- Inconvénients : dispersion des pratiques, consolidation fédérale plus difficile, effort d’opération multiplié.
|
|||
|
|
|
|||
|
|
### C) “Loki fédéré + ingestion via Pivot” (modèle retenu)
|
|||
|
|
|
|||
|
|
- Avantages : simplicité pour les petits (un seul endpoint), cohérence fédérale, contrôle d’accès et preuves centralisées, isolation par tenant.
|
|||
|
|
- Inconvénient : nécessite un pivot/gateway bien cadré (mais c’est déjà un invariant C5).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. Conséquences (ce que cela change)
|
|||
|
|
|
|||
|
|
### 4.1 Pour les membres affiliés (petits inclus)
|
|||
|
|
|
|||
|
|
- Ils n’ont pas l’obligation d’opérer Loki localement.
|
|||
|
|
- Ils doivent être **compatibles Loki** : capacité d’expédier des logs via l’endpoint standard (TLS, auth, labels conformes).
|
|||
|
|
|
|||
|
|
### 4.2 Pour la Fédération (C3)
|
|||
|
|
|
|||
|
|
- Opération d’un Loki “référence” (au minimum en mode simple) + Grafana de consultation.
|
|||
|
|
- Mise en place des politiques : rétention, quotas, RBAC, preuves auditables.
|
|||
|
|
|
|||
|
|
### 4.3 Pour le Pivot (C5)
|
|||
|
|
|
|||
|
|
- Le pivot devient **le point d’entrée unique** pour l’ingestion et la consultation (proxy/gateway).
|
|||
|
|
- Le pivot applique l’authentification, la médiation (multi-tenant masquée) et les contrôles de conformité (labels/quotas).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. Décision opérationnelle de démarrage (MVP)
|
|||
|
|
|
|||
|
|
- **Mode de déploiement Loki** : démarrage en mode simple (priorité à l’opérabilité).
|
|||
|
|
- **Chemin d’ingestion** : agents (C6/C5) → Gateway Pivot (C5) → Loki (C3).
|
|||
|
|
- **Chemin de consultation** : utilisateurs → Grafana (C3) via Gateway Pivot (C5) + SSO (Keycloak).
|
|||
|
|
- **Multi-tenant** : géré par le Pivot (C5). Les petits n’ont pas à manipuler l’isolation.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. Critères d’acceptation
|
|||
|
|
|
|||
|
|
La décision est considérée “en place” lorsque :
|
|||
|
|
|
|||
|
|
1. Un membre affilié peut expédier des logs avec Alloy vers l’endpoint pivot, sans configuration complexe.
|
|||
|
|
2. Les labels minimaux requis sont présents et conformes (cardinalité maîtrisée).
|
|||
|
|
3. Un utilisateur autorisé peut consulter les logs dans Grafana via SSO.
|
|||
|
|
4. La rétention par défaut est appliquée et vérifiable.
|
|||
|
|
5. Les preuves minimales d’audit (configuration + traces d’exécution + exemple de requêtes) sont archivées.
|
|||
|
|
|
|||
|
|
---
|