Architecture de référence¶
Vue d'ensemble de la stack LGTM¶
graph TD
subgraph Apps["Applications"]
KC["/metrics<br/>Keycloak"]
DNS["/metrics<br/>CoreDNS"]
CICD["/metrics<br/>CI/CD"]
Metier["OTel SDK<br/>Apps metier"]
end
Apps --> Alloy["Alloy<br/>(collecteur unifie)<br/>scrape metriques<br/>collecte logs<br/>reception traces"]
Alloy --> Mimir["Mimir<br/>(metriques)"]
Alloy --> Loki["Loki<br/>(logs)"]
Alloy --> Tempo["Tempo<br/>(traces)"]
Mimir --> S3["Stockage objet<br/>(S3 / MinIO)"]
Loki --> S3
Tempo --> S3
S3 --> Grafana["Grafana<br/>Dashboards, Alerting, Explore"] Composants¶
Alloy — Collecteur unifie¶
Grafana Alloy remplace Prometheus (scraping), Promtail (logs) et OpenTelemetry Collector en un seul binaire :
| Fonction | Protocole | Source |
|---|---|---|
| Scrape metriques | Prometheus scrape | Endpoints /metrics |
| Reception metriques | OTLP, Prometheus remote write | OTel SDK, autres Prometheus |
| Collecte logs | Journal, fichiers, syslog, Loki push | systemd, conteneurs, applications |
| Reception traces | OTLP (gRPC + HTTP) | OTel SDK, instrumentations auto |
Prometheus / Mimir — Metriques¶
Prometheus collecte et stocke les metriques a court terme (retention locale). Mimir est le backend de stockage longue duree, horizontalement scalable.
| Composant | Rôle | Scalabilité |
|---|---|---|
| Prometheus | Scraping local, regles d'alerte, cache | Vertical (un par cluster/zone) |
| Mimir | Stockage longue duree, requêtes globales | Horizontal (micro-services) |
Architecture Mimir (mode micro-services) :
graph TD
Dist["Distributor<br/>reception des metriques"] --> Ing["Ingester<br/>stockage en memoire + WAL"]
Ing --> Store["Store Gateway<br/>stockage objet S3/MinIO"]
Store --> Query["Querier<br/>execution des requetes PromQL"] Loki — Logs¶
Loki indexe uniquement les labels (et non le contenu complet des logs), ce qui le rend leger et economique :
| Composant | Rôle |
|---|---|
| Distributor | Reception et validation des logs |
| Ingester | Compression et écriture vers le stockage |
| Querier | Execution des requêtes LogQL |
| Compactor | Compaction des index, retention |
# Exemples LogQL
# Logs d'erreur du service catalog
{service="catalog"} |= "error"
# Logs JSON filtres par status code
{service="api-gateway"} | json | status_code >= 500
# Taux d'erreurs par service (metriques derivees des logs)
sum by(service) (rate({level="error"}[5m]))
Tempo — Traces¶
Tempo stocke les traces distribuees avec un stockage objet uniquement (pas d'index) :
| Fonction | Description |
|---|---|
| Reception | OTLP (gRPC/HTTP), Jaeger, Zipkin |
| Stockage | Blocs dans S3/MinIO, pas d'index |
| Requêtes | TraceQL, recherche par trace ID |
| Integration | Liens metriques ↔ traces ↔ logs dans Grafana |
Grafana — Visualisation et alerting¶
Grafana unifie les 3 piliers dans une seule interface :
| Fonction | Description |
|---|---|
| Dashboards | Visualisation des metriques, logs et traces |
| Explore | Investigation ad-hoc (correler metriques ↔ logs ↔ traces) |
| Alerting | Regles basées sur PromQL/LogQL, routing, silences |
| RBAC | Permissions par datasource, dossier, dashboard |
Stockage objet¶
Tous les composants LGTM utilisent un stockage objet comme backend de persistance :
| Option | Usage | Avantages |
|---|---|---|
| MinIO | Auto-heberge, on-premise | Contrôle total, compatible S3, open source |
| S3 (AWS) | Cloud AWS | Manage, durable, scalable |
| GCS (GCP) | Cloud GCP | Manage, durable, scalable |
| Azure Blob | Cloud Azure | Manage, durable, scalable |
MinIO pour le on-premise
Pour une installation auto-hebergee en classification Confidentiel, MinIO est le choix recommande. Il offre une compatibilité S3 complète tout en gardant les données en interne.
Dimensionnement¶
Guide de sizing¶
| Parametre | Petit (\<50 services) | Moyen (50-200 services) | Grand (>200 services) |
|---|---|---|---|
| Metriques | |||
| Series actives | < 500 000 | 500 000 - 5 000 000 | > 5 000 000 |
| Ingestion | < 50 000 samples/s | 50 000 - 500 000 samples/s | > 500 000 samples/s |
| Prometheus | 1 replica, 4 CPU, 8 Go RAM | 2 replicas, 8 CPU, 16 Go RAM | Mimir cluster (3+ ingesters) |
| Logs | |||
| Volume | < 50 Go/jour | 50 - 500 Go/jour | > 500 Go/jour |
| Loki | Mode monolithique, 2 CPU, 4 Go RAM | Simple scalable (3 replicas) | Micro-services (5+ composants) |
| Traces | |||
| Spans | < 100 000 spans/s | 100 000 - 1 000 000 spans/s | > 1 000 000 spans/s |
| Tempo | Mode monolithique | Simple scalable | Micro-services |
| Stockage | |||
| Retention metriques | 90 jours | 1 an | 1 an + downsampling |
| Retention logs | 30 jours | 90 jours | 1 an (Confidentiel) |
| Retention traces | 7 jours | 30 jours | 30 jours |
| MinIO / S3 | 500 Go | 5 To | 50+ To |
| Grafana | 1 replica, 1 CPU, 512 Mo RAM | 2 replicas HA | 3+ replicas HA |
Formules de calcul¶
# Estimation stockage metriques (Mimir/Prometheus)
# 1 sample = ~2 octets compresses
stockage_metriques_jour = series_actives * scrape_interval_par_jour * 2 octets
# Exemple : 1M series, scrape 15s → 1M * 5760 * 2 = ~11 Go/jour
# Estimation stockage logs (Loki)
# Compression ~10x typique
stockage_logs_jour = volume_logs_brut / 10
# Exemple : 100 Go brut/jour → ~10 Go/jour compresse
# Estimation stockage traces (Tempo)
# 1 span = ~500 octets compresses
stockage_traces_jour = spans_par_seconde * 86400 * 500 octets
# Exemple : 100k spans/s → ~4.3 To/jour (echantillonnage recommande)
Échantillonnage des traces
A haute volumetrie, l'échantillonnage (sampling) est indispensable. Stratégie recommandee : tail-based sampling dans Alloy — conserver 100% des traces en erreur, 10-20% des traces normales.