OpenTelemetry en 2023

 (bit.kevinslin.com)
2 points par GN⁺ 2023-08-29 | 1 commentaires | Partager sur WhatsApp
  • Lancé en 2019 par la fusion d’OpenTracing et d’OpenCensus, OpenTelemetry s’est imposé en quatre ans comme un standard d’observabilité couvrant traces, métriques et logs
  • Son architecture centrale se divise entre spécification et implémentations, fournissant à la fois un référentiel de compatibilité entre vendors et des outils concrets d’instrumentation et de collecte
  • La spécification OTEL a stabilisé le tracing en 2020, les métriques en 2021 et les logs en 2023, si bien que tous les signaux sont désormais stable, même si la prise en charge des logs varie encore selon les SDK
  • OTLP et le Collector constituent la base commune pour envoyer et traiter les données d’observabilité, et des agents de vendors comme Grafana ou Datadog les implémentent également
  • OTEL élargit son périmètre avec le Collector, les Semantic Conventions, OpAMP, OTTL et la Demo, et devient une base commune de l’observabilité neutre vis-à-vis des vendors

La place actuelle d’OpenTelemetry

  • OpenTelemetry, ou OTEL, est né en 2019 de la fusion d’OpenTracing et d’OpenCensus
  • Au départ centré sur le tracing, le projet a ensuite élargi son champ à l’ensemble de l’observabilité
  • Son objectif est d’aider les organisations à fournir une télémétrie de haute qualité, universelle et portable
  • Quatre ans plus tard, OTEL dispose des bases suivantes
    • des standards stables pour les métriques, les logs et les traces
    • un Collector capable de recevoir, traiter et exporter la télémétrie dans n’importe quel environnement
    • des SDK permettant l’instrumentation du code dans les principaux langages
    • des standards supplémentaires autour des Semantic Conventions et de la gestion des agents
  • Aujourd’hui, OTEL est le projet le plus actif de la CNCF après Kubernetes, avec des contributeurs répartis parmi les principaux vendors de l’observabilité, et son protocole est désormais adopté presque universellement parmi les fournisseurs d’observabilité

Une architecture OTEL divisée entre spécification et implémentations

  • OTEL se compose principalement de la spécification (specification) et des implémentations (implementation)
  • La spécification définit la manière de capturer, collecter, traiter et exporter la télémétrie
    • elle s’apparente à un standard commun que les vendors doivent suivre pour être compatibles avec OTEL
  • Les implémentations sont des bibliothèques clientes et des outils qui manipulent les données de télémétrie
    • c’est la partie à laquelle les utilisateurs finaux sont directement confrontés lorsqu’ils instrumentent leur code
  • La stabilité du projet est généralement indiquée par signal
    • dans OTEL, un signal désigne un type de donnée de télémétrie comme les métriques, les logs ou les traces
  • Les principaux sous-projets sont les suivants
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification constitue la base d’OTEL et fournit les API, SDK et modèles de données qui servent de fondation aux autres standards OTEL
  • La stabilisation progresse par signal
    • septembre 2020 : tracing stable
    • novembre 2021 : métriques stable
    • avril 2023 : logs stable
  • À ce jour, la spécification OTEL est stable pour tous les signaux
  • Le signal de logs n’ayant été stabilisé qu’en 2023, de nombreux SDK OTEL ne prennent pas encore en charge les logs

SDK OpenTelemetry et auto-instrumentation

  • Le SDK OTEL fournit l’instrumentation côté client basée sur la spécification OTEL
  • Chaque SDK selon le langage possède son propre niveau de maturité pour les signaux métriques, logs et traces
  • Certains SDK prennent en charge l’auto-instrumentation (auto instrumentation) selon le langage de programmation
    • l’auto-instrumentation consiste à laisser le SDK injecter automatiquement des signaux dans le code applicatif, principalement des traces, afin de réduire la charge d’instrumentation manuelle
  • Dans des langages compilés comme go et rust, l’auto-instrumentation ne fonctionne pas
  • En revanche, en dehors du SDK, des outils basés sur eBPF ou sur un service mesh permettent d’obtenir une injection automatique des traces

OTLP 1.0 et le standard de transport des données

  • OTLP est un protocole wire commun destiné au transport des données d’observabilité
  • Il existe deux modes de transport officiels
  • Cette spécification est considérée comme stable et peut être implémentée dans tout service qui reçoit, traite et exporte des données OTEL
  • OTLP est implémenté par l’OpenTelemetry Collector, ainsi que par les agents de vendors de l’observabilité comme Grafana et Datadog

OpenTelemetry Collector 0.83.0

  • Le OTEL Collector est un agent neutre vis-à-vis des vendors qui collecte, transforme et transmet les données d’observabilité
  • Le Collector est composé des éléments suivants
    • receivers : reçoivent des données depuis plusieurs sources en mode push/pull
    • processors : transforment, filtrent, enrichissent ou dérivent les données en transit
    • exporters : envoient les données vers des destinations downstream
    • connectors : agissent à la fois comme receiver et exporter et relient plusieurs pipelines
    • pipelines : chaînes composées d’un receiver, de zéro ou plusieurs processors, puis d’un exporter
    • extensions : fournissent des fonctions hors traitement de télémétrie, comme basic auth ou health check
  • Ensemble, ces composants forment un pipeline d’observabilité capable de collecter la télémétrie depuis n’importe quelle source, de la traiter en transit, puis de l’envoyer vers la destination voulue
  • Le Collector se divise en deux projets
    • otel-collector : ne contient que les composants de base du Collector et regroupe surtout la logique directement liée au traitement des données OTLP
    • otel-collector-contrib : ensemble d’intégrations incluant les exporters et receivers pour la plupart des fournisseurs d’observabilité
  • Au moment de la rédaction, otel-collector-contrib comprend 91 receivers, 48 exporters et 24 processors
  • Il est recommandé aux utilisateurs finaux d’utiliser OpenTelemetry Collector Builder pour créer une version personnalisée de otel-collector-contrib ne contenant que les composants nécessaires
  • Des vendors comme AWS et Splunk proposent aussi leurs propres distributions OTEL

OpAMP et la gestion distante des agents

  • OpAMP est un protocole réseau pour la gestion distante des agents
  • C’est un standard relativement récent, ajouté à OTEL en 2022, qui fournit une méthode neutre vis-à-vis des vendors pour contrôler un ensemble d’agents
  • Les agents gérés peuvent être des instances de otel-collector ou des agents propriétaires de vendors implémentant OpAMP
  • OpAMP permet d’activer les fonctions suivantes
    • déploiement dynamique de configuration
    • mise à jour des agents
    • gestion des identifiants
  • À l’heure actuelle, l’implémentation Go de la spécification OpAMP est encore en cours de développement

Semantic Conventions et projets supplémentaires

  • Les OTEL Semantic Conventions définissent un ensemble commun d’attributs pour les données d’observabilité
  • Leur champ d’application couvre notamment les ressources cloud, les bases de données, les exceptions et les systèmes
  • Les Semantic Conventions sont utilisées par les SDK OTEL et s’appliquent automatiquement dans les SDK prenant en charge l’auto-instrumentation
  • Une sémantique commune permet la corrélation entre différents signaux
  • D’autres composants majeurs d’OTEL existent également
    • OpenTelemetry Transformation Language (OTTL) : un langage commun de transformation pour la télémétrie, conçu et implémenté dans otel-collector-contrib avec un accent sur les performances et la flexibilité
    • OTEL Demo : un site e-commerce basé sur des microservices qui présente les fonctionnalités d’OTEL et la plupart de ses SDK pour différents langages

Quatre années de transformation

  • OTEL est passé d’une fusion de spécifications de tracing concurrentes à un standard industriel de l’observabilité
  • Ces quatre dernières années ont servi à construire une base commune à l’échelle des vendors et des outils

À lire aussi

1 commentaires

 
GN⁺ 2023-08-29
Avis sur Hacker News

  • OpenTelemetry a deux problèmes

    1. Son identité est floue. On ne sait pas très bien s’il s’agit d’un standard sémantique, d’un protocole, d’une façade, d’une bibliothèque, ni quelle couche d’abstraction il fournit ; la réponse est plutôt « tout à la fois »
    2. On a l’impression que personne du côté d’OpenTelemetry n’a réellement instrumenté une bibliothèque. Il n’y a pas non plus de recommandations sur la manière dont les personnes qui instrumentent doivent utiliser les métriques, les traces et les logs, ni sur le fait de devoir utiliser les trois ou un seul. J’ai posé la question il y a deux ans, sans obtenir de réponse : https://github.com/open-telemetry/opentelemetry-specificatio...
    • D’accord. C’est comme si l’on vous donnait à la fois l’évier et la maison qui va avec, ce qui rend la documentation mince et confuse
      Dans le même esprit, je voulais implémenter un simple heartbeat pour comprendre l’usage d’une application de bureau, et vu le nom du projet, c’était étonnamment proche de l’impossible. Il y a eu peu de réactions aux questions, donc j’ai complètement abandonné l’idée d’utiliser OpenTelemetry : https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • D’accord. Une partie de ce qu’OpenTelemetry recommande est impossible avec le SDK réel
      Par exemple, on ne peut pas définir les buckets à proximité de l’endroit où l’on définit un histogramme. Il faut passer, à un endroit comme un exportateur global, une liste d’« overrides » qui associe les noms d’histogrammes aux buckets. Si une bibliothèque émet des métriques, cela devient très sale : https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • Ce sont de bonnes questions, mais je ne les trouve pas très importantes. Dans le domaine de l’observabilité, qu’il s’agisse d’OpenTelemetry ou d’un autre système propriétaire, il est difficile d’y répondre clairement
      Même sur les sites des entreprises leaders de l’observabilité, les articles sur l’instrumentation personnalisée font à peine quatre pages et ne couvrent que des notions très basiques. OTel n’est pas particulièrement en retard ; la réponse est généralement proche de « ça dépend ». Avec l’expérience, on peut démêler ces points qui déroutent les débutants
    • Ce qu’il fallait, c’était simplement maintenir 3 fichiers de schéma JSON
    • La troisième question est de savoir si c’est extensible

  • J’aime beaucoup OpenTelemetry et je veux tracer presque tous les spans. Si j’avais utilisé un fournisseur, les coûts m’auraient mis en faillite
    Avec l’instrumentation automatique Java, j’ai ajouté OpenTelemetry presque sans effort, et je l’envoie vers un ClickHouse auto-hébergé qui stocke plus de 700 millions de spans par jour sur une EC2 à 100 dollars : https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • Sur un petit projet personnel, j’envoie traces/logs/métriques vers ClickHouse via SigNoz. Cela représente environ 400 000 à 800 000 spans par jour (https://i.imgur.com/s0J6Mzo.png), et sur un unique t4g.small, le CPU est généralement autour de 11 % et les IOPS à 4 %
      Avec une rétention des traces d’un mois, signoz_index_v2 compte 26,9 millions de lignes pour 17.06GiB, trace_log 123 millions de lignes pour 2.64GiB, et samples_v2 environ 949 millions de lignes pour 345MiB, donc la compression est bonne. Si j’avais utilisé une machine ClickHouse conforme aux recommandations, j’aurais réduit le temps passé au tuning, mais même ainsi cela fonctionne bien
      L’inconvénient, c’est que les IOPS du petit disque sc1 sont autour de 4, donc ClickHouse met environ 5 minutes à démarrer, et l’UI de SigNoz est suffisamment fonctionnelle, mais il ne faut pas s’attendre au niveau de polish de Datadog
    • Il faut avoir un taux d’échantillonnage, tout en vérifiant que toutes les erreurs sont bien envoyées
      Dans mon ancien poste, nous ne collections que 5 % des traces qui n’étaient pas des erreurs
    • En pratique, la plupart des gens ne veulent pas exploiter leur propre stockage ClickHouse, et tous les ingénieurs ne manipulent pas SQL efficacement comme du code. Cela reste une configuration assez élégante
    • Le faible effort nécessaire à la configuration est aussi appréciable. C’est la combinaison instrumentation automatique Java + exportateur ClickHouse + plugin Grafana ClickHouse

  • OpenTelemetry m’a fortement déçu. D’après mon expérience, c’est un amas confus sur-conçu, et l’expérience d’utilisation par défaut est très hostile à l’utilisateur.
    Le projet se présente comme un format universel de traces/métriques/logs et comme un ensemble de bibliothèques plug-and-play avec des adaptateurs pour tout ce dont on a besoin, mais en réalité cela ressemble plutôt à un ensemble de bibliothèques incomplètes, dont l’implémentation interne fuit beaucoup, avec des adaptateurs de mauvaise qualité et pas tant de fonctionnalités que ça.

    • Je suis d’accord. Chaque fois que j’utilise le SDK, j’ai l’impression de devoir penser d’une façon orthogonale au bon sens. Rien ne fonctionne comme on s’y attend, tout comporte trois couches d’abstractions inutiles, et il faut passer par la porte de derrière.
      Beaucoup de fonctionnalités viennent avec des conditions du genre : quand, où, combien, sous quelle phase de la lune, quand Jupiter est visible dans le ciel, et pour quelle longueur de chaîne elles fonctionnent.
      Cela dit, si l’on fait abstraction des API de SDK qui fuient et des fonctionnalités à moitié implémentées, la promesse de remplaçabilité est tenue dans une certaine mesure. Avant OTel, tout relevait de piles propriétaires ; maintenant, on peut brancher un autre backend de logging sur un SDK standard et s’attendre à ce que ça fonctionne globalement. C’est moins bien qu’une pile intégrée verticalement, mais cela permet une concurrence et une évolution par morceaux sans devoir remplacer toute la pile d’observabilité ; du point de vue architectural, c’est donc une victoire partielle.
    • J’ai connu les mêmes douleurs, mais les alternatives qui prétendent être meilleures parce qu’elles ont une spécification OpenAPI ne le sont pas vraiment à l’usage : https://github.com/openzipkin/zipkin-api-example
      L’exemple se contente de montrer comment parser la spécification OpenAPI (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) avec des outils Swagger, générer automatiquement du code de liaison en Go, puis enregistrer une trace en appelant une fonction générée automatiquement.
      Il n’y avait absolument aucune documentation ni autre exemple, si bien que je me suis demandé si quelqu’un utilisait réellement cette approche ; au final, j’ai fini par utiliser directement l’API du service (https://zipkin.io/zipkin-api/#/) via des appels REST. OTel est pénible, mais les alternatives ne sont pas meilleures. À mesure que la mesure des SLO et des SLI devient plus importante, j’aimerais que ce domaine suscite davantage d’intérêt.
    • Dans ce cas, je me demande si l’on peut recommander une alternative, ou s’il faut simplement faire avec OTel.
    • Ce serait bien de pouvoir citer des expériences concrètes et des propositions d’amélioration.

  • Les bibliothèques officielles OTel ne fonctionnent pas encore très bien côté frontend web. Par exemple, dans leur état par défaut, il n’y a aucun moyen de relier les erreurs aux source maps.
    Le collecteur pour navigateur web publié par le projet OTel utilise Zone.js pour intercepter en contexte presque tout ce qui se passe dans le navigateur. Si vous avez utilisé Angular récent, vous savez que Zone.js peut parfois être assez douloureux et, en touchant au global, produire des comportements difficiles à prévoir.
    Je ne sais pas non plus ce qu’il en est d’un standard OTel pour des choses comme le session replay. Beaucoup de plateformes de télémétrie comme Sentry, Rollbar ou DataDog le prennent en charge. Les équipes backend semblent plutôt l’apprécier, et j’aime le fait que les spans puissent traverser les frontières et permettre de suivre tout le système via des tags uniques. En revanche, les payloads générés sont parfois très verbeux, alors que certaines plateformes de logging sont plus compactes. En pratique, cela ne m’a pas semblé être un gros problème.

    • Avec les Promise natives et async/await, il ne semble actuellement pas possible d’implémenter correctement quelque chose comme Zone.js.
      J’ai aussi essayé l’instrumentation manuelle, mais c’était sujet aux erreurs et verbeux. Les navigateurs auraient vraiment besoin de quelque chose comme https://nodejs.org/api/async_context.html#class-asynclocalst....
    • Sur la plupart des plateformes, Otel ressemblait davantage à un point de départ pour créer une bonne bibliothèque d’instrumentation.
      Dans notre package, nous ajoutons du session replay, un meilleur suivi des exceptions, etc. par-dessus l’implémentation du SDK navigateur Otel/Splunk. Malheureusement, ce genre de choses est loin d’être fourni par défaut. Cela dit, je pense que le fait de pouvoir relier une session frontend aux traces/logs backend a beaucoup changé l’expérience développeur : https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Cette documentation d’Otel vaut aussi le coup d’œil : https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      Elle ne résout pas complètement le problème, mais constitue un point de départ.
    • Real User Monitoring, l’instrumentation frontend de DataDog, ne m’a pas non plus semblé particulièrement aboutie. C’est d’une subtilité comparable à manipuler des briques Duplo.
      Je me demande s’il y a des gens qui ont ne serait-ce que commencé à faire du tracing frontend.
    • Je me demande si vous avez déjà regardé Grafana Faro. On peut le faire envoyer vers Grafana Agent, et Grafana Agent est open source et peut stocker les traces ailleurs.

  • Avec quelques collègues, on a eu cette idée un peu saugrenue qu’on n’avait plus besoin de logs. Il suffit d’ajouter des événements de span à la place des messages de log : https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    Ensuite, on ne logue que le titre du span et le lien vers le span correspondant dans Jaeger. Je ne l’ai essayé que sur des projets personnels, mais ça m’a semblé plutôt bien ; simplement, j’aimerais que l’interface de Jaeger prenne mieux en charge ce type d’usage
    En fait, ces collègues ont même fait une présentation sur le sujet. Si vous êtes près de Hanovre, en Allemagne, cherchez « Nie wieder Log-Files! » sur https://javaforumnord.de/2023/programm/

    • Selon à quel point le projet est greenfield, on peut même ne pas avoir besoin d’événements de span, sauf si l’on a seulement besoin de l’horodatage d’une action donnée et pas de sa durée
      Utiliser des spans pour toutes les actions significatives revient un peu à utiliser des logs structurés plus puissants. C’est difficile pour beaucoup de systèmes qui doivent conserver les logs existants en parallèle, mais si le projet est suffisamment greenfield, je le recommande
    • J’ai aussi envisagé cette approche, mais j’aime le fait de pouvoir comprendre grosso modo ce qui se passe avec des outils simples
      Pour utiliser des traces, il y a beaucoup de choses qui doivent fonctionner correctement. Ou alors c’est peut-être simplement que je manque encore d’expérience et que les outils m’intimident
    • C’était l’idée du projet Veneur de Stripe. Traiter spans, logs et métriques dans le même format, avec un roll-up « automatique » de la cardinalité selon les besoins
      Quand j’ai vu la présentation il y a quelques années, j’ai trouvé ça excellent, mais il me semblait que ce serait très difficile de convaincre des développeurs qui ne sont pas SRE : https://github.com/stripe/veneur
    • Il n’est même pas nécessaire d’envoyer les traces quelque part. On peut les conserver dans le processus et construire une API au-dessus de ces données de trace en mémoire
    • On tient le même discours dans mon entreprise. Ça a beaucoup de sens, et je pense qu’on pourrait presque supprimer complètement les logs

  • OpenTelemetry est un projet mené par le marketing, conçu naïvement et inefficacement façon comité, et il semble surtout avoir pour objectif de permettre aux CTO du Fortune X00 de cocher une case dans leurs documents de feuille de route stratégique
    Ce n’est pas quelque chose que quelqu’un qui a le choix devrait utiliser

    • Les autres commentaires de ce fil sont globalement favorables, voire très positifs ; j’aimerais entendre plus en détail ce qui ne va pas concrètement
    • En tant que fondateur de highlight.io, du point de vue consommateur, j’ai trouvé beaucoup de valeur dans OTEL. Nous l’avons utilisé pour étendre le support de langages pour plusieurs clients, et la communauté a été très réceptive
      Voici un exemple de changement que nous avons soumis : https://github.com/open-telemetry/opentelemetry-js/pull/4049
      J’aimerais que vous expliquiez pourquoi, selon vous, personne ne devrait l’utiliser
    • Je ne pense pas que cette appréciation soit juste. Ça ressemble plutôt à : « les logiciels open source exportent des métriques Prometheus et des traces Jaeger, nous voulons vendre un produit propriétaire qui soit une alternative, et nous ne voulons pas envoyer des patches à tous les projets »
      Datadog a effectivement mobilisé beaucoup de personnes pour ajouter le support de Datadog à des projets OSS. Se plonger dans des bases de code inconnues est une compétence puissante, donc ça a peut-être été plutôt bon comme début de carrière
      OTel pousse les projets open source à utiliser une couche d’abstraction, ce qui permet aux utilisateurs d’acheter une solution plutôt que de l’auto-héberger. Je n’en suis pas particulièrement fan, mais pour des services exploités par des gens en dehors de mon entreprise, j’envisagerais désormais OTel. Parce que si un utilisateur veut utiliser Datadog, nous ne serons pas ceux qui l’en empêchent
      Quand j’ai utilisé OTel à ses tout débuts, l’API Go était très inefficace, ce qui m’avait déçu. Il fallait un context.Context pour incrémenter un compteur, et les abstractions fuyaient, par exemple sans moyen de configurer les buckets d’histogramme lors de l’export vers Prometheus. J’imagine que c’est probablement corrigé maintenant
    • C’est excessivement dur. Le modèle de données me semble être un progrès dans la bonne direction
      Le processeur est aussi assez capable, et l’ensemble contrib de receivers et d’exporters est globalement correct. Je ne dis pas que c’est la meilleure solution, cela dépend des cas d’usage, mais une critique aussi forte ne me paraît pas justifiée. Pour contexte, je fais partie de l’équipe de maintenance de fluent-bit
    • Le fait de faire parler les services en OTLP et de simplifier la configuration applicative en envoyant les données vers le collector OTEL est excellent
      Du point de vue opérations, quelle que soit l’observabilité que les développeurs ajoutent au code, on peut imposer un filtrage centralisé, et l’application n’a besoin de parler qu’à un seul point d’entrée central
      Comme tout exporte de l’OTLP, quand on veut passer à un nouveau backend, il suffit de modifier un fichier YAML, sans réécrire les applications pour prendre en charge un nouveau backend de logs. Plutôt que de revenir à l’ancienne approche avec des bibliothèques de logging propres à chaque fournisseur, malgré ses défauts, je continuerais à choisir OTEL 10 fois sur 10

  • Je déteste vraiment la popup d’abonnement de ce blog. Il n’y a pas de bouton x, donc il n’est pas du tout évident qu’on puisse la fermer sans donner son e-mail
    Sous le bouton d’abonnement, il y a un « continue reading » très peu intuitif ; je ne pensais pas que ça fonctionnerait, et cliquer à l’extérieur ne fermait pas la popup. Ce genre de chose devrait être amélioré
    Côté OpenTelemetry, cela fait longtemps que je voulais tester s’il fournit toutes les fonctionnalités nécessaires pour envoyer les données vers Datadog. Mais si, en plus des fonctions de base, il faut toujours l’agent Datadog, cela fait encore une chose de plus à gérer et à expliquer, donc j’hésite
    Je me demande si quelqu’un l’a vraiment raccordé à Datadog. Le but n’est pas forcément de rester lié à Datadog, mais comme une bonne partie de nos alertes et de nos logs y sont actuellement, passer d’abord à OpenTelemetry devrait théoriquement nous permettre de migrer vers autre chose plus tard

    • Cette popup est une fonctionnalité de medium.com. Je suis d’accord, elle est très agaçante
    • Personnellement, j’ai trouvé le sondage encore pire. Il me demandait mon avis, j’ai cliqué sur une option, et j’ai été récompensé par une fenêtre création de compte en plein écran
      Quand j’ai appuyé sur retour, ça m’a renvoyé sur HN

  • Je me demande s’il existe encore un frontend qui ne rogne pas fortement les flux de revenus en termes de coûts de personnel, d’infrastructure et de licences
    Quand on reçoit plus de 2 000 requêtes par seconde, conserver seulement les logs coûte déjà cher

    • Si vous ne le faites pas encore, je recommande le sampling des traces. Datadog APM ne m’a pas impressionné, faute de configuration bon marché
      Nous exploitons notre propre stack Jaeger avec un sampling de 0,1 %, et par rapport à Datadog APM, le coût est négligeable
      Pour les métriques et les logs, le sampling n’est pas très utile, donc il n’y a pas de bonne réponse. Si la marge brute de Datadog est de 80 %, les coûts d’infrastructure représentent au maximum 20 % de ce que vous payez, et si vos coûts de personnel sont inférieurs à ces 80 %, vous pouvez réduire fortement les coûts en exploitant vous-même une stack open source. Même avec Datadog, on mène tous les trois mois un projet de réduction d’usage, donc de toute façon il faut continuer à s’en occuper
    • La réponse, c’est le sampling. Il suffit d’échantillonner 1 % des requêtes réussies et de collecter toutes les erreurs
      Le coût est un problème, mais vous pourriez être surpris de voir à quel point l’observabilité pèse plus lourd qu’on ne l’imagine sur un service. Ça consomme pas mal de CPU
    • Il faut définir ce que signifie « fortement ». Dans mon entreprise précédente, nous routions les traces vers Cassandra, les stockions dans un domaine AWS Elasticsearch, et les visualisions avec Jaeger
      J’avais aussi écrit quelques requêtes Elasticsearch pour produire des rapports de base permettant de trouver les requêtes lentes. En suivant les tutoriels OTEL/Jaeger, c’est une configuration assez standard
      Le volume était de quelques centaines de traces par seconde, et nous les collections toutes sans downsampling. La rétention pouvait être configurée à 7 jours, et au moment de mon départ il y avait eu très peu d’optimisation réelle. Le coût mensuel devait être de l’ordre de quelques dizaines à quelques centaines de dollars
      On peut définir le comportement du sampler de tracing via des variables d’environnement configurables sur les conteneurs. Voir OTEL_TRACES_SAMPLER dans la documentation : https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • La plupart des fournisseurs d’observabilité prennent désormais en charge OTEL. Le projet OSS auquel je contribue prend aussi en charge la collecte OTEL : https://github.com/grafana/tempo/
    • Je ne comprends pas pourquoi c’est downvoté. Nous avons le même problème, mais à l’échelle de 500 000 requêtes par seconde
      Nous utilisons actuellement Datadog, mais tout le monde sait que c’est beaucoup trop cher

  • La majeure partie de ce fil parle d’envoyer les métriques/logs avec OpenTelemetry vers des tâches de collecteurs auto-hébergées
    Utiliser une bibliothèque standard prise en charge par plusieurs outils de collecte comme ClickHouse est déjà utile en soi, mais un autre avantage est que la spécification permet de transmettre les ID de trace au-delà des frontières des systèmes
    Si vous et vos dépendances implémentez tous la spécification OpenTelemetry, vous pouvez obtenir des spans qui montrent finement ce qui s’est passé tout au long du parcours. Par exemple, vous pouvez savoir si le chargement lent d’une page était dû au chargement de pages disque dans la base de données, ou si un span du plan de métadonnées d’un service cloud était la cause d’une latence élevée

  • Je suis très satisfait des progrès d’OpenTelemetry. Quand j’ai poussé son adoption il y a quelques années, les développeurs hésitaient en disant que c’était nouveau et qu’ils n’en avaient jamais entendu parler, mais quand j’y suis revenu il y a un an, OpenTelemetry était partout dans nos systèmes, et le fournisseur de logs/traçabilité que nous utilisions était aussi en train de migrer dans cette direction