Comment observer vos pipelines CI/CD avec OpenTelemetry

Les logiciels d'aujourd'hui sont beaucoup plus complexes que ceux d'il y a plus de 20 ans. Cette complexité accrue présente de nouveaux défis pour le dépannage de notre code. Heureusement, la mise en œuvre de l'observabilité dans nos systèmes nous a permis d'aller assez loin dans la compréhension des performances de nos applications et la localisation des problèmes qui se produisent.

Cependant, les logiciels ne sont pas les seuls à avoir évolué. En effet, le processus de création et de développement a également changé. Les DevOps ont introduit le concept de CI/CD. Avec le raccourcissement des cycles de livraison qui sont passés de trimestriels à mensuels, puis à hebdomadaires, voire à plusieurs fois par jour, nous adoptons à bras ouverts l'automatisation sur l'ensemble du pipeline de livraison de logiciels. 

Malheureusement, l'observabilité des pipelines CI/CD n'a pas beaucoup progressé par rapport aux logiciels d'application. Si l'on considère que ces pipelines sont l'épine dorsale du processus de livraison de logiciels, c'est surprenant : si vous n'avez pas de visibilité, comment pouvez-vous résoudre les problèmes lorsque quelque chose ne va pas et que vous ne pouvez pas mettre le logiciel en production ? 

C'est ce sur quoi nous allons nous pencher dans ce billet de blog : l'observabilité des pipelines CI/CD. Nous allons tout d'abord définir quelques éléments, puis nous verrons ensuite pourquoi il est important de pouvoir observer les pipelines et de savoir comment les rendre observables, et enfin, nous terminerons par les défis qui restent encore à relever. 

Concepts clés

Voici quelques définitions à connaître :

Observabilité

Il existe de nombreuses définitions de l'observabilité, nous allons donc nous limiter à celle que nous préférons : 

L'observabilité permet de comprendre un système de l'extérieur et de poser des questions sans en connaître les mécanismes internes.

Ainsi, même si vous ne comprenez pas le menu détail de la logique métier sous-jacente d'un système, celui-ci produit suffisamment d'informations pour que vous puissiez suivre le fil d'Ariane et répondre à la question suivante : « Pourquoi est-ce que cela se produit ? » Toutefois, l'observabilité est impossible sans informations provenant du système. Comment obtenir ces informations ? Avec OpenTelemetry, par exemple.

OpenTelemetry

OpenTelemetry (ou OTel), est un framework d'observabilité open source qui permet de générer, collecter, transformer et exporter les données télémétriques. La solution fournit un ensemble d'API, de kits de développement de logiciels (SDK), de bibliothèques d'instrumentation et d'outils pour vous aider à accomplir cette tâche. Depuis sa création officielle en 2019, OpenTelemetry est devenu la norme de fait de l'instrumentation des applications ainsi que de la génération et de la collecte de données télémétriques. Des entreprises telles qu'eBay et Skyscanner l'utilisent. 

L'un de ses principaux avantages est l'absence de dépendance à l'égard d'un fournisseur. Vous pouvez instrumenter votre application une seule fois et envoyer votre télémétrie à l'application qui vous convient le mieux. Cette solution fournit également des outils très intéressants, tels que le collecteur.

Le collecteur est un service neutre utilisé pour ingérer, transformer et exporter des données vers un ou plusieurs backends d'observabilité. Il est constitué de quatre composants principaux qui accèdent à la télémétrie :

• Les récepteurs ingèrent les données, qu'elles proviennent du code de votre application ou de votre infrastructure.
• Les processeurs transforment vos données. Un processeur peut par exemple obfusquer vos données, ajouter des attributs, en supprimer ou filtrer les données.
• Les exportateurs convertissent vos données en un format compatible avec le backend d'observabilité que vous avez choisi.
• Les connecteurs permettent de relier deux pipelines.

Vous pouvez considérer le collecteur OTel comme un pipeline de données.

Pipelines CI/CD

Le CI/CD est une approche automatisée de la livraison de logiciels qui s'appuie sur deux pratiques clés : 

• L'intégration continue (ou CI, de l'anglais « Continuous Integration »), qui comprend le développement, le packaging et le test de votre logiciel dès qu'une modification est apportée au code.
• La livraison continue (CD, de l'anglais « Continuous Delivery »), qui consiste à prendre ce package logiciel et à le déployer immédiatement en production.

Les pipelines automatisés assurent des itérations de produits rapides en vous permettant d'offrir plus rapidement à vos clients les nouvelles fonctionnalités, les correctifs et les mises à jour générales. Cela supprime le risque d'erreurs manuelles et normalise la boucle de rétroaction (feedback) auprès de vos développeurs. 

Pourquoi l'observabilité du pipeline CI/CD est-elle importante ?

Lorsque votre pipeline est en bonne santé, votre équipe peut continuellement programmer, développer, tester et déployer du code et des changements de configuration en production. Vous pouvez également améliorer ou atteindre l'agilité de développement, ce qui signifie que vous pouvez modifier vos opérations et minimiser le temps nécessaire pour déterminer si ces modifications ont eu un impact positif ou négatif sur la santé de votre application. 

À l'inverse, lorsque votre pipeline n'est pas en bonne santé, vous pouvez rencontrer un ou plusieurs des problèmes suivants :

• Lenteur du déploiement : les correctifs risquent de ne pas être publiés assez rapidement pour réduire l'insatisfaction des utilisateurs, et les problèmes peuvent devenir critiques. 
• Problèmes liés aux tests : le fait de devoir attendre que les tests soient terminés, ou de ne pas avoir assez de temps pour les tester contre différentes configurations, peut retarder le déploiement et rendre difficile l'obtention de performances suffisantes pour les applications de votre base d'utilisateurs.
• Dette technique : la difficulté à déterminer les problèmes sous-jacents peut être à l'origine de la dette technique.

Pipelines : les systèmes de production des ingénieurs DevOps

Bien que les pipelines ne constituent pas un environnement de production avec lequel les utilisateurs externes interagissent, ils constituent très certainement un environnement de production avec lequel les utilisateurs internes — les ingénieurs logiciels et les ingénieurs fiabilité des sites (SRE), par exemple — interagissent. Le fait de pouvoir observer votre environnement de production vous permet de :

• Éviter les temps de cycle inutilement longs, ou les délais d'exécution des modifications, qui ont une incidence sur le temps nécessaire à la mise en production d'un engagement.
• Réduire les retards dans l'introduction de nouvelles fonctionnalités et de correctifs.
• Réduire les temps d'attente pour les utilisateurs.

Quand le code échoue…

Les pipelines CI/CD sont gérés par du code qui définit leur fonctionnement, mais, malgré tous vos efforts, il arrive que ce code échoue. Le fait de rendre le code de l'application observable vous aide à comprendre ce qui se passe lorsque vous rencontrez des problèmes de production. De même, la visibilité sur vos pipelines peut vous aider à comprendre les raisons des échecs.

Un dépannage plus simple

Les pipelines observables permettent de répondre à des questions telles que :

• Qu'est-ce qui a échoué ?
• Pourquoi ?
• Est-ce déjà arrivé auparavant ?
• Qu'est-ce qui a échoué le plus fréquemment ?
• Quel est le runtime normal du pipeline ?
• Y a-t-il des goulots d'étranglement ? Si oui, lesquels ?
• Est-il possible de réduire le délai de résolution des problèmes liés aux pipelines ?

Quel type de données souhaitez-vous collecter ?

Pour répondre à ces questions, vous devez recueillir des informations sur vos pipelines. Mais de quelles informations avez-vous besoin ? Vous devez capturer des éléments tels que :

• Le nom de la branche
• L'algorithme de hachage sécurisé de l'engagement (SHA)
• L'adresse IP de l'appareil
• Le type d'exécution (planifiée, déclenchée par fusion/publication)
• L'étape qui a échoué
• La durée de cette étape
• Le numéro de version

Méthode d'observation des pipelines

Un système est observable lorsqu'il émet suffisamment d'informations pour répondre à la question « Pourquoi est-ce que cela se produit ? ». Un dispositif d'émission de ces informations doit tout d'abord être mis en place ; ensuite, il faut un endroit où les envoyer ; et enfin, il faut les analyser et déterminer ce qu'il faut corriger. 

C'est là qu'intervient OpenTelemetry. Vous pouvez mettre en œuvre OpenTelemetry (OTel) dans vos systèmes pour que les informations dont vous avez besoin soient émises afin d'établir l'observabilité de vos systèmes. Et de même que vous l'utilisez pour les applications, vous pouvez également l'utiliser pour les pipelines CI/CD. Mais vous devez toujours envoyer la télémétrie générée à une solution en backend, comme New Relic, pour l'analyser. 

Utilisation d'OpenTelemetry

OpenTelemetry est très utile pour les pipelines CI/CD instrumentés, car de nombreuses personnes l'utilisent déjà pour instrumenter leurs applications. Les taux d'adoption et d'implémentation sont en constante augmentation depuis deux ans. 

Utilisation de New Relic

Vous disposez des options suivantes pour le monitoring des pipelines CI/CD avec New Relic :

Le transfert des logs CircleCI à New Relic

Vous pouvez configurer le service webhook CircleCI pour envoyer les logs CI/CD à New Relic. 

GitHub Actions Exporter

Vous pouvez utiliser cet exportateur pour surveiller vos actions GitHub, ce qui facilite l'observabilité de la santé et des performances de votre workflow CI/CD. Il extrait les logs de vos étapes GitHub Action, puis ajoute des identifiants de trace et de span pour les corréler avec les traces.

Avec l'exportateur, vous pouvez :

• Visualiser les principales métriques de GitHub Actions, telles que la durée de vos workflows/tâches/étapes et la fréquence de leurs échecs.
• Visualisez les workflows, tâches et étapes en tant que traces distribuées avec les logs en contexte, rapportées à une entité de service OpenTelemetry avec New Relic.
• Identifiez l'origine des problèmes dans vos workflows.
• Créez des alertes sur vos workflows.

Veuillez noter que cet outil a été développé par notre équipe de terrain et qu'il est hébergé dans notre référentiel (ou repository) expérimental. Cela signifie que le code n'est pas nécessairement utilisé en production, mais qu'il est développé en open source, mais aussi que vos contributions sont les bienvenues.

Suivi des changements avec New Relic

New Relic propose également une fonctionnalité de suivi des changements qui vous permet de monitorer l'effet qu'ont les changements sur vos clients et systèmes. Vous désignez les changements qu'il faut monitorer, puis vérifiez les résultats dans votre compte New Relic. Cela vous permet ainsi de faire le suivi de toutes les modifications que vous apportez à votre environnement sur le pipeline de mise en production. 

Vous pouvez utiliser cette fonctionnalité avec les GitHub Actions — un exemple se trouve ici — et en utilisant Jenkins — le didacticiel est ici — puis apprendre comment visualiser et analyser vos changements dans l'interface. 

Quelles sont les autres options ?

Pour l'instant, les choix sont assez disparates. Ils comprennent :

• Des solutions de monitoring SaaS commerciales
• Des outils créés par les fournisseurs que vous pouvez intégrer dans les outils CI/CD existants pour faciliter l'observabilité CI/CD (par exemple, Honeycomb buildevents). 
• Des actions GitHub développées en interne (voir les exemples ici, ici et ici) pour permettre l'observabilité sur les pipelines CI/CD.
• Un webhook CircleCI pour OTel développé en interne.
• Un webhook Drone CI pour OTel développé en interne.
• L'intégration native d'OpenTelemetry dans Jenkins et Tekton. 

Vous pouvez également intégrer ces outils dans vos pipelines CI/CD ; ils émettent des signaux OpenTelemetry et contribuent ainsi à rendre vos pipelines observables :

• L'extension Maven OpenTelemetry émet des traces distribuées des déploiements Java.
• Le rappel Ansible OpenTelemetry trace les playbooks Ansible.
• L'extension JUnit Jupiter OpenTelemetry de Dynatrace est un plug-in Gradle pour la collecte des données d'exécution des tests JUnit via OpenTelemetry. Il existe également une version Maven.
• pytest-otel enregistre les traces distribuées des tests Python exécutés.
• otel-cli est un outil d'interface de ligne de commande (CLI) écrit en Go qui permet aux scripts shell d'émettre des traces.
• Le récepteur Filelog (collecteur OTel) suit et analyse les logs à partir des fichiers.
• Le récepteur de fournisseur Git (collecteur OTel) fait le scraping des données des fournisseurs Git.

Exemple de pipeline observable

Ce diagramme montre comment obtenir l'observabilité du pipeline à l'aide de certains des outils mentionnés ci-dessus. Supposons que vous développiez et déployiez une application Java. Vous utilisez Jenkins pour orchestrer le développement et le déploiement :

1. Le pipeline CI/CD Jenkins peut émettre des signaux de télémétrie via le plug-in Jenkins OTel.
2. Au stade du développement :
   1. Vous pouvez utiliser l'extension Maven OpenTelemetry pour émettre des traces distribuées de développements Java.
   2. Si votre version inclut des scripts shell, vous pouvez utiliser l'outil otel-cli pour permettre à vos scripts shell d'émettre des traces.
3. Dans la phase de test, le plug-in JUnit Jupiter pour Maven vous permet de collecter des données sur les exécutions de tests JUnit via OpenTelemetry.
4. Lors de l'étape de packaging, en utilisant Artifactory pour le packaging de votre application, vous pouvez envoyer ses logs au collecteur OTel via le récepteur Filelog, qui suit et analyse les logs à partir des fichiers.
5. Dans l'étape de déploiement utilisant Ansible pour orchestrer vos déploiements, le rappel Ansible OpenTelemetry ajoute des traces à vos playbooks Ansible. Si ce dernier utilise également des scripts shell, il peut tirer parti de l'outil otel-cli permettre à vos scripts shell d'émettre des données de traces supplémentaires.
6. Les signaux émis par les différents plug-ins sont ingérés par un collecteur OTel. Les données peuvent être ingérées en utilisant le récepteur OTLP standard pour ingérer les données télémétriques, ainsi que le récepteur Git Provider et le récepteur Filelog. Les signaux de télémétrie sont ensuite envoyés par le collecteur à un backend d'observabilité.
7. Une fois que vos données sont arrivées jusqu'au backend d'observabilité, vous pouvez visualiser et interroger vos données, paramétrer les alertes et plus encore. 

Difficultés d'obtention de pipelines observables

Bien qu'il soit logique d'utiliser OpenTelemetry pour permettre l'observabilité du pipeline CI/CD, il y a un manque de standardisation et le paysage des outils est désorganisé.

OpenTelemetry n'est pas intégré à la plupart des outils CI/CD. Et bien qu'il y ait aussi un désir d'ajouter des capacités d'observabilité aux outils CI/CD tels que GitLab et GitHub Actions, ces initiatives avancent lentement. Par exemple, bien qu'il y ait eu de l'activité sur la demande GitLab pour l'observabilité des pipelines avec OTel, cette demande est toujours ouverte après deux ans. La proposition d'OTel pour l'observabilité des pipelines CI/CD a été introduite en janvier 2023, mais (après vérification en novembre 2023), il n'y a eu aucune activité depuis juillet 2023.

Par conséquent, vous êtes à la merci des individus et des organisations qui créent leurs propres outils si vous voulez les utiliser. Que se passe-t-il s'ils décident de ne plus assurer la maintenance de ces outils ?

En savoir plus

En rendant vos pipelines CI/CD observables, vous pouvez les dépanner plus efficacement, gagner en agilité de développement et obtenir des informations précieuses sur leurs mécanismes internes que vous pouvez alors ajuster pour les rendre plus efficaces.

Un pipeline en bonne santé signifie que vous pouvez programmer, développer, tester et déployer du nouveau code en continu. À l'inverse, un pipeline en mauvaise santé peut entraîner des déploiements plus lents, des problèmes de test et une dette technique. 

Vous pouvez utiliser OpenTelemetry pour ajouter l'observabilité dans votre pipeline. Bien que les options soient limitées à l'heure actuelle, les choses évoluent dans le bon sens et nous sommes impatients de voir ce que l'avenir du CI/CD nous réserve.

Pour en savoir plus :

• L'utilisation d'OpenTelemetry pour améliorer Ansible avec Jaeger Tracing
• Consultez le canal cicd-o11y sur CNCF Slack

Vous pouvez également essayer :

• Le quickstart CircleCI de New Relic
• La transmission de vos logs CircleCI à New Relic

Une version de ce billet a été publiée initialement sur le site The New stack.