OpenTelemetry 过去主要在后端系统上采用，它是一种很好的解决方案，通过开放标准收集遥测数据，可以深入了解生产过程中发生的事情。这避免了可怕的供应商锁定成本，因为只要供应商支持 OTel 数据格式，您就可以轻松切换并控制自己的数据。

到目前为止，OTel 在移动设备上的采用还不是很广泛。然而，有早期迹象表明这种情况正在迅速改变，工程师采用该标准的原因与后端可观察性类似。与后端开发相比，移动端在收集遥测数据方面面临一些独特的挑战，在本文中，我们将重点介绍这些挑战以及一些解决方案。

1

 

移动入门挑战

在我们介绍 OTel 在移动领域的一些不同之处之前，值得将移动开发与后端开发进行比较，因为移动设备具有影响遥测收集方式的独特限制。

1.1

 

移动设备的硬件规格较低

后端服务器具有大量的 CPU 和内存，而大多数移动设备的硬件规格较低，性能较差。

此外，如果您的后端应用程序遇到性能问题，您通常只需配置更多具有更强大硬件的服务器即可。当（不是如果）您的移动应用程序遇到性能问题时，向用户提供更好的设备通常不是一个选择！因此在移动设备上，您只能支持成千上万台性能不足的 Android/iOS 设备型号。

1.2

 

对于移动设备来说，电池寿命至关重要

您可能经历过移动设备电量耗尽的沮丧。移动设备的功耗比所有设备都插入电源的后端更重要——这就是为什么移动设备上的 CPU 频率往往较低，因为它们需要的电量较少。

操作系统本身在延长移动设备电池寿命方面也更加积极。在后端可行的方法（例如每秒轮询一次数据）在移动设备上几乎总是行不通的。移动操作系统会急切地终止使用过多资源的进程，并且通常不可能让进程在后台持续运行。相比之下，这在后端相当简单。

1.3

 

网络连接

后端服务器具有稳定的网络连接，带宽大且延迟低。移动设备无法享受这些奢侈！它们的网络连接通常延迟高，可能长时间无连接（例如，启用飞行模式的长途航班），并且带宽可能较低。

1.4

 

进程生命周期差异

响应 HTTP 请求的应用服务器将持续运行。但在移动设备上并非如此。用户可能会在短时间内在数十个应用之间切换，为了节省有限的电池和计算资源，操作系统可能会随时终止这些进程而不发出警告。虽然这种情况可能在内存压力等极端情况下发生在后端，但在移动设备上，这是日常生活中常有的事。

1.5

 

交易与用户体验

后端应用程序通常具有短事务 - 一个 HTTP 请求进入，发生一些操作，然后向客户端返回响应。在移动设备上，用户可能会打开应用程序几分钟，但他们也可能会使用它几个小时，在单个会话期间与应用程序执行数百甚至数千次交互。因此，捕获的跟踪数据、上下文和持续时间在后端和移动应用程序之间可能存在巨大差异。

1.6

 

移动端在单一进程中运行

大多数移动应用程序都在单个进程中运行，这意味着 OTel 收集器和导出器在同一个进程中运行。这与后端完全不同，后端这些组件通常在单独的进程中运行。如果由于崩溃或操作系统终止而导致移动设备上的进程终止，而没有额外的工作来保存遥测数据，数据将会丢失。

2

 

这些限制对 OTel 在移动领域的发展有何影响？

2.1

 

通过较差的网络连接发送遥测

移动设备上的网络连接取决于具体情况，因此有必要为最坏的情况做好计划，即遥测数据无法传送到您选择的后端。即使您有幸在 95% 的时间里都能保持连接，但如果采用“即发即弃”的方法，您仍然可能会错过 1/20 的请求。对于移动设备，您的应用可能在数千种不同的设备上运行，这可能会给您的可观察性留下很大的漏洞。因此，在发送数据之前，保存数据至关重要。

持久化数据听起来可能很简单——只是将一堆数据写入磁盘，对吧？不幸的是，在移动设备上，这个简单的操作带来了很多复杂性。首先，普通移动设备没有太多的可用磁盘空间，因此需要以某种方式限制可以持久化的遥测数据量。这需要选择一种删除遥测数据的策略。常见的策略包括优先删除最新和最重要的类型，而不是陈旧的数据。

其次，必须处理 I/O 错误、根据数据持久化方式而可能发生的架构更改，以及从与捕获时不同的进程（甚至可能是不同的日期）发送的数据。如果工程师忘记处理这种复杂性，那么细微的错误可能会潜入您的数据管道，从而影响您的可观察性。

2.2

 

处理进程终止（崩溃或操作系统终止）

如果某个进程在移动设备上终止，则需要立即保存任何捕获的遥测数据。这部分是由于前面讨论过的网络连接不佳，但也是因为在进程终止时使用 HTTP 请求阻塞 UI 线程会导致阻塞和 ANR。

对于崩溃或操作系统终止，通常无法预测进程何时终止，而且一旦发生，可以做的事情相当有限。例如，一旦移动设备上发出 C 信号，就可以安装一个对崩溃作出反应的信号处理程序，但实现必须是异步安全的。这些实现限制使得无法发送 HTTP 请求，并且除了存储遥测数据以供以后处理之外，很难做任何事情。

为了捕获大多数遥测数据，一个选项是定期保存遥测数据，以便在下次启动应用程序时可以读取捕获数据的最新“快照”。我们稍后会详细说明这一点。

2.3

 

节省有限的设备资源

在移动设备上，没有灵丹妙药可以节省电池和内存等资源。作为一名开发应用的工程师，第一步是明智地选择要捕获哪些遥测数据。例如，每分钟轮询一次操作系统以获取内存数据在后端可能是可以接受的，但在移动设备上，最好依靠操作系统回调来处理重要事件。

在移动设备上，分析遥测代码在热路径（例如应用程序启动）中的影响也变得更加重要。在 Embrace，我们作为 SDK 供应商对自己的代码进行了这项操作，但对于您自己的应用程序也应该考虑这一点，因为每个移动应用程序在实际情况下的行为可能有所不同。

2.4

 

支持长期运行的 span

长时间运行的 span 是 OpenTelemetry 移动版面临的一个挑战，因为用户会话的运行时间比典型的后端 HTTP 请求要长得多。这意味着它们可以积累许多事件，从而使 span 负载变得非常大。span 也只能在完成之后才能发送，因此如果进程在 span 中途终止，则可能会丢失数据。

Embrace 使用“跨度快照”解决了移动设备上的这个问题。在这种方法中，所有未完成跨度的 JSON 表示会定期存储在磁盘上，如果进程意外终止，则在下次启动时，应用程序能够将它们发送到符合 OTel 标准的后端。

3

 

移动和后端 OTel 之间还有其他区别吗？

3.1

 

语义惯例不太适应

OTel 的语义约定是就应用程序应如何捕获遥测数据而达成的一致约定。这些约定非常有用，因为使用约定意味着 OTel 实现可以假定知道遥测数据包含哪些内容。

例如，后端解决方案可以处理包含 HTTP 调用信息的跨度，并在标准 OTel 之上添加自以为是的逻辑，而不是显示网络请求的 OTel 跨度，从而揭示对网络性能的卓越见解，而不是显示网络请求的 OTel 跨度。由于 OTel 历来在后端领域占有一席之地，因此与用户会话等移动事件相比，人们对 HTTP 请求和云事件等后端概念达成了更多的语义约定。

3.2

 

后端始终处于打开状态，而移动设备有用户会话

后端和移动端之间的另一个主要区别是，后端通常全年 365 天、每天 24 小时不间断运行。相比之下，移动消息应用程序的用户会话可能非常短，只有几秒钟，而电影流媒体应用程序的用户会话可能长达数小时。问题可能随着时间的推移而出现，并会涉及无数种用户、设备和应用程序条件的组合。移动环境不受控制的性质肯定比标准的 OTel 范式更为复杂。

4

 

OTel 未来在移动领域将如何发展？

Embrace 认为，OTel 社区可以通过三个关键点来改善对移动设备的支持。

4.1

 

网络连接处理

目前，OTel 的移动端实现并未充分考虑后端和移动端之间的差异，并且由于进程意外终止或长时间运行，数据很容易丢失。随着越来越多的可观测性供应商采用 OTel 并就通用解决方案达成一致，我们预计这种情况将会改变。

4.2

 

将建立更多语义约定

语义约定是约定俗成的约定，规定如何使用基本 OTel 数据类型（例如跨度和事件）来捕获遥测数据。例如，当用户插入充电器时，Android 手机进入省电模式，然后退出，这可以建模为跨度，因为它具有开始和结束时间。

如果符合 OTel 标准的后端实现支持省电模式的语义约定，那么它可以对遥测数据进行额外处理，从而可能揭示与此跨度的存在相关的隐藏趋势。从移动工程师的角度来看，这些数据很重要，因为低功耗表示操作系统将更愿意限制后台作业并减少可用的系统资源量 - 从而影响应用程序的性能。

4.3

 

OTel 生态系统将扩展到移动领域

目前，OTel 后端库和技术的生态系统已经非常丰富。移动设备上目前还没有这种生态系统，但我们相信，随着越来越多的移动工程师实施 OTel，以及越来越多的 SDK 供应商符合 OTel 标准，这种情况将会改变。

A Big Picture of Kubernetes

Kubernetes入门培训（内含PPT）

---