Observabilité

Qu’est-ce que l’observabilité ?

L’observabilité va au-delà du simple monitoring : c’est pour l’exploitant d’un système, la capacité à comprendre l’état interne d’un système en analysant ses sorties externes. Dans le contexte des applications cloud et microservices, l’observabilité permet de prévenir et diagnostiquer les problèmes, optimiser les performances et assurer la fiabilité des services.

Les principaux aspects de l’observabilité

1. Métriques (Metrics)

Metriques

Les métriques sont des données numériques agrégées dans le temps qui représentent l’état et les performances du système :

  • Métriques système : CPU, mémoire, disque, réseau
  • Métriques applicatives : Nombre de requêtes, temps de réponse, taux d’erreur
  • Métriques business : Nombre d’utilisateurs connectés, transactions par seconde
  • Format : Séries temporelles avec timestamps

Exemple : http_requests_total{method="GET", status="200"} 1547

2. Logs (Journaux)

Les logs sont des enregistrements textuels d’événements discrets qui se produisent dans le système :

  • Logs d’application : Messages de debug, erreurs, informations
  • Logs système : Événements du système d’exploitation
  • Logs d’audit : Traçabilité des actions utilisateurs
  • Format : Texte structuré (JSON) ou non-structuré

Exemple :

{
  "timestamp": "2024-01-15T10:30:00Z",
  "level": "ERROR",
  "service": "vote-api",
  "message": "Database connection failed"
}

3. Traces distribuées (Distributed Tracing)

Les traces permettent de suivre une requête à travers tous les services d’une architecture microservices :

  • Span : Unité de travail dans une trace (appel de fonction, requête HTTP)
  • Trace : Collection de spans représentant le parcours complet d’une requête
  • Context propagation : Transmission des informations de trace entre services
  • Visualisation : Timeline et graphe des appels entre services

Traces

Avantage : Identification des goulots d’étranglement et des dépendances entre services

Peut-être associé aux évènements (attendus ou non) : déploiements de mise à jour, pannes internes ou externes au système.

4. Alerting

  • Evènements détectés : pattern dans les logs
  • Seuil de Déclenchement : basé sur des métriques
  • Notifications : Mail, SMS, Slack

Principaux outils de l’écosystème

Observability

  • Prometheus : Système de monitoring et base de données de séries temporelles
  • VictoriaMetrics : Alternative haute performance à Prometheus
  • InfluxDB : Base de données orientée séries temporelles
  • Thanos : Extension de Prometheus pour le stockage long terme
  • ELK Stack : Elasticsearch, Logstash, Kibana
  • Loki : Solution de logs par Grafana, inspirée de Prometheus
  • Fluentd : Collecteur de logs unifié et open-source
  • Jaeger : Système de tracing distribué développé par Uber
  • Zipkin : Système de tracing distribué open-source
  • OpenTelemetry : Standard ouvert pour l’instrumentation
  • Grafana : Plateforme de visualisation et d’alerting
  • DataDog : Solution SaaS complète d’observabilité
  • New Relic : Plateforme de monitoring des performances applicatives
  • Elastic Observability : Solution basée sur la stack Elastic

OpenTelemetry : Le standard émergent

OpenTelemetry (OTel) est un framework d’observabilité qui standardise la collecte et l’export de données télémétriques :

Avantages

  • Vendor-neutral : Compatible avec tous les backends d’observabilité
  • Auto-instrumentation : Instrumentation automatique pour les frameworks populaires
  • Multi-langage : Support de nombreux langages de programmation
  • Unified API : API unique pour métriques, logs et traces

Architecture 

Application → OTel SDK → OTel Collector → Backend (Prometheus, Jaeger, etc.)

Observabilité pour la VotingApp

Pour notre application de démo, un stack d’observabilité typique pourrait inclure :

  • Prometheus ou Victoria Metrics pour collecter les métriques (latences, nombre de votes, …)
  • Grafana pour visualiser les dashboards
  • Loki pour centraliser les logs
  • Jaeger pour le tracing distribué
  • Logs structurés en JSON pour chaque microservice
  • Corrélation avec les traces via les trace IDs
  • Instrumentation avec OpenTelemetry
  • Suivi d’une requête : vote-ui → vote-api → redis → worker → database

Cette approche permettrait une visibilité complète sur le comportement de l’application distribuée.

← CI/CD
Next →