Les temps d'arrêt, qu'ils soient causés par des dysfonctionnements ou des problèmes de performance des applications, peuvent avoir des conséquences financières désastreuses pour les entreprises. En effet, l'enquête « Global Server Hardware and Server OS Reliability » publiée en 2022 par Information Technology Intelligence Consulting, révèle qu’un temps d'arrêt d’une heure coûterait aux entreprises 301 000 dollars ou plus. Bien souvent, ces problèmes proviennent d'erreurs humaines qui se produisent lors de modifications liées au code ou à la configuration logicielle.
La résolution de ces incidents exige une collaboration étroite entre les équipes chargées du développement et des opérations. Ces dernières doivent analyser les différents composants du système pour identifier la cause profonde du changement rencontré et rétablir rapidement le système pour qu’il fonctionne à nouveau normalement.
Cependant, il n'est pas rare que ces équipes utilisent des outils différents pour concevoir, gérer et surveiller leurs services applicatifs et leur infrastructure. Cela n'est pas sans conséquences, car cette approche entraîne un cloisonnement des données, des changements de contexte inefficaces et une mauvaise communication entre les équipes. Tout ceci allonge ainsi le temps nécessaire à la détection et à la résolution des incidents.
Découvrez dans cet article tout ce que vous devez savoir sur le traçage distribué, sans oublier notre fonctionnalité de « Distributed Tracing » (disponible en version bêta), une nouvelle étape vers une offre complète d’observabilité, intégrée de manière transparente à la plateforme DevSecOps de GitLab.
Une nouvelle ère avec GitLab Observability
GitLab Observability permet aux équipes chargées du développement et des opérations de visualiser et d'analyser les erreurs, les traces, les journaux, ainsi que les indicateurs de performance de leurs applications et de leur infrastructure.
En intégrant la surveillance des performances des applications directement dans les workflows de livraison de logiciels, nous réduisons les interruptions liées aux changements de contexte, augmentant ainsi la productivité des équipes qui peuvent alors collaborer efficacement au sein d'une plateforme unifiée.
De plus, GitLab Observability comble le fossé entre le développement et les opérations en fournissant des informations précieuses sur les performances des applications en phase de production. Cela favorise la transparence, le partage d'informations et une meilleure communication entre les équipes. Elles peuvent alors détecter et résoudre plus rapidement et efficacement les bogues et problèmes de performance liés aux changements de code ou de configuration. Ainsi, cela évite que ces problèmes ne se transforment en incidents majeurs susceptibles de nuire aux activités de l'entreprise.
Qu'est-ce que le traçage distribué ?
Avec le traçage distribué, les ingénieurs peuvent identifier l'origine des problèmes liés à la performance des applications. Une trace correspond à une requête d’un utilisateur unique qui chemine à travers différents services et systèmes. Cela permet aux ingénieurs d'analyser la chronologie de chaque opération et de détecter les erreurs éventuelles au fur et à mesure qu’elles se produisent.
Chaque trace est composée d'un ou de plusieurs spans (qui sont des opérations individuelles ou des unités de travail spécifiques). Ces spans contiennent un large éventail de métadonnées telles que le nom, les horodatages, le statut, ainsi que des tags ou des journaux pertinents. En examinant les relations entre les spans, les équipes de développement peuvent comprendre le parcours des requêtes, identifier les goulots d'étranglement en termes de performance, et localiser précisément les problèmes.
Le traçage distribué dans les microservices
Le traçage distribué est particulièrement utile pour l'architecture de microservices. Dans ce type d'architecture, une seule requête peut impliquer de nombreux appels de services à travers un système complexe. Grâce au traçage distribué, les équipes obtiennent un maximum de visibilité sur cette interaction et peuvent rapidement diagnostiquer et résoudre les problèmes.
Par exemple, cette trace illustre la manière dont une requête utilisateur passe par différents services pour obtenir des recommandations de produits sur un site e-commerce :
- Action de l’utilisateur. Cela correspond à l'action initiale de l'utilisateur. Par exemple, un clic sur un bouton pour demander des recommandations de produits sur une page produit.
- Frontend. Le frontend envoie une requête au service de recommandation pour obtenir une liste de produits recommandés.
- Service de recommandation. La requête provenant du frontend est traitée par le service de recommandation, qui génère une liste de produits recommandés.
- Service de catalogue. Le service de recommandation appelle le service de catalogue pour récupérer les détails des produits recommandés. Une icône d'alerte signale un problème ou un ralentissement à cette étape (par exemple, une réponse lente ou une erreur lors de la récupération des détails des produits).
- Base de données. Le service de catalogue interroge la base de données pour récupérer les informations détaillées des produits. Ce span montre la requête SQL effectuée dans la base de données.
En visualisant cette trace de bout en bout, les équipes de développement peuvent identifier les problèmes de performance (comme ici, une erreur au niveau du service de catalogue) et diagnostiquer puis résoudre rapidement les problèmes à travers l'ensemble du système distribué.
Comment fonctionne le traçage distribué ?
Découvrez ci-dessous une explication détaillée du fonctionnement du traçage distribué.
Collectez des données en provenance de n'importe quelle application avec OpenTelemetry
Les traces et les spans peuvent être collectés avec OpenTelemetry (un framework d’observabilité open source). Ce dernier prend en charge un large éventail de SDK et de bibliothèques dans les principaux langages de programmation et frameworks. Ce framework propose une approche indépendante pour la collecte et l'exportation des données de télémétrie, permettant ainsi aux équipes de développement :
- d'éviter toute dépendance vis-à-vis d’un fournisseur,
- de choisir librement les outils les plus adaptés à leurs besoins.
De cette façon, si vous utilisez déjà OpenTelemetry avec un autre fournisseur et que vous souhaitez essayer les fonctionnalités de GitLab, il vous suffit d'ajouter notre point de terminaison à votre fichier de configuration pour nous envoyer vos données.
Ingérez et conservez des données à grande échelle avec des requêtes rapides et en temps réel
L'observabilité implique de stocker et d'interroger d'importants volumes de données, tout en assurant une faible latence pour les analyses en temps réel.
Pour répondre à ces exigences, nous avons développé, grâce à ClickHouse et Kubernetes, une solution de stockage à long terme qui se met à l'échelle horizontalement.
Cette plateforme open source assure une performance rapide des requêtes et une évolutivité de niveau entreprise, tout en réduisant les coûts.
Explorez et analysez les traces en toute simplicité
Une interface utilisateur native avancée est essentielle pour une exploration efficace des données. Pour cela, nous avons construit une interface, en commençant par notre Trace Explorer, permettant aux utilisateurs d'examiner les traces et de mieux comprendre les performances de leurs applications :
- Filtrage avancé. Filtrez par service, nom d'opération, statut et intervalle de temps. L'autocomplétion facilite la création des requêtes.
- Mise en évidence des erreurs. Identifiez facilement les spans contenant des erreurs dans les résultats de recherche.
- Métriques RED. Visualisez le taux de requêtes, le taux d'erreurs et la durée moyenne depuis un graphique de série temporelle pour toute recherche en temps réel.
- Vue chronologique. Les traces individuelles sont affichées sous forme de diagramme en cascade, garantissant une vue complète d'une requête distribuée entre les différents services et opérations.
- Données historiques. Les utilisateurs peuvent interroger les traces remontant jusqu'à 30 jours en arrière.
Comment nous utilisons le traçage distribué chez GitLab
L'utilisation de nos propres fonctionnalités en interne (aussi appelé Dogfooding) est une valeur fondamentale et une pratique essentielle chez GitLab.
C'est pourquoi, pour répondre aux besoins de nos équipes d'ingénierie et d'opérations, nous avons déjà commencé à utiliser les premières versions du traçage distribué.
À travers ces exemples, découvrez comment nos équipes utilisent le traçage distribué :
Déboguez les erreurs et les problèmes de performance dans GitLab Agent pour Kubernetes
Le groupe « Environments » (équipe responsable des environnements dans la phase de déploiement du cycle de vie DevOps) utilise le traçage distribué pour identifier et résoudre divers problèmes liés à GitLab Agent pour Kubernetes (comme les délais d'attente ou les problèmes de latence élevée).
Les vues « Trace List » et « Trace Timeline » fournissent des informations précieuses permettant aux équipes de traiter ces problèmes efficacement. Ces traces sont ensuite partagées et discutées dans les tickets correspondants, favorisant ainsi une collaboration efficace entre les équipes pour la résolution des problèmes.
Optimisez le temps d'exécution des pipelines en identifiant les goulots d'étranglement
Notre dépôt principal exécute plus de 100 000 pipelines chaque mois. Si le temps d'exécution de ces pipelines variait ne serait-ce que d'une minute, cela pourrait ajouter plus de 2 000 heures de travail, soit l'équivalent de 87 jours supplémentaires. C'est pourquoi, lorsque le code source de GitLab se déploie lentement, son impact est considérable, tant sur notre productivité que sur nos coûts d'exploitation.
Pour optimiser le temps d'exécution des pipelines, les équipes d'ingénierie de la plateforme GitLab utilisent un outil personnalisé qui convertit les pipelines de déploiement GitLab en traces.
Ainsi, la vue « Trace Timeline » leur permet de :
- visualiser en détail la chronologie d'exécution des pipelines complexes
- repérer les jobs qui ralentissent l'ensemble du processus.
En identifiant ces goulots d'étranglement, nos équipes peuvent optimiser l'exécution des jobs (par exemple, en accélérant l'échec du job, ou en exécutant davantage de jobs en parallèle), afin d'améliorer l'efficacité globale du pipeline. Notre script est disponible gratuitement, vous pouvez donc l'adapter à vos propres pipelines.
Testez le traçage distribué sur GitLab
Participez à notre bêta privée et testez nos fonctionnalités. Votre contribution nous aidera à développer des outils qui répondent parfaitement à vos besoins et à vos défis. Aidez- nous à façonner l'avenir de l'observabilité au sein de GitLab !