Comment l’OpenTelemetry a amélioré son intégrité de code pour ARM64 en travaillant avec Ampère –
Instantané
Défi
Les développeurs de logiciels et les responsables informatiques ont besoin d’instruments et de mesures pour mesurer le comportement des logiciels. Lorsque les développeurs et les professionnels DevOps supposent que les logiciels fonctionneront sur une seule architecture matérielle, ils peuvent ignorer le comportement spécifique à l’architecture. Les serveurs basés sur ARM64, y compris la famille de processeurs Ampère Altra, offrent des améliorations des performances et des économies d’énergie sur X86, mais l’architecture sous-jacente est ARM64, qui se comporte différemment par rapport à l’architecture x86 à un niveau très bas.
À l’époque, mi-2023, OpenTelemetry ne prenait formellement pas officiellement les déploiements ARM64. À mesure que la popularité des instances ARM64 augmentait en raison de leur performance de prix compétitive, la surveillance de ces systèmes était essentielle pour les fournisseurs d’observabilité.
Solution
Pour aider à rectifier cette situation, Ampère Computing a donné des serveurs alimentés par Ampère Ampère à l’équipe d’Opentelemytry. Avec ces processeurs, l’équipe pourrait commencer à rénover leur instrumentation de télémétrie pour ARM64 et à adapter son code Node.js, Java et Python pour l’architecture ARM64.
« Ampère nous a donné une longueur d’avance pour comprendre comment instrument le code et l’exécuter dans cette configuration », a déclaré Antoine Toulmé, qui maintient le projet de collecteur d’Opentelemetry tout en étant directeur de l’ingénierie senior chez Splunk. «Ce fut une expérience intéressante car c’est un matériel vraiment puissant.»
Pour que l’équipe d’OpenTelemetry apporte son support CI / CD pour ARM64 jusqu’à la parité avec x86, ils ont utilisé l’actionnement. L’équipe OpenTelemetry en activation de l’OpenTelelemetry pour mettre en scène un environnement d’action GitHub auto-hébergé dans lequel ils pouvaient construire des pipelines qui ont testé le code dans les deux architectures pour les mêmes conditions.
De cette façon, le projet pourrait exécuter sa suite de test complète pour toutes les architectures, sans forcer les développeurs du projet à sélectionner différents tests pour chaque architecture. En conséquence, le support du projet pour ARM64 aborde la parité avec x86.
Résultats
L’OpenTelemetry a désormais donné aux développeurs ARM64 et X86 et les gestionnaires informatiques l’instrumentation et les mesures dont ils ont besoin. En conséquence, les clients qui exécutent l’OpenTelemétrie en production connaissent un code plus fiable et plus stable.
Cela est vrai non seulement pour toutes les architectures de processeur, mais tous les systèmes d’exploitation: identifier et corriger des bogues comme les conditions de course, qui peuvent être plus faciles à déclencher sur ARM64, a l’avantage d’améliorer le projet pour chaque architecture et système d’exploitation. Le Toulmé d’OpenTelemetry dit que son équipe a vu des économies de coûts de 15% uniquement en réduisant la quantité, la taille, l’échelle et l’attribution de la mémoire des instances de déploiement, après être passé de x86 à ARM64.
Histoire du développeur
Une classe de logiciels dont les caractéristiques de performance sont les plus susceptibles de différer selon les architectures de processeur est la plate-forme d’observabilité. Voici comment l’OpenteLelemetry a amélioré l’observabilité pour tout le monde en rendant ses tests d’intégration pour ARM plus robustes.
Jusqu’à il y a quelques années, les développeurs de logiciels et les opérateurs informatiques étaient en désaccord sur les aspects d’une application devaient être mesurés le plus. Il n’était pas appelé «observabilité» à l’époque, mais plutôt «Gestion des performances des applications (APM), qui a été utilisée de manière interchangeable avec la« surveillance des performances commerciales »(BPM).
Les développeurs voulaient des traces détaillées et des journaux de transactions et d’activité en mémoire. Les opérateurs voulaient qu’un chronomètre soit déclenché lorsqu’un processus semblait commencer et semblait se terminer, et mesurer la brièveté de l’intervalle entre les deux événements.
Opentelémétrie (Otel) a donné aux deux groupes l’instrumentation et les mesures dont ils ont besoin, ou à tout le moins, les outils pour concevoir ces mesures. Il fournit un frontal qui peut être utilisé avec des systèmes d’observabilité et d’instrumentation modernes qui ont remplacé les systèmes APM d’ancien, y compris des fournisseurs de longue date tels que Dynatatatrace et Nouvelle reliquemais aussi de nouveaux fournisseurs de services tels que Rayon de miel, Sabotet Médecin de donnéeset le Système de surveillance de Prometheus open source. L’OpenTelemetry est devenue le deuxième projet du plus grand projet de la Cloud Native Computing Foundation (CNCF) par nombre de contributeurs, après Kubernetes.
Pour que l’instrumentation d’OpenTelemetry soit robuste et fiable, les développeurs CNCF doivent le tester sur toutes les plates-formes de serveur capables de l’exécuter. Les serveurs basés sur ARM64, y compris la famille de processeurs Ampère Altra, offrent des améliorations des performances et des économies d’énergie. Mais l’architecture sous-jacente de ces processeurs est ARM64, qui se comporte différemment de l’architecture x86 (AMD64) à un niveau très bas. Le test de l’OpenTelemetry pour ARM64 a l’avantage supplémentaire de révéler des problèmes potentiels qui ne s’étaient pas présentés dans les suites de test du projet lorsqu’elles sont testées uniquement sur x86.
Équilibrer les échelles
À la mi-2023, les développeurs contribués au CNCF étaient confrontés à une pression croissante des utilisateurs pour soutenir la surveillance des serveurs basés sur ARM64. À mesure que la popularité des instances ARM64 augmentait en raison de leur performance de prix compétitive, la surveillance de ces systèmes était essentielle pour les fournisseurs d’observabilité. Comme OpenteLeletmetry fournit une interface commune pour les développeurs d’applications Kubernetes, il y avait une pression communautaire pour ajouter un support à l’OpenTelemetry pour les processeurs ARM64 avec jusqu’à 128 cœurs, tels que Ampère Altra.
À cette époque, l’OpenTelemetry n’a pas officiellement pris en charge les déploiements ARM64. Pour aider à rectifier cette situation, Ampère a fait don de serveurs alimentés par Ampère Altra à l’équipe d’Opentelemetry. Avec ces processeurs, l’équipe pourrait commencer à rénover leur instrumentation de télémétrie pour ARM64 et à adapter son code Node.js, Java et Python pour l’architecture ARM64.
« Ampère nous a donné une longueur d’avance pour comprendre comment instrument le code et l’exécuter dans cette configuration », a déclaré Antoine Toulmé, qui maintient le projet de collecteur d’Opentelemetry tout en étant directeur de l’ingénierie senior chez Splunk. «Ce fut une expérience intéressante car c’est un matériel vraiment puissant.»
Toulmé a noté que son équipe avait peu de mal à adopter l’architecture des bras et l’écosystème du point de vue du développement du code. Les tests ont présenté les plus grands défis, en particulier lors de l’intégration du code avec des cadres, des applications et des bibliothèques tiers.
« Nous verrions, par exemple, des images Docker qui affirmaient qu’elles étaient conformes aux bras », a poursuivi Toulmé, « et lorsque vous les exécutez dans un environnement CI / CD et vous voulez en fait les exécuter sur un serveur ARM, vous vous rendez compte qu’ils réapprochaient juste un code AMD64, et ils l’ont fait s’exécuter comme si c’était un bras. C’était un peu de dénouement. »
Photo: Antoine Toulmé présentant une télémétrie ouverte sur un système76 Thelio Astra, propulsée par un 128 Core Ampère Altra Max, à Kubecon EU 2025 (crédits: Dave Neary)
Lorsque les développeurs et les professionnels DevOps supposent que les logiciels fonctionneront sur une seule architecture matérielle, ils peuvent ignorer le comportement spécifique à l’architecture. Ils peuvent également manquer des problèmes avec le code qui n’apparaît pas fréquemment sur cette architecture.
En conséquence, ils peuvent ne pas trouver certaines anomalies simples telles que conditions de courseparce que le matériel se comporte d’une manière qui cache des problèmes potentiels lorsque deux processus ou plus tentent d’accéder à la même ressource de manière asynchrone.
Le remplacement de l’OpenTelemetry pour les agents APM qui se rassemblait à l’arrière de la mémoire comme la peluche sur une brosse, est le Composant collecteur. Écrit à Golang, Collector est un agent qui sert de point de destination pour les bibliothèques d’instruments afin d’exporter leurs données de télémétrie.
Lorsque Collector a été compilé pour la première fois pour ARM64, rappelle Toulmé, plusieurs problèmes de condition de course ont été découverts, en raison de la manière différente de la manipulation des pipelines de processeur X86 et ARM64 et du nombre de noyaux disponibles sur le CPU. C’était le premier indicateur de l’équipe Otel que l’architecture des bras gère les conditions de course d’une manière très différente.
«Nous avons eu quelques commentaires précoces des clients que certaines des instrumentations d’OpenTelemetry ne fonctionnaient pas bien sur ARM parce qu’il y avait tellement de cœurs. Vous passez de quatre cœurs à 128, 256 parfois.»
Les responsables du projet ont testé et résolu ces problèmes à l’aide de serveurs d’Ampère pour tous leurs code Node.js, Java et Python. « Au cours des deux dernières années », a déclaré Toulmé, « nous avons constaté une énorme amélioration de soutien à ARM. »
La solution de microvm
Pour que l’équipe d’OpenTelemetry apporte son support CI / CD pour ARM64 jusqu’à la parité avec x86, ils ont collaboré avec Développeur principal actionné Alex Ellis. ACTUTIED est une plate-forme qui fournit des coureurs hébergés pour l’un des systèmes CI / CD les plus courants, les actions GitHub, en utilisant son choix d’architectures de processeur. Cela facilite la création et le test des projets dans des environnements de serveur hétérogènes. ACTUTIED accomplit cela en exécutant des processus dans les microvms qui sont isolés des autres charges de travail fonctionnant sur le même hôte.
« Nous l’avons vu de clients qui ont essayé l’opérateur Kubernetes de Github », a noté Ellis, qui est également le créateur de Framework Microservices sans serveur OpenFAAS. « C’est bon jusqu’à ce que vous construisez ou exécutez un conteneur, puis vous avez besoin des privilèges élevés si haut que vous pouvez compromettre chaque nœud dans l’ensemble du cluster. Et beaucoup de gens mettent la tête dans le sable à ce sujet. »
« C’est ce qu’est le sujet de l’action », a poursuivi Ellis. « Au lieu de cela, les microvms sont utilisés qui ont leurs propres instances Docker, qui sont complètement isolés et n’existent que pour la durée de vie de la construction – alors ils sont complètement détruits. Il y a des frais généraux avec l’utilisation d’un microvm, mais principalement, CI est plus une question de processeur et d’avoir suffisamment de RAM pour s’adapter à vos programmes, que des E / S brutes. »
La mise en scène de tous les composants de code d’application dans des packages virtualisés les sépare des réseaux plus larges, en particulier l’Internet public, avec au moins une couche d’abstraction. Il en résulte un environnement de course plus sûr pour les composants logiciels pour toutes les architectures de processeur, y compris x86 et ARM64.
Payer
Désormais, l’équipe d’OpenTelemetry peut repérer les problèmes de comportement qui ont été manqués par des tests sur x86. En conséquence, les clients qui exécutent l’OpenTelemétrie en production connaissent un code plus fiable et plus stable. Cela est vrai non seulement pour toutes les architectures de processeur, mais tous les systèmes d’exploitation: identifier et corriger des bogues comme les conditions de course, qui peuvent être plus faciles à déclencher sur ARM64, a l’avantage d’améliorer le projet pour chaque architecture et système d’exploitation.
Le Toulmé d’OpenTelemetry dit que son équipe a vu des économies de coûts de 15% uniquement en réduisant la quantité, la taille, l’échelle et l’attribution de la mémoire des instances de déploiement, après être passé de x86 à ARM64. Maintenant, l’équipe peut travailler vers une situation où elle peut répondre aux problèmes clients basés sur ARM64 avec les mêmes soins et l’attention qu’ils accordent aux problèmes clients basés sur X86. C’est l’objectif d’OpenTelemetry: Support de niveau 1 d’ici la fin de 2025.
« Nous sommes très heureux des résultats », a déclaré Toulmé. « Nous voyons que les performances sur ARM sont beaucoup plus élevées que ce que nous obtiendrions avec les serveurs Legaca X86. Pour nos clients, nous avons publié des images Docker qui prennent en charge à la fois Linux / AMD64, mais aussi toutes les variantes ARM64. Nous voyons une grande altitude en termes de téléchargements ARM64. Nous voyons une réduction des coûts de quinze pour cent à travers le tableau. Je peux dire, sans aucun doute, je suis un converti. »
juin 26, 2025
Comment l’OpenTelemetry a amélioré son intégrité de code pour ARM64 en travaillant avec Ampère –
Instantané
Défi
Les développeurs de logiciels et les responsables informatiques ont besoin d’instruments et de mesures pour mesurer le comportement des logiciels. Lorsque les développeurs et les professionnels DevOps supposent que les logiciels fonctionneront sur une seule architecture matérielle, ils peuvent ignorer le comportement spécifique à l’architecture. Les serveurs basés sur ARM64, y compris la famille de processeurs Ampère Altra, offrent des améliorations des performances et des économies d’énergie sur X86, mais l’architecture sous-jacente est ARM64, qui se comporte différemment par rapport à l’architecture x86 à un niveau très bas.
À l’époque, mi-2023, OpenTelemetry ne prenait formellement pas officiellement les déploiements ARM64. À mesure que la popularité des instances ARM64 augmentait en raison de leur performance de prix compétitive, la surveillance de ces systèmes était essentielle pour les fournisseurs d’observabilité.
Solution
Pour aider à rectifier cette situation, Ampère Computing a donné des serveurs alimentés par Ampère Ampère à l’équipe d’Opentelemytry. Avec ces processeurs, l’équipe pourrait commencer à rénover leur instrumentation de télémétrie pour ARM64 et à adapter son code Node.js, Java et Python pour l’architecture ARM64.
« Ampère nous a donné une longueur d’avance pour comprendre comment instrument le code et l’exécuter dans cette configuration », a déclaré Antoine Toulmé, qui maintient le projet de collecteur d’Opentelemetry tout en étant directeur de l’ingénierie senior chez Splunk. «Ce fut une expérience intéressante car c’est un matériel vraiment puissant.»
Pour que l’équipe d’OpenTelemetry apporte son support CI / CD pour ARM64 jusqu’à la parité avec x86, ils ont utilisé l’actionnement. L’équipe OpenTelemetry en activation de l’OpenTelelemetry pour mettre en scène un environnement d’action GitHub auto-hébergé dans lequel ils pouvaient construire des pipelines qui ont testé le code dans les deux architectures pour les mêmes conditions.
De cette façon, le projet pourrait exécuter sa suite de test complète pour toutes les architectures, sans forcer les développeurs du projet à sélectionner différents tests pour chaque architecture. En conséquence, le support du projet pour ARM64 aborde la parité avec x86.
Résultats
L’OpenTelemetry a désormais donné aux développeurs ARM64 et X86 et les gestionnaires informatiques l’instrumentation et les mesures dont ils ont besoin. En conséquence, les clients qui exécutent l’OpenTelemétrie en production connaissent un code plus fiable et plus stable.
Cela est vrai non seulement pour toutes les architectures de processeur, mais tous les systèmes d’exploitation: identifier et corriger des bogues comme les conditions de course, qui peuvent être plus faciles à déclencher sur ARM64, a l’avantage d’améliorer le projet pour chaque architecture et système d’exploitation. Le Toulmé d’OpenTelemetry dit que son équipe a vu des économies de coûts de 15% uniquement en réduisant la quantité, la taille, l’échelle et l’attribution de la mémoire des instances de déploiement, après être passé de x86 à ARM64.
Histoire du développeur
Une classe de logiciels dont les caractéristiques de performance sont les plus susceptibles de différer selon les architectures de processeur est la plate-forme d’observabilité. Voici comment l’OpenteLelemetry a amélioré l’observabilité pour tout le monde en rendant ses tests d’intégration pour ARM plus robustes.
Jusqu’à il y a quelques années, les développeurs de logiciels et les opérateurs informatiques étaient en désaccord sur les aspects d’une application devaient être mesurés le plus. Il n’était pas appelé «observabilité» à l’époque, mais plutôt «Gestion des performances des applications (APM), qui a été utilisée de manière interchangeable avec la« surveillance des performances commerciales »(BPM).
Les développeurs voulaient des traces détaillées et des journaux de transactions et d’activité en mémoire. Les opérateurs voulaient qu’un chronomètre soit déclenché lorsqu’un processus semblait commencer et semblait se terminer, et mesurer la brièveté de l’intervalle entre les deux événements.
Opentelémétrie (Otel) a donné aux deux groupes l’instrumentation et les mesures dont ils ont besoin, ou à tout le moins, les outils pour concevoir ces mesures. Il fournit un frontal qui peut être utilisé avec des systèmes d’observabilité et d’instrumentation modernes qui ont remplacé les systèmes APM d’ancien, y compris des fournisseurs de longue date tels que Dynatatatrace et Nouvelle reliquemais aussi de nouveaux fournisseurs de services tels que Rayon de miel, Sabotet Médecin de donnéeset le Système de surveillance de Prometheus open source. L’OpenTelemetry est devenue le deuxième projet du plus grand projet de la Cloud Native Computing Foundation (CNCF) par nombre de contributeurs, après Kubernetes.
Pour que l’instrumentation d’OpenTelemetry soit robuste et fiable, les développeurs CNCF doivent le tester sur toutes les plates-formes de serveur capables de l’exécuter. Les serveurs basés sur ARM64, y compris la famille de processeurs Ampère Altra, offrent des améliorations des performances et des économies d’énergie. Mais l’architecture sous-jacente de ces processeurs est ARM64, qui se comporte différemment de l’architecture x86 (AMD64) à un niveau très bas. Le test de l’OpenTelemetry pour ARM64 a l’avantage supplémentaire de révéler des problèmes potentiels qui ne s’étaient pas présentés dans les suites de test du projet lorsqu’elles sont testées uniquement sur x86.
Équilibrer les échelles
À la mi-2023, les développeurs contribués au CNCF étaient confrontés à une pression croissante des utilisateurs pour soutenir la surveillance des serveurs basés sur ARM64. À mesure que la popularité des instances ARM64 augmentait en raison de leur performance de prix compétitive, la surveillance de ces systèmes était essentielle pour les fournisseurs d’observabilité. Comme OpenteLeletmetry fournit une interface commune pour les développeurs d’applications Kubernetes, il y avait une pression communautaire pour ajouter un support à l’OpenTelemetry pour les processeurs ARM64 avec jusqu’à 128 cœurs, tels que Ampère Altra.
À cette époque, l’OpenTelemetry n’a pas officiellement pris en charge les déploiements ARM64. Pour aider à rectifier cette situation, Ampère a fait don de serveurs alimentés par Ampère Altra à l’équipe d’Opentelemetry. Avec ces processeurs, l’équipe pourrait commencer à rénover leur instrumentation de télémétrie pour ARM64 et à adapter son code Node.js, Java et Python pour l’architecture ARM64.
Toulmé a noté que son équipe avait peu de mal à adopter l’architecture des bras et l’écosystème du point de vue du développement du code. Les tests ont présenté les plus grands défis, en particulier lors de l’intégration du code avec des cadres, des applications et des bibliothèques tiers.
Lorsque les développeurs et les professionnels DevOps supposent que les logiciels fonctionneront sur une seule architecture matérielle, ils peuvent ignorer le comportement spécifique à l’architecture. Ils peuvent également manquer des problèmes avec le code qui n’apparaît pas fréquemment sur cette architecture.
En conséquence, ils peuvent ne pas trouver certaines anomalies simples telles que conditions de courseparce que le matériel se comporte d’une manière qui cache des problèmes potentiels lorsque deux processus ou plus tentent d’accéder à la même ressource de manière asynchrone.
Le remplacement de l’OpenTelemetry pour les agents APM qui se rassemblait à l’arrière de la mémoire comme la peluche sur une brosse, est le Composant collecteur. Écrit à Golang, Collector est un agent qui sert de point de destination pour les bibliothèques d’instruments afin d’exporter leurs données de télémétrie.
Lorsque Collector a été compilé pour la première fois pour ARM64, rappelle Toulmé, plusieurs problèmes de condition de course ont été découverts, en raison de la manière différente de la manipulation des pipelines de processeur X86 et ARM64 et du nombre de noyaux disponibles sur le CPU. C’était le premier indicateur de l’équipe Otel que l’architecture des bras gère les conditions de course d’une manière très différente.
Les responsables du projet ont testé et résolu ces problèmes à l’aide de serveurs d’Ampère pour tous leurs code Node.js, Java et Python. « Au cours des deux dernières années », a déclaré Toulmé, « nous avons constaté une énorme amélioration de soutien à ARM. »
La solution de microvm
Pour que l’équipe d’OpenTelemetry apporte son support CI / CD pour ARM64 jusqu’à la parité avec x86, ils ont collaboré avec Développeur principal actionné Alex Ellis. ACTUTIED est une plate-forme qui fournit des coureurs hébergés pour l’un des systèmes CI / CD les plus courants, les actions GitHub, en utilisant son choix d’architectures de processeur. Cela facilite la création et le test des projets dans des environnements de serveur hétérogènes. ACTUTIED accomplit cela en exécutant des processus dans les microvms qui sont isolés des autres charges de travail fonctionnant sur le même hôte.
La mise en scène de tous les composants de code d’application dans des packages virtualisés les sépare des réseaux plus larges, en particulier l’Internet public, avec au moins une couche d’abstraction. Il en résulte un environnement de course plus sûr pour les composants logiciels pour toutes les architectures de processeur, y compris x86 et ARM64.
Payer
Désormais, l’équipe d’OpenTelemetry peut repérer les problèmes de comportement qui ont été manqués par des tests sur x86. En conséquence, les clients qui exécutent l’OpenTelemétrie en production connaissent un code plus fiable et plus stable. Cela est vrai non seulement pour toutes les architectures de processeur, mais tous les systèmes d’exploitation: identifier et corriger des bogues comme les conditions de course, qui peuvent être plus faciles à déclencher sur ARM64, a l’avantage d’améliorer le projet pour chaque architecture et système d’exploitation.
Le Toulmé d’OpenTelemetry dit que son équipe a vu des économies de coûts de 15% uniquement en réduisant la quantité, la taille, l’échelle et l’attribution de la mémoire des instances de déploiement, après être passé de x86 à ARM64. Maintenant, l’équipe peut travailler vers une situation où elle peut répondre aux problèmes clients basés sur ARM64 avec les mêmes soins et l’attention qu’ils accordent aux problèmes clients basés sur X86. C’est l’objectif d’OpenTelemetry: Support de niveau 1 d’ici la fin de 2025.
Source link
Partager :
Articles similaires