Comparaison des solutions d'observabilité¶

Cette page alimente un ADR (Architecture Decision Record) pour le choix de la stack d'observabilité.

Grille de comparaison¶

Analyse détaillée¶

LGTM — Recommande¶

La stack LGTM (Loki, Grafana, Tempo, Mimir) représente l'ecosysteme Grafana Labs complet :

Forces

• Coût maîtrise : open source, pas de licence par hôte ou par volume
• Ecosysteme standard : compatible OpenTelemetry, Prometheus exporters, Grafana dashboards communautaires
• Scalabilité prouvee : architecture micro-services (Mimir, Loki, Tempo) avec stockage objet (S3/MinIO)
• Correlation native dans Grafana entre metriques, logs et traces
• Alloy comme collecteur unifie remplace Prometheus + Promtail + OTel Collector

Faiblesses

• Complexité operationnelle : plusieurs composants a déployer et maintenir
• LogQL moins puissant que KQL pour l'analyse de logs complexes
• Pas de SIEM natif (compléter avec un outil dedie si besoin)

Datadog — Si SaaS accepte¶

Forces

• Expérience unifiee : un seul outil pour metriques, logs, traces, APM, sécurité, synthetics
• Zero maintenance infrastructure : SaaS entierement gère
• 700+ integrations preconfigurees
• Machine learning natif (anomaly detection, forecasting)

Faiblesses

• Coût eleve et difficile a prevoir (facturation par volume ingere + hôtes + APM + logs)
• Vendor lock-in : données hebergees chez Datadog, migration coûteuse
• Données sensibles chez un tiers (problème de classification Confidentiel)
• Latence d'ingestion potentielle (SaaS)

ELK — Pour l'analyse de logs avancee¶

Forces

• KQL/Lucene : langage de requête tres puissant pour l'analyse de logs (full-text search, aggregations complexes)
• Elastic SIEM : capacites de sécurité intégrées (detection de menaces, correlation d'événements)
• Elastic APM : traces distribuees intégrées
• Maturité et documentation abondante

Faiblesses

• Empreinte ressources elevee : Elasticsearch est gourmand en RAM (JVM, heaps importants)
• Licence SSPL (Elastic) vs Apache 2.0 (OpenSearch) : choisir sa variante
• Metriques : Metricbeat moins complet que Prometheus
• Coût de stockage : les index Elasticsearch sont volumineux

VictoriaMetrics — Pour la haute cardinalite¶

Forces

• Performance exceptionnelle : compression aggressive, faible consommation mémoire
• MetricsQL : surensemble de PromQL avec des fonctions supplémentaires
• Haute cardinalite : gère des millions de series temporelles sans dégradation
• Compatible Prometheus : remplacement transparent (remote write, Grafana datasource)

Faiblesses

• Metriques uniquement : necesssite Loki pour les logs, Tempo pour les traces
• Communauté plus petite que Prometheus
• Fonctionnalités enterprise (clustering, downsampling) dans la version payante

Comparaison des langages de requête¶

Le choix du langage de requête impacte fortement la courbe d'apprentissage et les capacites d'analyse :

# PromQL — taux d'erreur par service
sum by(service) (rate(http_requests_total{status=~"5.."}[5m]))
/
sum by(service) (rate(http_requests_total[5m]))

# LogQL — logs d'erreur avec extraction de champs JSON
{service="catalog"} | json | level="error" | line_format "{{.timestamp}} {{.message}}"

# KQL — recherche full-text avec aggregation
service: "catalog" AND level: "error" AND message: "timeout"

Complexité operationnelle comparée¶

Matrice de decision¶

Decision recommandee¶

Pour une DSI orientee développement avec des exigences de maîtrise des coûts et de classification Confidentiel :

Decision : Stack LGTM (Prometheus/Mimir + Loki + Tempo + Grafana) avec Alloy comme collecteur unifie. VictoriaMetrics en alternative si la cardinalite metriques depasse les capacites de Mimir.

Justification :

• Open source : pas de coût de licence, pas de vendor lock-in
• Données hebergees en interne : compatible classification Confidentiel
• Ecosysteme standard : OpenTelemetry, Prometheus exporters, dashboards communautaires
• Scalabilité prouvee : stockage objet (S3/MinIO) pour la retention longue
• Correlation native des 3 piliers dans Grafana