Transformez les traces en métriques avec OpenTelemetry

Le tracing distribué fait la lumière sur les mécanismes complexes de l'infrastructure d'une application et offre un aperçu des moindres détails des demandes et des transactions. Parce qu'elles consolident l'enregistrement d'événements qui ont eu lieu sur l'ensemble d'un système distribué, les traces sont indispensables au diagnostic des causes profondes et à l'identification des anomalies de performances. Toutefois, s'ils sont inestimables au début, leurs riches détails présentent des défis pour le monitoring à long terme en raison de la montée des coûts et de la diminution des rendements dans le temps.

Bienvenue dans le monde des métriques ! Un monde où l'agrégation des données dans le temps vous apporte un aperçu complet de la santé et des performances du système tout en étant nettement plus rentable pour l'observation prolongée. Ce changement promet non seulement l’efficacité, mais aussi une perspective durable plus large sur la dynamique du système.

Imaginez que vous puissiez maîtriser la capacité de transformer les données de traces en métriques durables et très informatives ; une transformation qui combinerait des informations immédiates et détaillées du tracing avec la perspective agrégée à long terme des métriques.

Ce billet de blog vous guide tout au long du processus de conversion des traces en métriques à l'aide d'OpenTelemetry (ou Otel) et propose la méthode la plus simple pour obtenir des métriques importantes durables à partir de vos données de traces.

Les problèmes sont mieux résolus avec les métriques

Les coûts de votre solution d'observabilité dépendent des fournisseurs que vous utilisez et de la taille de votre infrastructure, mais ce n'est un secret pour personne que l'observabilité peut coûter cher. Pour une solution d'observabilité complète, le tracing distribué doit comprendre comment les demandes individuelles et les transactions circulent à travers votre infrastructure, les métriques pour capturer l'état et les performances de vos systèmes dans le temps, et les logs pour fournir des informations contextuelles détaillées sur des événements et erreurs spécifiques au sein de vos systèmes. 

Les traces sont très granulaires et détaillées, et nécessitent un espace de stockage et des ressources informatiques considérables pour le traitement et l'analyse. En agrégeant ces données en métriques, les organisations peuvent réduire considérablement le volume des données stockées et traitées, et réduire ainsi les coûts d'infrastructure. 

Par exemple, l'ingestion de 3 000 traces avec 7 spans a généré 0,0176 Go d'ingestion. En comparaison, les métriques transformées envoyées par Collector pour la même quantité de traces a généré seulement 0,0095 Go d'ingestion, soit une diminution de près de 50 % de l'ingestion pour les métriques transformées. Évaluez votre ingestion avec ce référentiel.

Planification des capacités et allocation des ressources

Les données de traces peuvent être utilisées pour aider à la planification des capacités en identifiant les goulots d'étranglement et en comprenant les dépendances. Vous pouvez identifier les endroits où les ressources pourraient être insuffisantes et prédire comment les changements dans un domaine pourraient avoir un effet sur les autres. Pour une planification efficace des capacités, les métriques fournissent des informations précieuses et détaillées sur les tendances d'utilisation et la consommation des ressources, ce qui permet de prendre des décisions éclairées concernant la scalabilité et la répartition des ressources. Ces prévisions contribuent à l'optimisation des coûts et permettent de garantir que le système peut répondre aux demandes futures.

Alertes et détection des anomalies

Les métriques sont essentielles à la mise en place de systèmes d’alerte efficaces. En établissant des seuils basés sur des données métriques, les équipes peuvent être rapidement informées de la présence d'anomalies ou d'écarts par rapport au comportement normal, ce qui permet de prendre rapidement des mesures correctives. Il est facile de définir un seuil d'utilisation du CPU ou du temps de réponse. Parce qu'elles sont très détaillées et spécifiques aux demandes individuelles, les traces ne se prêtent pas aussi facilement à la création d'un seuil efficace d'alerte.

Identification des goulots d'étranglement des performances

Avec les traces, vous obtenez la visibilité sur des transactions ou des demandes individuelles, ce qui ne se traduit pas par une compréhension des modèles d'utilisation globaux sans une agrégation et une analyse significatives. Les métriques fournissent des vues granulaires (par service ou par conteneur, par exemple) et agrégées (l'utilisation totale du CPU sur un cluster, par exemple). Cette flexibilité permet d’explorer en profondeur certaines zones de préoccupation ou de garder une vue d’ensemble sur la santé du système.

Transformation des traces en métriques avec OpenTelemetry Collector

OpenTelemetry est un framework d'observabilité robuste et open source équipé d'une boîte à outils pour générer, collecter et gérer les traces, métriques et logs. Un composant essentiel du framework est OpenTelemetry Collector, un outil polyvalent qui simplifie l'orchestration des pipelines de données pour ces types de télémétrie. Après avoir collecté des métriques, traces et logs via des agents Otel comme Collector, vous pouvez transformer les données via un pipeline d'extraction, de transformation et de chargement (ETL). Chaque pipeline se compose de quatre composants clés : les récepteurs, les processeurs, les connecteurs et les exportateurs. Aujourd'hui, nous allons aborder le processeur et le connecteur des métriques de span et nous verrons les avantages du connecteur sur le processeur.

Le processeur des métriques de span

Le processeur des métriques de span a été initialement conçu pour agréger les données de span dans les traces d'OpenTelemetry. Il visait à faire le lien entre les données télémétriques à l'analyse des métriques. Cependant, sa conception, qui combinait le modèle de données d'OpenTelemetry aux conventions d'affectation de noms de Prometheus pour les métriques et les attributs, a malencontreusement compromis sa capacité à rester agnostique à la logique de l'exportateur. Cette approche était en contradiction avec la mission principale d'OpenTelemetry consistant à normaliser les données télémétriques sur les différents outils et plateformes. Consciente de ces défis, la communauté OpenTelemetry a depuis déclaré le processeur de métriques de span obsolète et l'a remplacé par le connecteur des métriques de span.

Qu'est-ce qu'un connecteur ?

Un connecteur permet d'envoyer des données télémétriques entre différents pipelines de collecte en les connectant. Il agit en tant qu'exportateur sur un pipeline et récepteur sur un autre. Autre avantage du connecteur : il simplifie la configuration de Collector en unissant deux pipelines de télémétrie. En effet, dans le cas des processeurs, vous devez configurer manuellement les récepteurs et les exportateurs si vous travaillez avec deux pipelines.

Le connecteur des métriques de span

Le connecteur des métriques de span est un port du processeur des métriques de span créé pour améliorer certains des problèmes rencontrés dans le processeur. Certaines des améliorations modifiaient les conventions d'affectation de noms pour les aligner sur le modèle de données Otel, la prise en charge des histogrammes exponentiels d'OpenTelemetry et la génération des champs d'application des ressources des métriques qui correspondent au nombre de champs d'application des ressources des spans. Cela signifie que davantage de métriques sont maintenant générées.  

Configuration de Collector

La configuration de base du connecteur de métriques de span est relativement simple. Vous trouverez ci-dessous la configuration utilisée dans une démo que j'ai créée pour montrer le connecteur des métriques de span. Une fois que vous avez configuré le connecteur des métriques de span lui-même, vous devez l'inclure en tant qu'exportateur pour le pipeline des traces et récepteur pour le pipeline des métriques. Cette configuration comprend les données de tracing d'origine et les métriques transformées à partir de ces données envoyées à un backend d'observabilité, qui dans ce cas est New Relic. 

Échantillonnage

Si vous utilisez le tracing distribué, il y a de fortes chances que vous utilisiez une forme d'échantillonnage. Que vous utilisiez l'échantillonnage en début de workflow, l'échantillonnage en fin de workflow, ou les deux, il est important de comprendre comment optimiser la valeur de ce processus.

Implémentation du connecteur des métriques de span avec l'échantillonnage en début de workflow

L'échantillonneur par défaut d'OpenTelemetry est un composite de deux échantillonneurs : ParentBased, qui a un paramètre obligatoire pour savoir quel échantillonneur utiliser pour les spans racine ; et, dans ce cas-ci, l'échantillonneur par défaut, AlwaysOn. Comme son nom l'indique, AlwaysOn échantillonne toujours un span avec un span parent. Avec l'échantillonneur par défaut, vous obtenez les métriques de toutes les traces envoyées à Collector lors de l'utilisation du connecteur des métriques de span. Les ajustements apportés à la configuration par défaut de l'échantillonneur auront un effet sur la précision des métriques transformées à partir des données de traces échantillonnées. Si vous souhaitez obtenir des métriques à partir de toutes vos traces et continuer d'échantillonner vos données de traces, vous pouvez mettre en place le processeur d'échantillonnage probabiliste. Par défaut, ce processeur échantillonne les données de tracing selon un pourcentage basé sur le hachage traceId.

Implémentation du connecteur des métriques de span avec l'échantillonnage en fin de workflow

L'échantillonnage en fin de workflow vous permet d'échantillonner les traces en fonction de critères spécifiques dérivés des différentes parties d'une trace. Grâce à cette technique, vous pouvez transformer toutes vos traces en métriques, puis n'échantillonner que les traces intéressantes. Ainsi, vous pouvez mieux contrôler les coûts, mais tout contrôle entraîne des difficultés au niveau de l'implémentation et des opérations d'échantillonnage en fin de workflow. Dans la démo fournie, nous utilisons un autre connecteur. Le connecteur forward sert au transfert des données d’un pipeline à un autre. Il nous permet d'obtenir des métriques à partir de toutes les traces, puis de les transmettre à un deuxième pipeline de tracing où nos règles d'échantillonnage sont appliquées avant l'exportation vers un backend d'observabilité.

Conclusion

La transformation des traces distribuées en métriques est une méthode puissante pour améliorer les stratégies d'observabilité et de monitoring. Cette pratique fournit non seulement un moyen plus efficace de gérer les données télémétriques, mais elle garantit également que les organisations peuvent maintenir des niveaux élevés de performances et de fiabilité du système. L'adoption de cette approche peut conduire à d'importantes économies et à une meilleure compréhension des performances du système, ce qui permet ensuite d'améliorer la qualité des services et la satisfaction des clients.

En ce qui concerne votre stratégie d'observabilité, les traces distribuées et les métriques jouent un rôle important. En apprenant à tirer parti de leurs forces et faiblesses uniques, vous pourrez profiter au mieux de vos données télémétriques.