Développement axé sur l’observabilité avec OpenTelemetry | Opensource.com

Le développement piloté par l’observabilité (ODD) est reconnu comme “nécessaire” pour les architectures complexes basées sur des microservices. Charity Majors a inventé le terme et a écrit à ce sujet dans plusieurs articles, notamment Observabilité : un manifeste. Elle explique le terme dans cette citation :

Intégrez-vous l’observabilité directement dans votre code au fur et à mesure que vous l’écrivez ? Les meilleurs ingénieurs font une forme de “développement axé sur l’observabilité” – ils comprennent leur logiciel au fur et à mesure qu’ils l’écrivent, incluent l’instrumentation lorsqu’ils l’expédient, puis le vérifient régulièrement pour s’assurer qu’il ressemble à ce qu’il attend. Vous ne pouvez pas simplement ajouter cela après coup, “quand c’est fait”.

OpenTelemetry fournit la plomberie

Le projet OpenTelemetry bénéficie du soutien de l’industrie pour être la “plomberie” permettant l’observabilité entre les applications distribuées. Le projet OpenTelemetry est juste derrière Kubernetes en mesurant la taille de sa communauté de contributeurs parmi Fondation Cloud Native Computing (CNCF) projets, et a été formé lorsque les projets OpenTracing et OpenCensus ont fusionné en 2019. Depuis lors, presque tous les principaux acteurs de l’industrie ont annoncé leur soutien à OpenTelemetry.

OpenTelemetry couvre trois signaux d’observabilité : les journaux, les métriques et les traces distribuées. Il normalise l’approche de l’instrumentation de votre code, de la collecte des données et de son exportation vers un système principal où les analyses peuvent avoir lieu et les informations peuvent être stockées. En normalisant la « plomberie » pour collecter ces métriques, vous pouvez désormais être assuré que vous n’avez pas à modifier l’instrumentation intégrée dans votre code lorsque vous passez d’un fournisseur à un autre, ou que vous décidez d’effectuer l’analyse et le stockage en interne avec une solution open source comme OpenSearch. Les fournisseurs prennent entièrement en charge OpenTelemetry car il supprime la lourde tâche d’activer l’instrumentation dans chaque langage de programmation, chaque outil, chaque base de données, chaque bus de messages et dans chaque version de ces langages. Une approche open source avec OpenTelemetry profite à tous !

Combler le fossé avec Tracetest

Donc, vous voulez faire ODD, et vous avez une norme sur la façon d’instrumenter le code avec OpenTelemetry. Maintenant, vous avez juste besoin d’un outil pour combler le fossé et vous aider à développer et tester votre application distribuée avec OpenTelemetry. C’est pourquoi mon équipe construit Tracetest, un outil open source pour permettre le développement et le test de votre application de microservice distribuée. Il est indépendant du langage de développement utilisé ou de la source de données backend OpenTelemetry choisie.

Pendant des années, les développeurs ont utilisé des outils tels que Postman, ReadyAPI ou Insomnia pour déclencher leur code, afficher la réponse et créer des tests par rapport à la réponse. Tracetest étend cet ancien concept pour prendre en charge les besoins de développement modernes et axés sur l’observabilité des équipes. Les traces sont à l’avant et au centre de l’outil. Tracetest vous permet de déclencher l’exécution de votre code, d’afficher à la fois la réponse de ce code et la trace OpenTelemetry, et de créer des tests basés à la fois sur la réponse et les données contenues dans la trace.

Tracetest : Déclencher, tracer et tester

Comment fonctionne Tracetest ? Tout d’abord, vous définissez une transaction de déclenchement. Cela peut être un LE REPOS ou appel gRPC. L’outil exécute ce déclencheur et montre au développeur la réponse complète renvoyée. Cela permet un processus interactif de modification du code sous-jacent et d’exécution du déclencheur pour vérifier la réponse. Deuxièmement, Tracetest s’intègre à votre infrastructure OpenTelemetry existante pour extraire la trace générée par l’exécution du déclencheur et vous montre tous les détails de la trace. Les étendues, les attributs et la synchronisation sont tous visibles. Le développeur peut ajuster son code et ajouter une instrumentation manuelle, réexécuter le déclencheur et voir les résultats de ses modifications sur la trace directement dans l’outil. Enfin, Tracetest vous permet de créer des tests basés à la fois sur la réponse de la transaction et sur les données de trace dans une technique connue sous le nom de test basé sur la trace.

[ Related read: What you need to know about automation testing in CI/CD ]

Qu’est-ce qu’un test basé sur la trace ?

Les tests basés sur les traces sont une nouvelle approche d’un vieux problème. Comment permettez-vous aux tests d’intégration d’être écrits sur des systèmes complexes ? En règle générale, l’ancienne approche impliquait d’ajouter beaucoup de complexité à votre test afin qu’il ait une visibilité sur ce qui se passait dans le système. Le test nécessiterait un déclencheur, mais il nécessiterait également un travail supplémentaire pour accéder aux informations contenues dans tout le système. Il faudrait une connexion à la base de données et des informations d’authentification, la capacité de surveiller le bus de messages et même une instrumentation supplémentaire ajoutée au code pour activer le test. En revanche, les tests basés sur Trace suppriment toute la complexité. Il peut le faire à cause d’un simple fait : vous avez déjà entièrement instrumenté votre code avec OpenTelemetry. En exploitant les données contenues dans les traces produites par l’application testée, Tracetest peut faire des assertions à la fois sur les données de réponse et sur les données de trace. Voici des exemples de questions pouvant être posées :

• La réponse à l’appel gRPC comportait-elle un code d’état 0 et le message de réponse était-il correct ?

• Les deux microservices en aval ont-ils retiré le message de la file d’attente des messages ?

• Lors de l’appel d’un système externe dans le cadre du processus, renvoie-t-il un code d’état de 200 ?

• Toutes mes requêtes de base de données se sont-elles exécutées en moins de 250 ms ?

En combinant la possibilité d’exercer votre code, d’afficher la réponse et la trace renvoyées, puis de créer des tests basés sur les deux ensembles de données, Tracetest fournit un outil pour vous permettre de faire du développement axé sur l’observabilité avec OpenTelemetry.

Essayez Tracetest

Si vous êtes prêt à commencer, télécharger Tracetest et essayez-le. C’est open source, donc vous pouvez contribuer au code et aidez à façonner l’avenir des tests basés sur la trace avec Tracetest !