Là, maintenant, tout de suite, êtes-vous capable de dire si votre site internet fonctionne correctement ? Et en cas d’incident en pleine nuit, pouvez-vous déterminer la chronologie des évènements ? C’est à ces questions que la télémétrie apporte une réponse, en instrumentant votre code et en envoyant les données collectées dans un outil d’analyse. Mais quel est le meilleur ? Est ce qu’il existe des solutions (presque) gratuites ? Peut-on changer d’avis facilement ? C’est là qu’OpenTelemetry intervient. OpenTelemetry propose une API de télémétrie, indépendante du langage et indépendante du service d’analyse utilisé. Fortement encouragé (et déjà supporté!) par les principaux acteurs du marché, poussé par une communauté active, ce protocole a tout pour devenir un standard de communication pour la télémétrie. Dans cette conférence nous aborderons les concepts fondamentaux de cette API, l’écosystème PHP existant, ainsi que des idées à mettre en pratique (et en production !) dès la semaine suivante.
_ Merci ! Ceci est un test. Ça va ? J'ai toujours rêvé de faire ça. C'est pourquoi vous êtes là. Vous voulez savoir pourquoi quand vous êtes une file d'attente la fille d'à côté va plus vite. C'est une illusion, ce n'est pas vrai.
Maintenant, on va parler d'OpenTelemetry. On va savoir si ça peut être un standard pour surveiller vos applications. Standard, c'est difficile à garantir dans l'Internet. Il n'y a pas de chef de l'Internet pour vous dire : "Aujourd'hui, c'est comme ça qu'on fait."
À chaque fois que j'entends le mot standard, je pense à cette bande dessinée que vous connaissez peut-être. Je l'adore. Un jour, il y a 14 standards en compétition. Il n'y en a qui dit que c'est ridicule d'avoir 14 standards. On va faire le standard. Vous vous retrouvez avec 15 standards en compétition. Est-ce qu'OpenTelemetry sera dans ce cas ? On va essayer de se faire une opinion.
Je travaille chez PlatformSh. Particulièrement dans l'équipe Blackfire. Il se trouve que Blackfire fait un outil de monitoring de profiling. Ça explique exactement pourquoi je suis là. Ce sujet m'a intéressé. Si vous êtes curieux, à propos de Blackfire, on est sponsor et il y a un stand. Vous dites que vous venez de ma part. Ça ne fait rien du tout, mais ça débloque la conversation.
On est nombreux. Vous avez tous des profils différents, j'aimerais juste rappeler ce que c'est que le monitoring. Je vais vous donner ma définition. Suivant si vous êtes en free-lance, en start-up, en grosse entreprise, ça peut avoir plein de définitions et de connotations différentes. Pour moi, le monitoring, c'est les outils qui permettent de répondre à cette question : "Est-ce que ça marche ?" Rapidement. Si ça vous prend une semaine, ce n'est pas intéressant.
La deuxième question, c'est : "Pourquoi ça ne marche pas ?" À partir du moment où vous avez des outils qui vous donnent rapidement la réponse à ces questions, pour moi, on peut appeler ça le monitoring.
Une bonne image de comparaison, le cockpit d'un avion. Un pilote ou une pilote peut conduire dans la nuit ou avec du brouillard. Il se fie à ses instruments de mesure et il sait si ça marche ou si ça ne marche pas. L'analogie marche pareil avec le monitoring. Si vous avez besoin de vous connecter en SSH pour savoir si ça marche, ce n'est pas terrible. Là où ça s'arrête, c'est dans un cockpit. Vous avez des manettes. Je redresse parce que je tombe. Je suis un bon pilote. Vous tirez sur les boutons, etc. dans le monitoring, ce sera autre chose. Le monitoring répond à la question. Ce n'est pas forcément agir sur l'environnement. L'autre point, c'est l'alerting, très complémentaire du monitoring. C'est-à-dire avoir des trucs qui vous envoient des notifications, etc. C'est intéressant, mais ce n'est pas ce qui vous aide à dire si ça marche maintenant ou pas. Ça vous dit plutôt qu'il y a quelque chose. C'est intéressant, mais c'est à côté. Je n'en parlerai pas spécialement ici.
Maintenant que je vous ai dit un peu ce que c'était que le monitoring, la question que vous devez vous poser : "Est-ce que j'en ai besoin ?" Ce n'est pas parce que je suis sur scène que ce que je dis est vrai et utile. Est-ce que vous avez besoin de développement... Non, pardon, de monitoring ? Ça dépend, bien sûr. Pour répondre à cette question, rien de tel qu'une autre question. Combien de temps votre application peut-elle rester en panne ? Ça paraît bête, mais il faut se rendre compte ici que l'on ne parle pas de si on peut empêcher les bugs ou si on peut avoir une application de meilleure qualité. On parle juste de temps. Combien de temps votre application pour rester en panne ? On est sûr de la qualité de service. Avoir du monitoring ne vous fera pas développer des features plus rapidement sans vague, c'est juste d'être sûr de minimiser le temps où il y aura un bug visible par tout le monde. Si c'est un petit blog perso pour la famille, vous ne perdez pas d'argent. Ensuite, quel investissement vous avez à faire pour le monitoring ? Ça dépend directement du temps que vous pouvez laisser en panne. À terme, on a tous du monitoring et sur nos utilisateurs. Ils nous disent que ça ne marche pas. Là, c'est du monitoring, mais ça peut être mieux de le savoir avant et dans le meilleur des cas, réussir à anticiper les moments où ça ne marche pas. Par où commencer quand vous avez zéro monitoring ? Vous vous dites que ça a l'air intéressant, mais par quoi on commence ?
Je vais vous donner des outils par ordre de difficulté croissante avec les plus et les moins. On va discuter de tout ça. Un premier outil. Quand j'étais dans des conditions de start-up, c'est idéal pour commencer. C'est une solution Analytics. Vous avez des graphs sur le nombre d'utilisateurs, d'où ils viennent, ce qu'ils tapent comme mots-clés. C'est simple à mettre en place et ça donne des donnés business. C'est intéressant pour une petite structure. L'inconvénient, c'est que ça fait surtout du monitoring business, c'est-à-dire que si votre base de données est en panne, ça ne vous dira pas pourquoi. Et ce n'est même pas sûr que ça nous dise qu' il y a un problème. Est-ce qu'il y a moins de gens sur la page parce qu'il y a un problème ? Ce n'est pas du monitoring technique et applicatif. Mais c'est mieux que rien et c'est lié au frontend. Ça fait toujours un petit bout de JavaScript exécuté par le navigateur. S'il y a quelqu'un de mauvaise intention sur le script, ce sera complètement invisible. Vous ne verrez pas tout passer.
Autre solution, pas trop intrusive dans votre code, tout ce qui est à base de sondes http. Vous imaginez votre site comme une boîte noire. Ça peut être très basique. Vous regardez si ça fait 200. Si ça fait 200, c'est bon. Ça peut être des tests un peu plus évolués avec un scénario. J'attends de recevoir de telles données, je recherche un tel pattern, on peut suivre ça dans le temps et voir comment ça évolue. L'avantage, c'est que ça marche partout, même sur des API et des sites qui ne sont pas les vôtres. Ça peut être pratique, vous utilisez une application de paiement, rien ne vous empêche de vérifier que c'est toujours au top. Si un jour ça ne marche pas, ça peut répondre à la question de pourquoi ça ne marche pas. C'est les API qui sont en rade par exemple. Ça peut être intéressant. Après, l'inconvénient en boîte noire, c'est que vous avez peu de contexte sur le pourquoi ça ne marche pas. Après, il faut écrire les scénarios à la main. Ce ne sont pas forcément des vrais scénarios. Il faut penser à tous les scénarios. C'est un peu l'inconvénient.
On va parler ensuite de quelque chose de très connu, les logs. Beaucoup de logiciels fournissent des logs et tout ça peut être agrégé au sein de logiciels qui est Kibana, ici pour l'exemple. C'est très détaillé. Vous en avez partout. Il y en a tellement de partout c'est tellement détaillé, que c'en devient le principal inconvénient, c'est très volumineux. C'est parfois difficile à explorer. Ça va super bien répondre à la question du pourquoi ça ne marche pas. Vous allez vraiment savoir ce qu'il s'est passé. Si vous arrivez à explorer le log. En revanche, c'est plus difficile de savoir si ça marche. Vous avez des kilomètres de logs. Vous vous demandez si ça marche, il faut y passer plus de temps.
Ça tombe bien. L'exact opposé, c'est que les métriques. On va mesurer des choses au cours du temps et on va pouvoir les afficher. Là, tout de suite, on est sur quelque chose de plus visuel. C'est l'inverse des logs. Ce sera super pour savoir si ça marche. Vous aurez des choses jolies, très agrégées pour avoir une vue générale. Par contre, ce sera plus difficile pourquoi ça ne marche pas. Ça va dépendre. Les logs et ça, c'est très complémentaire. L'alerting, on en parlait un peu. Sur ce genre de métrique, typiquement, l'alerting permet de savoir quand on dépasse un certain seuil quand la courbe augmente ou diminue trop vite. Il y a peu de détails. Et l'intégration aussi. Les logs, c'est assez standard. On peut toujours récupérer un fichier standard. Les métriques, il va alors commencer à mettre les mains dans le cambouis.
Pour les métriques, si vous vous posez la question et parfois vous pouvez commencer, il y a les Golden Metrics. Les métriques qui sont bien pour commencer, c'est de la charge. On a le nombre de requêtes par minute sur le serveur. Il y a les performances pour savoir combien de temps pour répondre et ensuite le nombre d'erreurs. Ça peut-être les logs, ou simplement les 500. Avec ces trois métriques, vous avez déjà une base solide pour commencer. C'est ce qui est proposé de base dans tous les outils. Et ensuite, bien sûr, tout l'intérêt est de pouvoir enrichir ça avec des métriques un peu plus propres à ce que vous faites. Ça va des ratios pour le cache, ou combien de fois on a fait tel algorithme. Ça va donner du sens plus métier. Ça peut être très pratique.
Pour finir, quelque chose d'un peu moins connu et le plus avancé, c'est un bon compromis, c'est très pratique, c'est un peu le rayon X d'une application, si vous connaissez le profiling, comme le fait Blackfire, c'est la capacité de vraiment savoir exactement la fonction qui a été exécutée dans quel ordre. Le tracing, c'est un peu ça, mais en plus léger de manière à pouvoir faire un peu en continu une situation sur les requêtes qui arrivent. Ce que l'on fait sur le tracing, c'est que l'on mesure les points d'entrée et les points de sortie. S'il y a un point d'entrée sur un frontend qui s'appelle MySQL ou d'autres API.
C'est pas mal. Vu qu'on le fait un peu partout, ça permet d'avoir des statistiques, mais globales sur des choses un peu précises aussi. Vous pouvez avoir grosso modo le nombre de requêtes sur le serveur. Vous pouvez avoir aussi combien d'appels ** sont faits sur une route, ou sur des requêtes. On peut creuser les statistiques. Éventuellement, on peut tomber sur une trace. C'est l'histoire d'une requête. C'est savoir ce qu'il s'est passé. Vu que l'on a un identifiant de trace, on peut aussi le mettre dans les logs pour faire la liaison entre les logs et les traces. Le gros inconvénient, c'est qu'il faut carrément mettre les mains dans le code. Ça demande d'instrumenter votre code pour faire la mesure. Ça peut se faire dans certaines unit, mais à un moment donné, il va falloir aller dans votre code pour surveiller les appels http, etc. Les trois derniers moyens que l'on a vus, à savoir le log, les métriques et les traces, c'est ce que l'on appelle dans la télémétrie les trois piliers de l'observabilité. C'est un terme un peu marketing. De même que les Golden Metrics, c'est vraiment un bon pacte de base pour commencer à avoir une solution complète. En général, on vous propose ça sur le marché.
Si vous voulez ce pack de base, si vous voulez commencer par les logs, les métriques puis les traces, vous allez d'abord mettre une instrumentation. Vous allez envoyer ça sur un service. Mais cela va vous faire faire trois instrumentations. En termes d'APM, l'idée est d'avoir un outil pour tous les gouverner et ensuite, dedans, on pourra faire de la corrélation, faciliter les vues sur les trois outils. C'est le package, et la promesse intéressante, c'est que vous n'aurez besoin que de faire une seule intégration. Et vous envoyez tout à votre fournisseur et c'est fini.
L'inconvénient, c'est que vous devez les lier au prestataire. Comment le choisir ? Si vous voulez changer, quoi faire ? Si vous commencez petit ? C'est là que je vais vous parler d'OpenTelemetry. C'est un protocole qui permet de standardiser la communication entre vos applications et les APM ou toute autre application capable de visualiser et d'exploiter ces données.
Dans OpenTelemetry, on peut faire passer des logs, des métriques et des traces. D'un point de vue utilisateur, c'est très intéressant. On va essayer de l'hébergeur local, on va essayer différents APM. On a le choix de ne pas faire de choix.
De l'autre côté, du point de vue des fournisseurs de services APM, c'est très intéressant, on peut adresser une énorme quantité d'écosystèmes et de langage, parce que OpenTelemetry, c'est juste un protocole de communication. Même si vous avez plusieurs stacks techniques, ça peut... Ce n'est pas lié à un langage en particulier.
OpenTelemetry, c'est assez intéressant. Ça date de 2019. L'appellation officielle, c'est une fusion d'OpenTracing et voilà, ils ont fusionné ça en 2019. C'est hébergé sérieusement. Ce sont des gens de chez Google et de tous les acteurs actuels de la télémétrie. Ils travaillent ensemble pour répondre à un vrai besoin. C'est la même fondation qui a poussé K8S*, notamment dans les exemples. Il y a un site Internet où ce qui fait OpenTelemetry est une spécification. Il y a beaucoup de documentation. Ils fournissent des reportings avec un peu de code. On verra ça.
Ça couvre les trois piliers de la télémétrie. Pour autant, tout n'est pas encore complètement figé. Le tracing, c'est ce qu'il y a de plus abouti. C'est historique. C'est instable. Pour les métriques, c'est presque stable partout. SDK, tout n'est pas finalisé. Les logs, c'est sûrement ce dont on a moins besoin tout de suite.
Pour parler du protocole en soi, tout d'abord, le transport. Il y a deux manières de parler, soit sur GRPC, la manière d'utiliser... La manière propulsée par Google, ou le standard http, le classique. Il est peut-être un peu moins rapide parce que ça va moins dans les deux sens, mais il marche très bien. Il n'y a aucun souci là-dessus. Les deux peuvent être utilisés.
Et sur le format, c'est Protobuf, en format binaire qui est utilisé. Json, c'est encore expérimental. C'est une manière d'avoir quelque chose de plus commun que Protobuf. Protobuf, c'est un format où vous écrivez dans un fichier de configuration et vous avez plein de petits programmes qui permettent de convertir ce schéma de données en code PHP, etc.
C'est du binaire et c'est assez portable. C'est plaisant. Quand on va mettre en place tout ça, l'idée est que vos applications, vous pouvez en avoir plusieurs, ça va pousser sur un backend et quelqu'un va collecter les données. Ça peut être vous ou un tiers. Si vous ne voulez pas héberger ça, parce que vous n'avez pas les outils, etc. Ça, c'est la vision simple. Ce n'est pas le scénario est recommandé. Il va y avoir le collecteur qui fait une sorte de proxy entre vos applications et le backend. C'est important. Le monitoring, c'est très important pour vous et ça ne doit surtout pas faire planter vos applications. Ce serait un peu incongru.
L'idée est de mettre un collector au plus près possible de vos applications, comme ça, quand les applications ont des données, elles les envoient et ça a moins de chances d'échouer sur quelque chose de proche. Ensuite, elles continuent. À charge du collector d'essayer d'optimiser. Je vais faire débattre, je vais les envoyer au backend, j'analyse, je renvoie, toutes ces stratégies, vous ne voulez pas que ce soit l'application qui le fasse. C'est le but du collector. Il est là pour avoir toute cette logique. Il est même développé pour être très extensible. Il y a trois composants et trois notions dans le collector. Receiver, Processor et Exporter. Bien sûr, on parle du protocole OpenTelemetry OTLP, mais vous pouvez aussi implémenter votre propre Receiver. Ce n'est pas l'idée de faire le vôtre, mais c'est intéressant pour certains tiers qui ont leur propre format. Ou si vous utilisez d'anciens formats comme Jaeger ou Prométhéus, vous mettez l'Exporter ou le Receiver qui va bien et ça peut faciliter la migration. Le collector peut avoir ce rôle.
Je vais m'attarder un peu sur le tracing, comme nous le voyons, c'est ce qu'il y a de mieux dans OpenTelemetry. C'est parfois ce que l'on connaît un peu moins. Ça demande un peu plus d'investissement.
Pour balayer un petit peu quelques concepts, vous avez une trace. C'est votre enregistrement de ce qui s'est passé dans la requête. Cette trace est composée de spans qui sont des mesures, il s'est passé des choses entre là et là. Bien sûr, il faut leur donner un nom. Il y a des exemples qui sont donnés dans la documentation. Il y a des bonnes pratiques.
Typiquement, si vous avez un span qui correspond à votre requête http, get, c'est trop générique. Ensuite, le deuxième est trop spécifique. Les deux derniers sont bien. Tous ces spans seront liées dans une relation parents-enfants. On peut avoir 0 ou 1 parent et autant d'enfants que l'on veut. Il n'y a aucune condition pour que les enfants soient inclus dans les parents en termes de temps. Il y a la possibilité d'avoir des processus asynchrones. Il est tout à fait possible aussi de générer des spans d'une même trace sur différents serveurs, par exemple, mon API appelle une autre API. Si j'arrive à transmettre les identifiants de la trace, le parent, une autre API peut générer de nouveaux spans dans la même trace.
Une autre propriété intéressante sur les spans c'est le type. Vous envoyez une requête http à l'extérieur, idéalement, si c'est vous qui maintenez l'autre serveur http, vous faites un span de type serveur pour dire ce que vous voulez. Vous analysez la différence entre ce qui est perçu par le client et ce qui est constaté par le serveur. Très intéressant. Cela permet de mesurer tout le temps qui est perdu dans le "réseau". J'utilise ce terme pour dire tout ce que je ne comprends pas entre une application et une autre. Ça peut être des menteurs en réseau, ça fait plein d'autres choses.
Ça, c'était toutes les propriétés fixes sur les spans, il n'y en a pas beaucoup. Et ensuite, toute la flexibilité avec les attributs. Toutes les valeurs qui sont associées à chaque span. On peut y mettre tout et n'importe quoi. Dans la documentation, il y a des spécifications. Si vous faites http, il va y avoir des attributs. C'est normalisé. C'est pour que ce soit repérable entre les différentes API que vous pouvez utiliser. Il y en a pour http, les bases de données, etc.
Typiquement, on voit que ça pourrait être intéressant d'anonymiser certaines choses. Le collector va faire ça aussi. Entre le receiver et l'exporter, il y a le transcriver*.
Maintenant que l'on a fait un peu le tracing, on va voir ce qui existe actuellement. Pas grand-chose. C'est pour ça que je suis là. Pour motiver et donner la bonne énergie. Tout d'abord, il y a une démo qui est fournie par Github. Ils ont codé toute une forêt d'applications qui interagissent entre elles. Tout est packagé. Il y a plusieurs langages. Vous récupérez les sources. Vous avez une page Web pour visiter un petit site d'avis sur des restaurants totalement imaginaires. Il y a aussi quelque chose qui génère du trafic en arrière-plan pour avoir des données et des erreurs. Il y a un Jaeger qui est inclus. Il permet de visualiser les traces. Cela vous permet de vous rendre compte sur une application complètement inventée de ce que vous pouvez avoir.
Tout est inclus. Maintenant, si vous voulez commencer à faire vos tests, le premier point d'entrée est qu'il faut un collector. Le collector permet de dumper tout ce qu'il reçoit. Vous n'avez même pas besoin d'avoir un APM derrière. Vous faites un test. Vous avez un collecteur. Est-ce que vous arrivez à envoyer à ce collecteur ? Pour ça, il y a un repository. Ici, OpenTelemetry collector contrib. À chaque fois qu'il y a du code source qui est fourni par OpenTelemetry, il y a un le projet core et -contrib qui permet à certaines tierces parties de venir faire des contributions propres à leur utilité. Si vous voulez commencer, l'idéal est de prendre la version -contrib où seront incluses pour l'un intégration. Cela permet de tester plein de choses. Et si vous voulez vraiment affiner, vous prenez OpenTelemetry collector. Je ne vais pas détailler l'utilisation. Vous dites ce que vous avez et ça fait le job.
Le Jaeger, c'est bien. Je ne suis pas un expert en docker. Ça ouvre deux ports. Ça vous permet rapidement de visualiser les données que vous avez exportées. C'est plutôt sympa à avoir sous la main. Ensuite, vous pouvez l'héberger. C'est un autre débat. Oui, ça coûte d'héberger quelque chose plutôt que de payer un service là-dessus.
Sur PHP, il y a plusieurs choses. Il y a l'API d'OpenTelemetry. C'est l'interface de l'interaction avec le protocole. Ensuite, ils fournissent le SDK pour une dizaine de langages. Ensuite, il y a des intégrations qui permettent de créer les spans et de mettre des attributs. On va voir quand php, le SDK est là. Sur d'autres langages, il y a énormément d'intégration. On a un peu de retard sur l'écosystème PHP. Il y a un paquet composé qui existe. Ce n'est pas encore complètement fonctionnel. Ça ne fait que le tracing pour l'instant il n'y a pas encore les métrites et certainement pas les logs. Pour faire du Protobuf, il vaut mieux utiliser une extension. Ils fournissent une solution en PHP, mais c'est beaucoup plus lent.
Pour communiquer, c'est soit du http soit du GRPC. Pour le GRPC, le meilleur moyen reste une extension. Le client, il suffit de fournir des interfaces PSR 17 pour pouvoir se connecter.
Un petit exemple, très minimaliste. On ne va pas forcément rentrer dans tous les détails. Je veux créer un tracer provider avec mes factories http, etc. derrière, je vais créer un tracer, je vais créer mon root span. Ça, vous le mettez au tout début de votre code, le plus tôt possible et vous aurez une trace qui contiendra un span qui sera fait sur votre application.
Il est à noter que toute la configuration, ça se fait par des variables d'environnement. C'est normalisé sur l'ensemble de l'utilisation. Ça fait partie de la documentation API. C'est pratique. Quand on a fait ça, on n'a pas fait grand-chose non plus. Il va manquer les attributs, il faut propager ça aux appels http que je fais. Il y a un header spécial à mettre pour dire qu'on était dans tel span ou etc., il y a le sampling aussi. On ne veut pas faire une trace pour chaque requête entrante. Ça a un petit coût. Idéalement, on en fait 1/10, etc. Il y a pas mal de choses à faire.
Dans le meilleur des mondes, on aimerait que ce soit automatique. Les intégrations arrivent là. Ça se trouvera dans opentelemetry-php-contrib il n'y a pas grand-chose, mais il y a déjà l'intégration pour AWS, pour Symfony, pour OtelSDK, pour créer des services et depuis pas longtemps, il y a aussi un OtelBundle petit instrument et le kernel Symfony. C'est basique, mais pour chaque requête entrante, ça va remplir ça. Ça donne le naming qui va bien. Le SDK a déjà fait des choses : ça tourne sur tel OS et l'architecture. Les informations génériques. Ce bundle peut enrichir avec des informations plus liées à la requête.
Le reste, c'est écrire. Effectivement, le gros avantage, c'est qu'on l'écrit une fois et qu'ensuite, vous pourrez l'envoyer chez plein d'APM. Pour l'avoir testé sur d'autres langages tout automatiques, c'est plaisant. C'est assez bluffant. Vous faites votre instrumentation, que ce soit dans les logs du collector ou dans un de Jaeger en local, s'est supporté. Les différents acteurs supportent déjà OpenTelemetry et c'est utilisé beaucoup dans d'autres communautés et d'autres langages. L'avantage, c'est qu'il n'y a plus OpenTelemetry et tout est prêt.
Est-ce que OpenTelemetry peut être un standard ? Personnellement, je pense que oui. Il y a tout pour ça. C'est assez générique, ce n'est pas fait dans son coin. C'est fait en consultation avec les acteurs du marché. C'est même déjà implémenté. Pour ça, oui, pas de souci. Là où il faut se poser la question, c'est en termes d'instrumentation. Il y a peut-être un changement de paradigme. Avant, vous payiez en APM et à partir de là, vous aviez un peu le package tout-en-un. Vous aviez l'intégration et l'outil pour exploiter. Ça, c'est bien parce que si ça ne marche pas, on peut taper sur les doigts en disant qu'on paye qu'on veut que ça marche. En revanche, dès que vous avez une nouvelle librairie qui n'est pas supportée, vous ne pouvez pas le faire vous-même. Le fameux débat open source propriétaire. Avec OpenTelemetry, ça renverse un peu le problème. Il y a une séparation entre moi qui suis capable d'analyser les données et de faire des super graphs et de l'autre côté, il faut instrumenter et collecter les données. Il faudra voir... Il y a certains acteurs qui se démarquent en disant qu'ils font limite de la data analyse. Ils analysent les datas. Dès qu'on les collecte, on les renvoie au format OpenTelemetry. Ensuite, il y aura peut-être de l'autre côté du tuyau quelqu'un qui vous fournira une instrumentation précise de vos applications. On génère OpenTelemetry est libre à vous de les utiliser comme vous le voulez. C'est à voir. Et bien sûr, PHP, il n'y a pas encore grand-chose. Il va falloir voir si la communauté suit derrière. On en a pour Symfony, mais ça ne couvre pas tous les usages. Il faudra voir.
Une fois que ce sera fait, normalement, c'est du standard. Si le standard n'est pas remplacé par un autre standard, ça devrait être fait une fois pour toutes. C'est gratuit, je ne l'ai pas dit. On m'a posé la question. C'est gratuit, OpenTelemetry. Si vous avez d'autres questions sur OpenTelemetry ou sur le monitoring en général, n'hésitez pas que ce soit maintenant ou après. Je me ferai un plaisir d'y répondre. Merci à tous.
_ On a le temps pour une question. Qui sera l'heureux vainqueur ? Une bonne question. Pas de pression.
_ Est-ce que le standard Telemetry spécifie l'utilisation du header à utiliser pour la propagation des traces ? Comme par exemple W3* ?
_ Oui. On peut envoyer un contexte entre deux services. Typiquement, on peut l'utiliser pour dire "traceID et spanID", c'est tout ce dont on a besoin minimal pour pouvoir transmettre les informations. Il y a aussi une autre spécification qui permet d'embarquer plus de données. C'est en cours, si je me rappelle bien. Et il y a un autre standard dont je n'ai plus le nom en tête, un autre header qui peut être utilisé. Ça s'appuie sur d'autres standards. Donc oui. C'était une très bonne question.
_ Merci.
Tweets