OpenTelemetry (OTel) 长期以来主要应用于后端系统，通过收集符合开放标准的遥测数据，为生产环境提供深入洞察，从而避免供应商锁定的高额成本。只要提供商支持 OTel 数据格式，用户就可以轻松切换供应商，掌控自己的数据。
然而，OTel 在移动端的应用相对较少。然而，最近出现了越来越多的迹象表明，工程师们开始在移动端采用该标准，其原因与后端可观测性类似。移动端与后端开发相比，具有许多独特的遥测收集挑战。本文将探讨这些挑战，并提供解决方案。
移动端遥测的独特挑战
在探讨 OTel 在移动端的应用之前，有必要将移动端开发与后端开发进行对比，因为移动设备的独特限制会影响遥测数据的收集。
硬件规格较低
后端服务器通常拥有强大的 CPU 和内存资源，而大多数移动设备的硬件规格较低，性能较弱。
如果后端应用程序出现性能问题，通常可以通过配置更强大的服务器来解决。但在移动端，如果应用性能不佳，显然无法让用户更换设备。因此，移动应用需要支持成千上万种性能各异的 Android 和 iOS 设备型号。
电池续航至关重要
移动设备的电池续航至关重要，这与一直连接电源的后端服务器截然不同。因此，移动端的 CPU 通常采用低频设计以降低功耗。
移动操作系统会积极管理资源，延长电池续航。例如，频繁的数据轮询在移动端通常不可行。此外，操作系统会终止占用过多资源的进程，而持续在后台运行的进程通常是不被允许的。
网络连接不稳定
与拥有高带宽、低延迟和稳定网络连接的后端服务器不同，移动设备的网络连接通常具有高延迟，甚至可能在长途飞行等情况下完全断开连接。因此，移动端应用需要能够应对间歇性网络中断和较低的带宽环境。
进程生命周期差异
后端服务器通常连续运行以响应 HTTP 请求，而移动应用的生命周期则截然不同。用户可能在短时间内频繁切换多个应用，操作系统会在内存紧张时随时终止这些应用进程。这在后端服务器中仅在极端情况下发生，但在移动端却是日常操作。
事务与用户体验的差异
后端应用通常执行短时间事务，例如处理 HTTP 请求，而移动应用的用户会长时间使用应用程序，并在单个会话中执行数百甚至数千次交互。因此，移动端捕获的跟踪数据在时长和上下文上与后端系统大相径庭。
单进程运行模式
大多数移动应用在单个进程中运行，因此 OTel 的收集器和导出器也运行在同一进程中。如果该进程因崩溃或操作系统终止而退出，遥测数据将丢失，除非开发人员采取措施将其持久化存储。
这些限制对移动端 OTel 有何影响？
在不稳定的网络环境中发送遥测数据
由于移动设备的网络连接不稳定，必须设计出能够应对数据传输失败的遥测系统。如果简单采用“发送即忘”的方法，即使连接成功率为 95%，也意味着每 20 个请求就会丢失 1 个。这对运行在成千上万台设备上的移动应用来说，将导致巨大的数据缺失。因此，必须先将数据持久化，然后再发送。
持久化数据听起来简单，但在移动端却非常复杂。移动设备的存储空间有限，因此需要实施删除策略，优先保留最新和最重要的数据，而非过时数据。此外，还需要处理 I/O 错误、数据架构变更以及跨进程和跨日期的数据存储和发送问题。忽略这些复杂性可能导致数据管道中的隐性错误，从而影响可观测性。
应对进程终止（崩溃或操作系统终止）
如果移动设备上的进程终止，必须立即保存遥测数据。崩溃或进程被系统终止后，无法再发送 HTTP 请求，能做的只有将遥测数据持久化，以便在应用程序下次启动时继续发送。
一种解决方案是定期持久化遥测数据，保存“快照”，确保下次启动时拥有最新的数据。
资源管理与节能策略
在移动设备上，资源（如电池和内存）是有限的。工程师必须明智地选择哪些遥测数据需要捕获。例如，在内存数据的收集中，频繁轮询操作系统在移动端是不现实的，而依赖系统回调在关键事件发生时触发操作更为合理。
另外，在应用程序启动等性能敏感的路径中，剖析遥测代码的影响至关重要。这也是遥测 SDK 开发人员需要不断优化的方面。
支持长时间跨度跟踪
与后端的 HTTP 请求相比，移动端的用户会话可能持续数小时，生成大量事件，从而导致跟踪跨度数据过大。此外，跨度必须等到完成后才能发送，如果进程在跨度完成前终止，则会导致数据丢失。
一种解决方案是使用“跨度快照”，将未完成的跨度数据存储在磁盘上。如果进程意外终止，应用程序可以在下次启动时将数据发送到 OTel 兼容的后端。
OTel 在移动端的未来发展方向
1. 改进网络连接处理： 移动端 OTel 实现需要更好地适配后端与移动端的差异，尤其是在进程终止和长时间跨度的跟踪数据处理方面。
2. 更多语义约定支持： 随着更多 OTel 社区成员参与移动端开发，未来将建立更多针对移动端应用的语义标准，例如用户会话和电量模式等关键指标。
3. 扩展到更广泛的移动生态系统： 未来，OTel 在移动端的生态系统将持续扩展，为常见库和框架提供标准化的遥测实现，从而减少开发人员的集成工作量。
欢迎加入云原生社区或向社区投稿，点击阅读原文了解更多。
文章转载自云原生社区动态。点击这里阅读原文了解更多。
CNCF概况（幻灯片）
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请关注CNCF微信公众号。
