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）贡献者数量第二大的项目，仅次于Kubernetes。
为使OpenTelemetry的检测工具健壮可靠，CNCF开发者必须在所有能运行它的服务器平台上进行测试。基于Arm64的服务器（包括Ampere Altra处理器系列）提供性能改进和节能优势。但这些处理器的底层架构是Arm64，在极低层级上与x86（AMD64）架构行为不同。测试OpenTelemetry for 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上运行不佳，因为核心数量太多。你从4个核心增加到128个，有时是256个。”
项目维护者使用Ampere的服务器测试并解决了所有这些Node.js、Java和Python代码的问题。“在过去的两年里，“Toulmé说，“我们看到对Arm的支持有了巨大改进。”
微虚拟机解决方案
为使OpenTelemetry团队将Arm64的CI/CD支持提升至与x86对等，他们与Actuated首席开发者Alex Ellis合作。Actuated是一个平台，为最常见的CI/CD系统之一GitHub Actions提供托管运行器，使用用户选择的处理器架构。这使得在异构服务器环境中构建和测试项目更加容易。Actuated通过在与同一主机上运行的其他工作负载隔离的微VM中运行进程来实现这一点。
“我们从尝试GitHub的Kubernetes操作器的客户那里看到了这一点，“Ellis指出，他也是无服务器微服务框架OpenFaaS的创建者。“直到你构建或运行容器时还好，但然后你需要提升特权如此之高，以至于可能危及整个集群中的每个节点。许多人对此视而不见。”
“这就是Actuated的意义所在，“Ellis继续说。“相反，使用具有自己的Docker实例的微VM，这些实例完全隔离，仅存在于构建的生命周期内——然后它们被完全销毁。使用微VM有一些开销，但主要地，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%。我可以毫无疑问地说，我是一个转变者。”