Qu’est-ce que l’observabilité ?

5 minutes

Avant de vous plonger dans le code, prenons un pas en arrière et parlons de l’observabilité. Vous devez disposer d’outils qui vous aident à comprendre l’état interne d’un système en fonction de ce qui est visible en externe.

Pourquoi implémenter l’observabilité ?

Il existe plusieurs raisons pour lesquelles l’observabilité est un aspect crucial du développement et de l’amélioration des applications natives cloud :

Comprendre le comportement du système: L’observabilité fournit des insights sur la façon dont votre application effectue et où des goulots d’étranglement ou des erreurs se produisent.
Débogage et résolution des problèmes: Lorsque des problèmes surviennent, les outils d’observabilité peuvent fournir des informations détaillées sur ce qui se passait dans le système au moment du problème.
Amélioration continue: L’observabilité n’est pas seulement pour identifier et résoudre les problèmes—qu’elle est également utilisée pour l’amélioration continue. En surveillant les performances du système au fil du temps, vous pouvez identifier les opportunités d’optimiser votre code, d’améliorer les performances du système et d’améliorer quantitativement l’expérience de vos utilisateurs.
détection proactive des problèmes: Avec les outils d’observabilité appropriés en place, vous pouvez souvent détecter les problèmes avant même que vos utilisateurs ne les voient.

L’implémentation de l’observabilité dans les applications natives cloud n’est pas seulement une bonne pratique, c’est une nécessité de maintenir, d’optimiser et d’améliorer continuellement vos applications. Il permet aux développeurs de fournir des applications fiables et performantes et fournit les insights nécessaires pour prendre des décisions éclairées.

Les trois piliers de l’observabilité

Il existe trois piliers principaux de l’observabilité :

Journaux d’activité : Les journaux fournissent des enregistrements détaillés des événements qui se produisent dans une application ou un système. Dans votre application, vous pouvez utiliser Microsoft.Extensions.Logging l’infrastructure pour journaliser les événements.
Métriques : Les métriques font référence à des mesures et compteurs numériques qui fournissent des informations sur les performances et l’intégrité d’un système. Par exemple, les taux de requête, les temps de réponse, l’utilisation du processeur/mémoire et les taux d’erreur. Dans votre application, vous pouvez avoir des mesures spécifiques dont vous avez besoin pour effectuer le suivi.
Suivi distribué: Ce processus implique le suivi d’une requête au fur et à mesure qu’elle se propage à travers tous les micro-services de votre application native cloud. Chaque service journalise les données de suivi telles que les ID de requête qui vous permettent de mettre en corrélation les événements entre les services. Le suivi distribué est également utile pour le débogage des problèmes de performances et des erreurs dans les systèmes complexes.

Ensemble, ces trois piliers offrent une observabilité complète dans un système.

Sources de données pour la télémétrie

Dans l’application cloud native de votre entreprise, vous pouvez choisir de collecter plusieurs sources de données de télémétrie :

Journaux d’application: Les applications génèrent des journaux qui fournissent des informations détaillées sur son fonctionnement et ses erreurs s’ils se produisent. La journalisation est une source riche de données de télémétrie.
Bases de données : Les bases de données peuvent fournir des données de télémétrie sur les requêtes qu’ils traitent, les temps d’exécution et toutes les erreurs qui se produisent.
requêtes et réponses HTTP: Les requêtes et réponses HTTP entre vos microservices fournissent des données de télémétrie riches et précieuses. Ces données incluent les en-têtes de requête et de réponse, le contenu du corps, les codes d’état et les informations de minutage.
données de performances côté client: Dans les applications natives cloud avec un serveur frontal, vous pouvez collecter les données de performances côté client. Ces données peuvent inclure les accès aux pages, les temps de chargement et les temps d’interaction de l’interface utilisateur.
Métriques d’infrastructure: Si votre application est hébergée dans un environnement cloud, vous pouvez collecter des métriques d’infrastructure telles que l’utilisation du processeur, l’utilisation de la mémoire, le trafic réseau et les opérations d’E/S de disque.

En collectant et en analysant ces données de télémétrie, vous pouvez obtenir des insights précieux sur les performances et l’intégrité de votre application.

Implémenter l’observabilité

Pour ajouter l’observabilité à votre application native cloud, procédez comme suit :

Ajouter une journalisation.
Activez les métriques et définissez des métriques personnalisées à capturer.
Activez le suivi distribué avec OpenTelemetry et Zipkin.
Instrumentez votre application, là encore avec OpenTelemetry et en ajoutant des données de télémétrie à votre code.
Analysez les données de télémétrie, avec Prometheus, Grafana ou Visual Studio Online Application Insights.

Présentation d’OpenTelemetry

Comment OpenTelemetry contribue-t-il à ajouter l’observabilité à votre application et pourquoi existe-t-il une prise en charge aussi approfondie de celle-ci dans .NET ? OpenTelemetry est une infrastructure d’observabilité open source. Il fournit un moyen standard, indépendant du fournisseur, de générer des données de télémétrie.

OpenTelemetry normalise la façon dont les données de télémétrie sont collectées et transmises aux plateformes principales. Il permet de combler les lacunes de visibilité en fournissant un format commun d’instrumentation sur tous vos microservices. Vous n’avez pas besoin de réinstrumenter du code ou d’installer différents agents propriétaires chaque fois qu’une plateforme back-end change.

Étant donné qu’il s’agit d’une norme ouverte, il prend en charge de nombreux autres outils en dehors de .NET. OpenTelemetry est configuré pour utiliser des extensions qui permettent aux exportateurs de créer des données de télémétrie à tous les différents outils. Cela signifie que vous pouvez utiliser les mêmes outils pour surveiller les microservices quel que soit le langage dans lequel ils sont écrits.