Le concept d’observability et l’évolution des outils

• Concept d’observability :

  • une mesure indiquant dans quelle mesure l’état interne d’un système peut être correctement déduit à partir des résultats (connaissances) de ses sorties externes
  • un système dynamique conçu pour estimer l’état du système à partir de la mesure des sorties
  • l’observability est devenue nécessaire avec la généralisation du cloud, des applications conteneurisées avec Docker et des architectures en microservices

• Différence entre observability et monitoring :

  • monitoring : ce que fait l’utilisateur ; cela montre ce qui ne va pas
  • observability : concept plus large qui englobe le monitoring ; elle fournit un contexte riche sur les mécanismes internes et aide à résoudre des problèmes système en profondeur ; elle montre aussi pourquoi quelque chose ne va pas

• Situations où une organisation a besoin d’observability :

  • lorsqu’un incident survient en production et qu’on se demande : « Quelles données permettent d’identifier la cause du problème, où se trouvent-elles et comment faut-il les examiner ? »
  • lorsqu’un service qui fonctionnait encore une minute auparavant rencontre soudain un problème, et qu’on se retrouve face à la question : « Où faut-il chercher la cause racine ? »
  • lorsqu’une organisation se demande : « Comment faire pour que l’équipe de développement détecte les symptômes d’un dysfonctionnement du service avant les clients ou les équipes de support/exploitation ? »
  • lorsqu’on cherche un moyen efficace de suivre les erreurs de service et de performance dans une architecture en microservices, ou qu’on se demande si cela peut être vérifié via des logs ou sous forme d’APM (Application Performance Monitoring)

• Évolution des outils d’observability :

  • depuis les années 2010, divers outils d’observability sont apparus dans l’industrie IT
  • en 2010, Google a présenté « Dapper », une infrastructure de traçage pour systèmes distribués à grande échelle
  • ensuite, Uber et Twitter ont respectivement créé les systèmes de traçage distribué « Jaeger » (Uber) et « Zipkin » (Twitter)
  • « Open Tracing » est ensuite apparu, un ensemble d’API standard destiné à modéliser et décrire en continu le fonctionnement des systèmes distribués
  • publication de « Open Census » : un ensemble de bibliothèques pour différents langages qui collecte les métriques applicatives et le traçage distribué, puis envoie les données en temps réel vers le backend
  • puis « Prometheus » est arrivé
  • en 2019, publication de « Open Telemetry (OTel) », un ensemble d’outils, d’API et de SDK unifiant Open Tracing et Open Census

• Open Telemetry :

  • un framework open source d’observability neutre vis-à-vis des fournisseurs
  • les données de télémétrie qui aident à analyser les performances et le comportement des logiciels comprennent les logs, les métriques et les traces ; Open Telemetry sert à les instrumenter, les générer, les collecter et les exporter
    • logs : métadonnées horodatées ; utilisées pour déterminer la cause racine d’un incident
    • métriques : données statistiques ou agrégées avec des tags clé/valeur mesurées dans le service ; valeurs capturées du service à l’exécution
    • traces : enregistrements des événements survenus à l’utilisateur et à l’application ; elles consignent le chemin de propagation d’une requête individuelle
  • mode d’utilisation : l’outil d’observability envoie une alerte -> on vérifie le contenu de l’alerte et on va sur le dashboard pour identifier la zone problématique -> on interroge en détail une partie précise de cette zone -> on retrouve et examine les logs -> on cherche les données de trace liées à ces logs pour en dégager des motifs -> on identifie alors le problème, on le corrige et on met en œuvre l’observability
  • la plupart des outils d’observability créés récemment prennent Open Telemetry en charge par défaut

• Pourquoi Open Telemetry est apparu :

  • auparavant, chaque backend d’observability disposait de ses propres bibliothèques d’instrumentation et agents pour envoyer les données depuis les outils, et il existait plusieurs façons d’instrumenter le code
  • il n’existait pas de format de données standardisé pour envoyer les données vers un backend d’observability
  • par la suite, Open Tracing et Open Census ont fusionné pour créer Open Telemetry, afin d’établir un standard unique

• SigNoz : outil APM open source

  • aide à surveiller les applications et à résoudre les problèmes
  • utilise le traçage distribué pour comprendre la stack logicielle côté utilisateur
    • surveille des métriques applicatives comme latency, requests per second et error rates
    • observe aussi des métriques d’infrastructure comme l’utilisation du CPU ou de la mémoire
    • suit les requêtes utilisateur à travers l’ensemble des services
    • permet de configurer des alertes sur les métriques
    • permet d’aller jusqu’à la trace exacte à l’origine du problème pour en trouver la cause racine
    • permet aussi de voir des flame graphs détaillés pour le suivi de chaque requête

[ninebow]

Merci pour cet excellent article !

[ironlung]

Merci pour votre commentaire ! :)

[kaistj]

Merci pour cet excellent article~

[ironlung]

Merci pour votre commentaire ! :)

[jujumilk3]

Comment surveiller le bon fonctionnement du monitoring ?

Je me posais une question un peu similaire à celle qu’on voit dans le manga Watchmen, mais je découvre qu’il existait le terme observability, merci.

[ironlung]

Merci ! En ce moment, on voit aussi émerger des outils qui simplifient l’observability grâce à l’IA. C’est un domaine sur lequel j’aimerais en apprendre davantage ! :)

[inthelife]

Merci pour ce bon article :)

[ironlung]

Merci beaucoup ! :D