L’essentiel de l’observabilité de la pile complète – DZone Refcardz

L’observabilité de la pile complète est la capacité de comprendre à tout moment ce qui se passe dans une pile technologique. En collectant, corrélant et agrégeant toutes les données télémétriques dans les composants, il fournit un aperçu du comportement, des performances et de la santé d’un système. Grâce à l’observabilité de la pile complète, les équipes peuvent comprendre en profondeur les dépendances entre les domaines et la topologie du système. Contrairement aux systèmes de surveillance traditionnels, l’observabilité de la pile complète permet aux équipes informatiques de réagir de manière proactive, de prévoir et de prévenir les problèmes en utilisant l’intelligence artificielle et l’apprentissage automatique, ce qui est tout sauf une exigence étant donné que la quantité de données collectées serait presque impossible autrement. La présentation de ces données sous la forme d’analyses et de tableaux de bord unifiés peut donner à l’observateur une image complète de la santé du système, par exemple, où les problèmes se sont produits et les solutions ont été introduites.

Télémétrie (MELT)

Pour atteindre l’observabilité d’un système, nous nous appuyons sur l’agrégation des données de télémétrie de quatre catégories. Ce sont les données brutes qui alimenteront le système – métriques, événements, journaux et traces (ou MELT) :

• Métrique: Une représentation numérique des mesures sur une période de temps. Ils peuvent être utilisés pour rendre compte de la santé d’un système. Des exemples de métriques incluent la quantité de mémoire utilisée à un moment donné, la taille de la file d’attente d’un courtier de messages ou le nombre d’erreurs par seconde.
• Événements: enregistrements horodatés immuables des événements dans le temps. Généralement émis par le service en raison d’actions dans le code.
• Journaux: Lignes de texte écrit décrivant un événement qui s’est produit à un moment donné, généralement le résultat d’un bloc de code en cours d’exécution. Les journaux peuvent être représentés en texte brut, en texte structuré (comme JSON) ou en code binaire. Ils sont particulièrement utiles pour dépanner les systèmes moins sujets à l’instrumentation, aux bases de données ou aux équilibreurs de charge, pour n’en nommer que quelques-uns. Le « Hello World » de base est généralement le premier journal qu’un développeur écrit – et il a tendance à être plus granulaire qu’un événement.
• Traces: Représente le flux d’une transaction ou d’une demande unique lors de son passage dans un système. Les traces doivent montrer le chemin suivi, la latence que chaque composant inflige sur le chemin et les informations pertinentes associées à chaque composant qui peuvent indiquer des goulots d’étranglement ou des problèmes. Ces flux de données doivent pouvoir répondre facilement et clairement aux questions sur la disponibilité et les performances d’un système.

Microservices

Les principe de responsabilité unique a d’abord été inventé par Robert C. Martin et est devenu la base de la philosophie des microservices :

« Rassemblez les choses qui changent pour les mêmes raisons. Séparez les choses qui changent pour différentes raisons.

Une architecture de microservices suit cette approche en organisant une application en services plus petits et faiblement couplés qui peuvent être développés, déployés et maintenus indépendamment. Les services communiquent entre eux via des API en tant que blocs de construction du système global. Cela peut fournir un développement plus agile dont les monolithes ne bénéficient pas. Les microservices peuvent être développés et corrigés séparément tout en isolant les autres composants des problèmes potentiels qui ont un impact négatif sur l’ensemble du système. Les microservices peuvent donner à une équipe de développement la liberté de sélectionner le meilleur ensemble de technologies pour le problème à résoudre — et peuvent être modifiés, améliorés et mis à l’échelle sans avoir à franchir les frontières des autres services.

Les microservices, cependant, ne sont pas le Saint Graal qui résout tous les problèmes, et les entreprises peuvent facilement atteindre des centaines ou des milliers de microservices, ce qui rend les politiques de sécurité, d’observabilité et de réseau plus complexes à gérer. C’est là qu’interviennent les maillages de services, en permettant une communication gérée, observable et sécurisée entre les services. Les maillages de services suppriment la logique en gouvernant la communication entre les microservices à partir des services et dans une couche d’infrastructure.

Bien que toutes les implémentations de service mesh ne soient pas les suivantes, la plupart des demandes seront acheminées entre les microservices via des proxys qui vivront dans leur propre infrastructure, découplant la logique métier de la fonction réseau. Les mandataires individuels sont assis à côté du service et sont parfois appelés « side-car » pour la même raison. Tous ces proxys découplés forment ensemble un réseau maillé de services. Sans le maillage de services, les microservices doivent régir la communication de service à service, et non seulement cela peut devenir un point de défaillance caché, mais sa maintenance devient également plus coûteuse.

Les maillages de services peuvent aider à apporter de la visibilité dans la couche d’application sans modifications de code, ce qui facilite la configuration de la collecte de métriques ; comme tout le trafic passe par les proxys dans le maillage, cela permet à l’observateur d’avoir une plus grande visibilité sur toutes les interactions de service. Chaque proxy rendra compte de sa partie de l’interaction, fournissant des métriques telles que le trafic proxy entrant et sortant, des métriques de niveau de service. Les journaux d’accès avec les appels de service et les traces distribuées, que le maillage génère via des informations sur chaque service qu’il contient, facilitent le suivi d’une demande sur plusieurs services et proxys.

Étant donné que les microservices sont distribués par nature, ils peuvent être difficiles à surveiller et à observer. Corréler les journaux de nombreux services différents et les parcourir pour déterminer où les problèmes peuvent survenir est l’un des principaux points faibles d’une telle architecture.

Traçage distribué

Comme mentionné précédemment, le traçage distribué permet aux équipes de développement et de DevOps de déboguer et de surveiller des systèmes distribués complexes tels que les microservices en suivant les transactions d’un service à l’autre, tout au long de la pile. Cette approche holistique permet aux équipes de prendre des décisions éclairées en cas de besoin en combinant la surveillance côté serveur et côté client avec la puissance des outils de visualisation. Cette est l’observabilité de bout en bout.

Un système de traçage distribué collecte des données au fur et à mesure que les demandes passent d’un service à l’autre, enregistrant chaque segment sous la forme d’une étendue (ou d’une étape) qui contient les détails et est combiné en une seule trace. Une fois terminée, une trace représentera l’ensemble du parcours d’une demande tout au long de son parcours dans le système. L’image suivante montre un graphique en flammes, qui est l’une des visualisations préférées pour les traces. Il montre le chemin d’exécution d’un système représenté par la figure 5.

Une travée est, par exemple, la Courrier de recherche action dans le microservice Dispatch qui a trois étendues enfants. En combinant les étendues dans une trace et en exposant la relation enfant-parent entre elles, il devient possible de visualiser la granularité de la trace, les dépendances et la durée de chaque dépendance.

En pratique, le traçage distribué commence par une seule requête ou transaction. Chaque requête est marquée d’un identifiant unique qui est souvent appelé identifiant de trace ou de corrélation qui identifiera désormais cette transaction spécifique en la transmettant dans les en-têtes de requête propageant le contexte de trace entre les requêtes suivantes.

Visualisation et rapports

Il est difficile de rassembler et de corréler toutes les données d’un système, en particulier sans les outils ou techniques appropriés pour visualiser et traiter la télémétrie de manière significative, ce qui est essentiel. Être capable de comprendre les dépendances dans l’ensemble de la pile, ainsi qu’entre les services, les processus et les hôtes, donne aux observateurs et aux équipes SRE la possibilité de prédire et de comprendre la topologie de leur service.

La création d’une base de référence pour chaque composant du système, l’automatisation de la découverte de nœuds et l’ajout d’instruments aux applications peuvent aider à passer de la configuration et de la configuration manuelles à des alertes proactives et à un système de reporting basé sur la corrélation des données collectées. Dans les environnements multi-cloud, les applications peuvent atteindre des millions de composants, ce qui rend particulièrement difficile la compréhension du contexte entre eux. Une façon de visualiser les relations entre ces composants consiste à utiliser des cartes topologiques.

L’analyse des traces distribuées est souvent l’un des moyens les plus efficaces d’effectuer une analyse des causes profondes, pour laquelle il existe des aides à la visualisation utiles qui aident au profilage.

Tableaux de flammes ou de glaçons

Les graphiques en flammes ou en glaçons aident les développeurs à voir la relation entre les appels de service et l’impact sur la trace unique globale, comme une latence ou des erreurs inhabituellement élevées et leur impact sur les autres appels et services. Ils représentent chaque appel sur une trace distribuée sous la forme d’une ligne horizontale (voir Figure 6) ou verticale (voir Figure 7) qui est horodatée et contient des détails pour chaque intervalle.

Tracer la carte

Une carte de trace montre la connexion entre les travées et permet de comprendre rapidement la relation entre les services.

Arbre de trace

Une arborescence de trace est similaire à une carte de trace mais est représentée verticalement avec l’étendue parent comme nœud racine.

Diagramme de rayon de soleil

Un diagramme d’éclatement solaire représente une trace utilisant un ensemble d’anneaux et de demi-anneaux. Le cercle est l’étendue parent et les demi-anneaux déployés représentent la relation parent-enfant entre eux.

Interrogation de télémétrie

Stocker toute la télémétrie d’un système en un seul endroit est très puissant ; cependant, les équipes informatiques doivent être en mesure d’interroger ces données afin de répondre à des questions significatives. Heureusement, les équipes peuvent s’appuyer sur des langages de requête (comme SQL, Kusto, etc.) pour l’analyse. L’intention de ces langages de requête est de fournir une requête de requête en lecture seule qui traitera les données et renverra un résultat. Ce résultat peut ensuite être utilisé pour créer des visualisations, effectuer un dépannage, effectuer une analyse commerciale, etc.

Voici un exemple de requête SQL qui renverra les opérations les plus lentes au cours de la dernière heure :

SELECT service, 
   span_name, 
   ROUND( 
       approx_percentile(0.95, percentile_agg(duration_ms))::numeric, 
       3 
   ) as duration_p95, 
   ROUND(avg(duration_ms)::numeric, 3) as duration_avg 
FROM span 
WHERE start_time > NOW() - INTERVAL '1 hour' 
   AND parent_span_id = 0 
GROUP BY service, 
   span_name 
ORDER BY duration_p95 DESC 
LIMIT 10 

Et le résultat serait :

Sur la base de ces informations, nous pouvons immédiatement vérifier qu’il y a un problème de performance dans le service frontend pour le /panier/paiement point final, car bien que la moyenne puisse être considérée comme bonne (500 ms), au moins 5% des utilisateurs auront une mauvaise expérience (~25 secondes). Avoir la possibilité d’utiliser des langages de requête pour analyser ces données et les corréler est très puissant. Dans l’exemple ci-dessus, nous pourrions croiser les informations des opérations les plus lentes dans le point de terminaison problématique avec des métriques telles que l’utilisation du processeur, la consommation de mémoire, etc. Combiner OpenTelemetry avec la flexibilité d’un puissant langage de requête…