OpenTelemetry如何通过与Ampere合作提升Arm64代码完整性

挑战

软件开发人员和IT管理者需要工具和指标来测量软件行为。当开发者和DevOps专业人员假设软件将在单一硬件架构上运行时，可能会忽略特定架构的行为。基于Arm64的服务器（包括Ampere Altra处理器系列）相比x86提供了性能改进和节能优势，但其底层架构是Arm64，在非常低的级别上与x86架构行为不同。

2023年中期时，OpenTelemetry尚未正式支持Arm64部署。随着Arm64实例因其竞争性的性价比越来越受欢迎，监控这些系统对可观测性供应商至关重要。

解决方案

为了帮助改善这一状况，Ampere Computing向OpenTelemetry团队捐赠了搭载Ampere Altra处理器的服务器。借助这些处理器，团队可以开始为Arm64改造他们的遥测工具，并调整他们的Node.js、Java和Python代码以适应Arm64架构。

“Ampere帮助我们更好地理解如何最佳地检测代码，并在该设置中运行它，“Antoine Toulmé说道，他在担任Splunk高级工程经理的同时维护OpenTelemetry Collector项目。“这是一次有趣的经历，因为硬件非常强大。”

为了让OpenTelemetry团队将他们对Arm64的CI/CD支持提升到与x86相当的水平，他们使用了Actuated。Actuated使OpenTelemetry团队能够在自托管的GitHub Actions环境中构建管道，测试相同条件下两种架构的代码。

这样，项目可以为所有架构运行完整的测试套件，而不强迫项目开发者为每种架构选择不同的测试。结果，项目对Arm64的支持正接近与x86相当的水平。

成果

OpenTelemetry现在为Arm64和x86开发者和IT管理者提供了他们所需的工具和指标。因此，在生产环境中运行OpenTelemetry的客户正在体验更可靠、更稳定的代码。

这不仅适用于所有处理器架构，也适用于所有操作系统：识别和修复如竞争条件这样的错误（在Arm64上更容易触发）的好处是使项目对每种架构和操作系统都更好。OpenTelemetry的Toulmé表示，他的团队在从x86转向Arm64后，仅通过减少部署实例的数量、大小、规模和内存分配就实现了15%的成本节约。

开发者故事

一类软件的性能特征最有可能因处理器架构而异，那就是可观测性平台。以下是OpenTelemetry如何通过使其对Arm的集成测试更加健壮，为每个人提供更好的可观测性。

直到几年前，软件开发人员和IT操作人员还对应用程序的哪些方面最需要测量存在分歧。那时它不被称为"可观测性”，而是"应用程序性能管理（APM）"，与"业务性能监控”（BPM）互换使用。

开发者想要详细的事务跟踪和内存中的活动日志。操作人员想要一个秒表，当某个过程似乎开始和结束时触发，并测量两个事件之间间隔的短暂性。

OpenTelemetry（OTel）为两个群体提供了他们所需的工具和指标，或者至少是设计这些指标的工具。它提供了一个前端，可以与现代可观测性和工具系统一起使用，这些系统已经取代了旧的APM系统，包括来自Dynatrace和New Relic等长期供应商的系统，也包括Honeycomb、Splunk和Datadog等新服务提供商，以及开源的Prometheus监控系统。OpenTelemetry已成为云原生计算基金会（CNCF）按贡献者数量计算的第二大项目，仅次于Kubernete。

为了使OpenTelemetry的工具健壮可靠，CNCF开发者必须在所有能够运行它的服务器平台上进行测试。基于Arm64的服务器，包括Ampere Altra处理器系列，提供了性能改进和节能优势。但这些处理器的底层架构是Arm64，在非常低的级别上与x86（AMD64）架构行为不同。测试OpenTelemetry对Arm64的支持还有一个额外的好处，即揭示在仅对x86进行测试时项目测试套件中未出现的潜在问题。

平衡天平

2023年中期，CNCF的贡献开发者面临着来自用户的越来越大的压力，要求支持基于Arm64的服务器的监控。随着Arm64实例因其竞争性的性价比越来越受欢迎，监控这些系统对可观测性供应商至关重要。由于OpenTelemetry为Kubernetes应用程序开发者提供了一个通用接口，社区有压力要求为OpenTelemetry添加对多达128核的Arm64处理器（如Ampere Altra）的支持。

当时，OpenTelemetry尚未正式支持Arm64部署。为了帮助改善这一状况，Ampere向OpenTelemetry团队捐赠了搭载Ampere Altra处理器的服务器。借助这些处理器，团队可以开始为Arm64改造他们的遥测工具，并调整他们的Node.js、Java和Python代码以适应Arm64架构。

“Ampere帮助我们更好地理解如何最佳地检测代码，并在该设置中运行它，“Antoine Toulmé说道，他在担任Splunk高级工程经理的同时维护OpenTelemetry Collector项目。“这是一次有趣的经历，因为硬件非常强大。”

Toulmé指出，从代码开发的角度来看，他的团队在采用Arm架构和生态系统方面几乎没有遇到困难。测试带来了最大的挑战，特别是在将代码与第三方框架、应用程序和库集成时。

“我们会看到，例如，声称符合Arm标准的Docker镜像，“Toulmé继续说道，“当你在CI/CD环境中运行它们，并且你实际上打算在Arm服务器上运行它们时，你意识到它们只是重新打包了amd64代码，它们只是让它像Arm一样运行。这有点让人失望。”

当开发者和DevOps专业人员假设软件将在单一硬件架构上运行时，他们可能会忽略特定架构的行为。他们也可能错过在该架构上不常出现的代码问题。

因此，他们可能找不到某些简单的异常，如竞争条件，因为硬件的行为方式掩盖了潜在问题，当两个或多个进程尝试异步访问同一资源时。

OpenTelemetry取代了那些像刷子上的线头一样聚集在内存后部的APM代理的是Collector组件。用Golang编写的Collector是一个代理，作为工具库导出其遥测数据的目的地点。

当Collector首次为Arm64编译时，Toulmé回忆说，发现了几个竞争条件问题，因为x86和Arm64处理器流水线的处理方式不同，以及CPU上可用的核心数量。这是OTel团队的第一个迹象，表明Arm架构以非常不同的方式处理竞争条件。

“我们收到了一些早期客户的反馈，说一些OpenTelemetry工具在Arm上运行不佳，因为有太多核心。你从四个核心到128个，有时256个。”

项目维护者使用Ampere的服务器测试并解决了这些问题，用于他们所有的Node.js、Java和Python代码。“在过去的两年里，“Toulmé说，“我们看到对Arm的支持有了巨大的改进。”

微型虚拟机解决方案

为了让OpenTelemetry团队将他们对Arm64的CI/CD支持提升到与x86相当的水平，他们与Actuated的主要开发者Alex Ellis合作。Actuated是一个平台，为最常见的CI/CD系统之一GitHub Actions提供托管运行器，使用选择的处理器架构。这使得在异构服务器环境中构建和测试项目更加容易。Actuated通过在与其他工作负载隔离的微型虚拟机中运行进程来实现这一点，这些工作负载在同一主机上运行。

“我们从尝试过GitHub的Kubernetes操作员的客户那里看到了这一点，“Ellis指出，他也是无服务器微服务框架OpenFaaS的创建者。“在你构建或运行容器之前，它是可以的，然后你需要提升特权，以至于你可以危及整个集群中的每个节点。很多人对此视而不见。”

“这就是Actuated的意义所在，“Ellis继续说道。“相反，使用微型虚拟机，它们有自己的Docker实例，完全隔离，只存在于构建的生命周期内——然后它们被完全销毁。使用微型虚拟机有一些开销，但主要来说，CI更多的是关于CPU速度和有足够的RAM来容纳你的程序，而不是原始I/O。”

将所有应用程序代码组件放在虚拟化包中，将它们与更广泛的网络（尤其是公共互联网）隔离开来，至少有一层抽象。这为所有处理器架构（包括x86和Arm64）的软件组件提供了更安全的运行环境。

回报

现在，OpenTelemetry团队可以发现被x86测试遗漏的行为问题。因此，在生产环境中运行OpenTelemetry的客户正在体验更可靠、更稳定的代码。这不仅适用于所有处理器架构，也适用于所有操作系统：识别和修复如竞争条件这样的错误（在Arm64上更容易触发）的好处是使项目对每种架构和操作系统都更好。

OpenTelemetry的Toulmé表示，他的团队在从x86转向Arm64后，仅通过减少部署实例的数量、大小、规模和内存分配就实现了15%的成本节约。现在，团队可以朝着能够以与x86客户问题相同的关心和关注来响应基于Arm64的客户问题的方向发展。这就是OpenTelemetry的目标：到2025年底实现一级支持。

“我们对结果非常满意，“Toulmé说。“我们看到Arm上的性能比我们从旧的x86服务器上获得的要高得多。对于我们的客户，我们发布了支持Linux/AMD64以及所有Arm64变体的Docker镜像。我们看到Arm64下载量大幅增加。我们看到了全面的成本降低15%。我可以毫无疑问地说，我是一个转变者。”