DOP 283: OpenTelemetry Meets Mobile
41:21 Share

#283: 今天的重点从通常的可观察性领域转向移动领域——OpenTelemetry 的一个相对未开发的领域。将 OpenTelemetry 集成到移动应用程序中为移动应用程序的可观察性开辟了新的途径。在本集中，Darin 和 Viktor 与来自 Embrace 的 Austin Emmons 讨论了向开发人员普及工具价值的必要性，以及 OpenTelemetry 如何显著帮助移动应用程序的性能监控和诊断工作。Austin 的联系方式：领英：https://www.linkedin.com/in/austin-emmons-264ba347/ YouTube 频道：https://youtube.com/devopsparadox 在 Apple Podcasts 上评价播客：https://www.devopsparadox.com/review-podcast/ Slack：https://www.devopsparadox.com/slack/ 联系我们：https://www.devopsparadox.com/contact/</context> <raw_text>0 你们拥有现有的日志、跟踪和指标支柱，但问题就变成了，什么时候是将这些信息上报的最佳时机？当这些数据来自成千上万甚至数百万台设备，而不仅仅是服务器机架上的一小部分服务器时，我们该如何解读这些数据呢？这里是 DevOps Paradox，第 283 集，OpenTelemetry 与移动应用的结合。♪

欢迎收听 DevOps Paradox 播客。这是一个关于各种随机话题的播客，在其中，我和维克多假装我们知道自己在说什么。大多数时候，我们通过在任何可能的地方都加上“DevOps”这个词来掩盖我们的无知，并将其与 Kubernetes、无服务器、CI/CD、团队生产力、快乐岛屿以及其他让我们听起来像知道自己在做什么的花哨表达混在一起。

偶尔，我们会邀请一些确实懂行的人做客，但我们并不经常这样做，因为他们可能会让我们显得无能。真相就在那里，我们不可能找到它。是的，这是达伦在读这段文字，并为维克多让我读它而感到尴尬。以下是你们的两位主持人，达伦·波普和维克多·法森。维克多，我们已经赞扬 OpenTelemetry 了多久了？一年？一年半？是的。

是的。我的意思是，它最终让每个人都统一了标准。这并不是说更好或更坏。更像是成为一个标准。但我们花了所有时间说，好吧，这对 Datadog、New Relic 和 Dynatrace 这些数据狗来说很棒。我在列举它们时尽量不遗漏任何一个。我认为正好相反。

你这么认为？这是我的理论，我无法证明这一点，对吧？Datadog 已经有了它的代理和格式等等，对吧？他们从 OpenTelemetry 中没有获得任何好处。如果有什么不同的话，他们可能会损失，因为他们在之前就已经有了自己的投资和知识产权，对吧？

谁让他们的最终用户受益更多。哦，好吧，所以现在我不需要以某种方式为某个可观察性工具专门编写应用程序，然后再去想为什么我永远无法切换。但我们根本没有讨论过的平台之一是移动平台。在今天的节目中，我们邀请到了来自 Embrace 的 Austin Emmons。Austin，你好吗？我很好，你们好吗？

很好，谢谢。谁能想到你实际上可以用 OpenTelemetry 来处理移动应用？我从未想过。我太困惑了。我甚至无法想象这在移动设备上是如何工作的。我的脑袋可以理解，哦，这些是我的服务器，对吧？我知道东西在哪里运行。我知道如何从这些东西中获取信息。移动设备，这是一个谜。

这绝对是姗姗来迟了。我认为我们在后端已经看到了进展。现在是有人必须尝试的时候了。社区正在努力尝试，这很棒。我们在过去六个月中看到了客户端领域的这种进步。当然，当你谈论客户端时，也会谈到移动领域。

这是如何工作的？我现在在猜测，如果我在这个领域真的不了解，请纠正我。它一定是一种推送类型，对吧？因为你不知道从哪里拉取信息。即使你能做到，你可能也做不到。它是推送的。所以主要的逻辑实际上是导出。数据模型在 OpenTelemetry 中保持不变。你们拥有现有的日志、跟踪和指标支柱。

但问题就变成了，什么时候是将这些信息上报的最佳时机？当这些数据来自成千上万甚至数百万台设备，而不仅仅是服务器机架上的一小部分服务器时，我们该如何解读这些数据呢？数百万台设备。好吧，我已经开始理解移动设备了，但我实际上并没有考虑到数百万台设备。当我还在 2007 年、2008 年做移动开发的时候，有一些分析平台。

我们会实现任何库。再说一次，回到维克多之前所说的，Datadog 有自己的做事方式。New Relic 有自己的做事方式。在移动领域，有一些分析平台也有自己的做事方式。但是现在有了 OpenTelemetry，它应该很简单。我的意思是，对于 Embrace 项目来说，这是一个开源项目。你们只是在处理标准的指标、日志和跟踪吗？你们在做什么？

就是这样。我们之前有专有的数据格式。我们意识到，每次我们添加一种新的遥测类型、一些新的检测时，我们都从零开始，说，好吧，这是如何通过网络传输的？它应该使用什么信封？我们尽可能地优化它。但后来我们意识到，等等。

我们可以把它扔进一个跨度中，测量这段时间，并开始捕获这些数据，将它们组合在一起，并在发送时批量处理它们。或者，如果它是一个时间点，也许我们会决定，好吧，日志更适合于任何东西，我们会把它写成日志。然后，当设备准备好时，我们会发送该日志。这比“当设备准备好时”这个短语要困难一些。这就像找到合适的时机……

避免干扰你正在监控的应用程序，但也尽快向想要查看几乎正在进行的会话的应用程序开发人员提供反馈。是否存在一些超出你们控制范围的限制？我现在在编造，苹果允许吗？iPhone 允许你发送数据，还是你需要绕过一些障碍？这部分是如何工作的？因为你无法控制硬件，对吧？

绝对的。最大的问题是你无法控制硬件。因此，苹果提供的限制有时只是应用程序本身，我们是一个 SDK。因此，如果你是可观察性提供商，你很可能是一个位于 iOS 平台上的应用程序沙箱中的 SDK，并且你……

是该应用程序的一部分，这意味着如果应用程序在后台运行，并且在足够长的时间内没有任何事情发生，系统可能会说，好吧，你完成了。我们只是暂时关闭你的应用程序或让它休眠、暂停，然后在下一次用户进入时再把它带回来。好吧，显然是在用户下次打开应用程序时再把它带回来，但你可能会回到……

一个新的状态，或者你可能会回到一些脏的状态，这取决于你休眠了多久，我想。因此，肯定有一些约束需要解决。有很多恢复工作要做。好吧，我在这个过程中处于什么位置？我是否有尚未上传需要导出并上传到 OTLP 收集器的数据？当我这样做时，确保……

尽可能稳健地进行。因此，如果我需要重试任何操作，如果由于任何原因任何上传失败，绝对……然后只是网络上的物理限制，你住在哪里或你在哪里，这是一个 Wi-Fi 连接吗？你是否必须比开发时批量处理得更小？因为你的开发环境非常干净，它位于 Wi-Fi 上……

也许你正在使用 VPN 或其他东西，并且一切比现实世界中稳定得多。维克多深入探讨了这个问题，试图弄清楚，好吧，如果有人强制关闭会发生什么？对我来说，我没有看过代码，感觉你可能正在写入 SQLite 数据库，然后从该数据库中进行某种事务日志记录，然后你可以确定重发或删除。这听起来对吗？

是的，差不多。SQLite 数据库，然后……

当我们准备好时，我们会确定用户会话很重要，因为这是一个客户端应用程序。因此，我们会将数据批量处理到我们称为用户会话的内容中。我们将其确定为应用程序处于前台或后台时。我们有前台会话和后台会话。因此，在会话结束时，我们将存储在 SQLite 中的原始数据作为跨度记录，并将其推送到更类似于……

blob 的有效负载记录中，然后我们可以缓存该有效负载记录，以便它准备好上传。这就是从设备卸载的提示。所以，如果我今天是一个 iOS 或 Android 开发人员，而且看起来你们也支持 React Native、Flutter 和 Unity。哇，范围很大。我假设这对我来说只是一个库。

我只需要决定要发送什么数据。好吧，不一定是发送。我要“记录”什么数据。然后，根据我调用 SDK 的方式，它在发送回时会是什么样子，无论是日志、指标还是跟踪，对吧？

正确。因此，希望它只是一个依赖项，并且你熟悉使用 Swift 包管理器引入新包，或者如果你想自己从源代码构建它，则引入动态框架。然后，从那里开始，它只是交互，你知道，启用某些功能，也许自定义你想要捕获的内容。

以及你希望哪些检测是自动的。你可能希望你的应用程序的某些部分手动检测，这就是调用实际的日志消息或启动和停止跨度，因为你比我们更了解你的应用程序逻辑。然后你配置一个导出器。OpenTelemetry 的优点是 OTLP 是一种标准协议，已经有许多基础设施支持它。因此，如果你正在运行 Grafana 实例，只需将其插入即可。如果你正在运行 Dynatrace 实例，你知道，你只需插入该收集器的授权，它就可以“正常工作”。但这是最好的部分。

在这个生态系统中，数据可以去任何你想去的地方。如果它就在你的后端数据旁边，并且你希望这些数据与你的后端数据混合，那就随意。如果你想将它们分开，并且想单独查看它们，因为你的团队就是这样构建的，那也取决于你。因此，在你可以导出数据的位置方面，它非常灵活。

数据去哪里？我的意思是，这听起来像个愚蠢的问题，但它是否直接发送到 Datadog、Prometheus 或人们正在使用的任何目标？或者它是否与其他请求一起发送到后端，然后从那里进一步发送？

在我们的 SDK 中，你可以在设备上配置导出器。因此，它直接从设备发送到你已配置导出器的位置。如果你在前面放置一个网关来管理负载，那么你可以这样做。我可以设置多个导出器吗？假设我想发送我的……仅仅因为 UI 在其他供应商那里，或者假设，谢谢你之前提到 Grafana，因为我忘记了它们。

所以假设我想将我的指标发送到 Grafana。我想将我的日志发送到 Datadog，我想将我的跟踪发送到 Dynatrace。我可以这样做吗？是的，绝对可以。目前，我们的 SDK 只处理来自设备的日志和跟踪。我们正在开始探索指标，并希望能够实现。我可以讨论为什么我们把它留到最后。

每个支柱都配置了导出器。因此，日志导出器、跟踪导出器。我最喜欢的是，这是一个接受……你知道，它是一种你实现的一种方法。因此，在底层的 OpenTelemetry SDK 中内置了一种方法，我认为它是多跨度导出器，它为你完成了扇出操作。因此，如果你希望你的跟踪发送到多个位置，你可以配置它。

当我使用后端中的类似内容时，你会将应用程序指标或跟踪（或者你正在做的任何事情，希望所有这些）与硬件结合起来，对吧？然后所有这些都会结合起来。你也可以访问硬件，还是仅仅是应用程序数据？你知道，你是否会得到，哦，这是 iPhone，或者这是三星？哦，是的。是的。

苹果在其对隐私的推动方面做得非常好，真的……

专注于你可以访问的内容，但他们做得非常好，说，我们不希望你能够在应用程序后面识别这个用户。因此，访问设备型号等信息很容易且直接，并且仍然是可以接受的，但访问诸如剩余磁盘空间多少之类的信息……

苹果认为这是一种识别用户的途径。因此，如果你获取剩余磁盘空间（这是一个整数值，但一个非常精确的值）以及 IP 地址或其他一两个特征，那么你就可以开始描绘用户的图像，并开始真正识别，哦，我们可以看到他们在这些应用程序之间移动。这就是苹果真正试图减少的行为。

因为这并不是应用程序监控用户去向的地方。甚至我们作为可观察性供应商，我们真的也不想这样做。因此，我们不会捕获位置，或者系统已经拥有这些非常明确的权限，这很好。但是现在苹果有这个官方的隐私清单……

当你进入应用商店时，它看起来像营养标签。它真的很有帮助，说明我的数据是如何被处理的。而应用程序性能的数据就是我们所属的类别，或者任何可观察性供应商都属于这个类别。如果你正在访问任何硬件信息，你必须明确声明你正在使用的调用。开发人员愿意检测他们的应用程序的程度如何？

我之所以问这个问题，是因为在后端，我们一直在努力，好吧，有一些运维人员，我现在正在概括，对吧？他们观察一切等等。他们在他们的服务器上运行所有代理。他们希望有一天，如果所有星星都对齐，开发人员也会检测应用程序，但这通常不会发生。你在移动领域的经验如何，特别是由于实际上……

除了检测之外，没有其他东西。你无法运行代理，对吧？

当然，有时让人们理解什么是检测以及为什么它有用是令人沮丧的。但这只是教育社区过程的一部分，好吧，这些开发人员……我与之交谈和互动过的许多开发人员都在使用其他事件提供商，也许是 Mixpanel 或任何一个这样的供应商来……

跟踪用户流程并查看成功情况。此用户已登录，此用户已到达结账流程，这是他们进行的非常快速的应用程序级检测。所以他们对此很熟悉。现在是……

将他们习惯于从这些供应商那里获得的内容转换为 OpenTelemetry 概念。好吧，将此标记为日志。在此处将此标记为跨度。你想测量下载此图像并对其进行反序列化的性能。让我们监控它并用跨度将其包装起来。这绝对变得非常困难。当我查看我们自己的后端指标时，我非常嫉妒，因为它只是你可以从……

被击中的端点一直跟踪到数据库以及数据库正在做什么。我认为随着时间的推移，这将会实现，我们希望公开一些这些 API，以允许第三方供应商使用 OpenTelemetry API 将检测添加到他们的库中。但现在还为时过早。因此，仍然有很多手动检测工作要做。你抢走了我的下一个问题。我正要问，有多常见……

进行检测，我不确定如果我经常在后端使用 Go 的话该如何称呼它，嘿，我的意思是，当我添加检测时，最好的结果是我自己做的，但是嘿，我可以使用带有已完成检测的 Web 服务器，这在移动设备中存在吗？或者有多常见？

因此，iOS 的历史是 Objective-C 是主要的选择语言。Objective-C 运行时具有一个漂亮且令人痛苦的功能，称为 swizzling，它是在应用程序运行时更改方法指针的地方。它可能非常危险，但一旦你理解了正在发生的事情，它实际上并不太难。

我们可以使用 swizzling 来挂钩方法以进行一些自动检测。因此，开箱即用，许多可观察性供应商将提供自动检测，但主要是在 Apple 的框架周围。因此，Apple 在提供 URL 会话或核心网络以进行网络请求方面做得非常好。这可能是……

可观察性供应商将检测到的最大事情是应用程序何时发出网络请求。因此，对 URL 会话或每个单独请求的 URL 会话任务进行 swizzling 非常常见。这就是我们如何挂钩并提供一些自动检测的方法。当你没有使用 swizzling 时，系统还会提供一些良好的通知，只是为了说，嘿，我……

处于低功耗模式，你可以从设备查询该模式。在这些设备上的低功耗模式下，很多时候这意味着系统正在限制 CPU，并且它将使用 CPU 上的效率核心而不是最好的核心。或者低内存警告。嘿，系统正在检测到低内存事件。你的应用程序应该尝试弹出一些数据。

或它拥有的某些缓存。因此，它只会触发一个通知，我们可以利用它，至少允许某人看到，哦，在这里触发了一个低内存事件。然后，你知道，也许三步之后，应用程序收到了 SIG kill，并且系统杀死了你的应用程序。

这很可能意味着你的应用程序导致了部分内存增长。然后系统决定，好吧，让我们终止它。这不行。因此，有几种不同的方法可以做到这一点。但是，是的，大多数人都会提供有限的自动检测。然后我们一直在努力添加更多内容，但同时允许扩展 API，以便即使你只想配置……

以不在你的代码中内联的方式在你的应用程序中进行检测，希望也许你可以通过 swizzling 你自己的代码或做一些适合你逻辑中使用的任何设计模式的事情来做到这一点。当人们发现发布版本中存在问题时，他们会怎么做？

在移动领域？我的意思是，我认为这是一个比 Oto 本身更通用的问题。你知道，如果是服务器，好吧，我们搞砸了，这正在疯狂泄漏，让我们应用一个新版本。我想移动设备的工作方式并非如此，对吧？希望你看到它。希望你理解，希望你在用户看到之前看到它。我认为应用商店评论不是一件好事，因为这有点太晚了。

如果你看到它，那么你就会开始优先考虑，好吧，这个问题有多普遍？是 100% 的用户吗？是 3% 使用了六个月或更长时间的用户吗？无论是什么，希望能够利用数据来真正了解中断的规模。然后是修复它，诊断它，无论这需要多长时间。希望它是计划好的，你可以发布一个热修复程序，并且你公司的发布流程是计划好的。

经过验证的。你可以在希望在一两天内做到这一点。然后不幸的是，你可能需要向 Apple 提交一个版本，并且有应用商店审核流程。Android 有一个自动审核流程，需要一些时间，你必须等待他们验证和认证应用程序是否已准备好进入应用商店。这个过程的时间已经缩短了。他们在使这个过程尽可能短方面做得非常好，但是，

等待真是令人痛苦，好吧，这会是一天吗？这会是……

两分钟。让我刷新一下。我不知道我是否应该去喝杯咖啡，或者我是否需要在这里一秒一秒地观看这件事。一旦它获得批准，它很可能就可以自动提交到商店了。然后它必须通过应用商店推出，这些用户必须希望更新。很多时候系统会自动更新这些应用程序，这正变得越来越普遍。但是

但在早期，用户必须手动进入并说，我需要更新此应用程序。如果他们没有受到影响，或者如果他们没有意识到他们受到了影响，那么他们可能需要一周左右的时间才能真正进入应用商店进行更新，并意识到有更新可用。所以，是的，这是一个过程。再说一次，我非常嫉妒我的服务器同事，他们可以说部署，它就修复了，因为它是……

我们将事物发布到野外。一旦它发布，它就会拥有自己的生命，你必须做好准备。这就像看着你的孩子去上学。我还没到那一步，但他们可以做任何他们想做的事情，或者它会按照它想要的方式行事，你只能希望你已经为它成功做好了准备。我猜想，如果我寻找一些统计数据，由于整个过程很大程度上不受你的控制，那么移动应用程序的发布频率一定更高。

低于后端，对吧？因为我不必太担心后端，对吧？因为是的，我应该拥有无错误、零漏洞的版本，但是嘿，如果我搞砸了，我可以在两分钟内重新运行。根据我的理解，对于移动设备来说，你没有这种奢侈，对吧？不，绝对没有。CI/CD 流程并非不存在。它已经走了很长一段路，GitHub Actions 非常棒……

现在有很多供应商允许你使用 macOS 运行器进行构建。因此，当你推送可能已构建并准备就绪的新候选版本，甚至提交到 TestFlight 以便你的测试用户可以尽快访问它时，这会有很大帮助。但是仍然有一个过程。对于我们这些 SDK 开发人员来说，这个过程会延长一点，因为我们发布了一个版本，然后我们必须等待。希望我们没有造成任何问题，但它可能会发生。

我们必须等待使用我们的应用程序来采用新的源代码，然后经历发布过程。因此，对于这些修复来说，这是一个漫长的流程，才能完全完成并让你放心，确保你理解这一点。

预先了解中断的限制、中断的普遍程度以及错误的严重程度非常重要，这可能就是我进入可观察性领域的原因，并且理解，我一直喜欢能够解决软件问题，我认为这是一个解决问题的非常好的方法，现在观察问题发生的时间让我在解决这些问题时有了先机，所以你……

推出部分掌握在 Apple、Google 或其他公司手中，对吧？有没有什么方法可以……我现在完全偏离主题了，但这实际上仍然与可观察性相关。有没有什么方法可以进行某种金丝雀部署，并说，我将把它推出给 5% 的 Apple 用户，iPhone……

有可能吗？我的意思是，如果可能的话，这是可能的，因为 Apple 允许这样做，对吧？是的。是的，我相信是这样。我知道在 Android 上，这更常见。当我过去在担任 Android 应用程序开发人员时，我熟悉他们的 Google Play 工作流程。这非常有用。我不记得当时 Apple 是否有这个功能。

但我相信自从他们五六年前提购 TestFlight 以来，我相信他们已经引入了这个流程来允许这些金丝雀部署。因为对我来说，这听起来很棒，特别是由于发布时间更长，就像 FOTL 和遥测的惊人用法，等等，对吧？嘿，我正在获取我的信息，我可以决定继续推出，对吧？是的，绝对可以。你之前说过，

你今天有日志和跟踪，你等到指标成为第三个。你说，我们稍后再谈。我认为现在是时候了。当然。为什么指标是最后？对我来说，我可以看到日志总是排在第一位。这很简单。不，在 Hotel 中，它是最后。日志是最后。哦，我知道。但在正常生活中，不是在 Hotel 中。是的，在正常生活中，你首先获得日志，可能是指标，然后是跟踪，因为跟踪很难。好吧，是的。

在 Hotel 之前。为什么你把指标放在最后？对我们来说，主要是因为很难将该指标与可比较且可操作的内容联系起来。我喜欢的一个用例，我们真正想要进入并开始使用的用例只是内存使用情况。在 Xcode 中，当你正在开发时，当你连接到本地调试器时，它会告诉你使用了多少应用程序内存。如果你连接仪器，那么你可以将其分解到每个分配中。

但这对于部署到野外的应用程序来说有点过于繁重了。但是……

困难的是，如果我在我的设备上（这是一部 iPhone 15），并且我使用了 20 MB 的应用程序内存，如果我在不同的会话中切换到不同的设备，那么该设备在时间方面可能运行得一样好，但由于某种原因，它可能使用了 30 MB 的应用程序内存。因此，很难将它进行比较并将其固定到……

应用程序开发人员可以采取行动的东西，但这确实是有用的信息。因此，我们正在努力弄清楚如何才能以最佳方式显示这些信息，使其围绕用户会话以及用户在应用程序中执行的操作为中心。而且它也有意义。我可以看到，哦，当用户进入此视图时，应用程序内存就会激增，我可以做些什么。

那是我们一直搁置下来，目前正在积极开发的东西。所以我们真的很高兴能把它发布出来，让大家使用，但这也就是我们为什么最后才做它的原因。主要是因为有三件事你必须，你确实必须选择一个顺序。对我们来说，日志是一个时间点。好的。这似乎是最基本、最简单的项目，跟踪现在是两个时间点，一个开始和一个结束。好的。然后是树状结构，但这并不太难。

但这似乎是一个不错的第二种情况。现在指标是，你知道，在一段时间内，在一个间隔内，我们会进行某些测量，然后我们会弄清楚这意味着什么。所以这就是我们把它放在第三位的原因。从观察者的角度来看，这听起来像是要得出结论的一件非常复杂的事情，对吧？因为如果我回到服务示例，对吧？

如果我的应用程序使用了更多内存，因为有更多可用内存，所以我可以让它运行，对吧？但是当服务器上的东西开始燃烧时，我就不想要它了，诸如此类。我想在移动设备上，你真的不知道移动设备上还会发生什么，对吧？是的，没错。

因为其他应用程序正在运行并且系统正在对其进行限制，或者由于其他原因，我的内存使用量太少了吗，等等？

是的，没错。系统可能对 CPU 或设备进行的限制，也可能与系统上发生的其它事情有关。然后，我获得内存事件的时机是另一个指标。好的。可能存在内存问题。所以，是的，我们真的很高兴开始进行这项工作。这绝对是被多次请求的，因为我认为如果做得正确，它将非常有用。现在我们只需要弄清楚我们如何才能正确地做到这一点？是的。

我刚刚查看了 iOS SDK，它看起来你发布它的频率相当高。我没有查看其他的。对于使用你的 SDK 的开发者来说。所以如果我还在编写 iOS，如果我使用 Embrace，我看到它每五天、十天发布一次，具体情况如何。你认为 Embrace 如何？你的开发者实际上手这些新版本的速度有多快？

我认为变化很大。我们有一些早期采用者正在从源代码构建并通过 GitHub 问题或他们自己的拉取请求向我们反馈，这太棒了。然后我们有一些大型组织，它们像大型组织一样运作。这是一个缓慢、稳定、日复一日的改进过程，当你拥有……

一个如此规模的组织，而你的应用程序对如此多的用户如此重要时，这是完全合理的。所以变化很大，我们对 6.X 系列非常兴奋。你正在查看的 Embrace Apple SDK 现在是开源的，并采用了现代化的 Swift 设计模式，对我们来说是一个全新的项目，基于 OpenTelemetry。我们，我们有，呃，

两个主要的依赖项，OpenTelemetry SDK，然后另一个我要提到的依赖项是 GRDB，这是一个非常好的 Swift 包装器，围绕 SQLite 以及我们如何进行存储或本地存储。这是一个稳定的改进，我们希望人们能够接受并尝试它。所以，如果你正在收听，一定要查看一下，并告诉我们哪里错了。告诉我们哪里对了。我们喜欢反馈。

如果有人今天开始使用它，你会推荐什么？源代码还是直接获取库？当然是源代码。我认为 SPM，Swift Package Manager，是 Apple 或 Swift 语言的新包管理系统。它已经取代了一些以前可用的包管理器，例如 CocoaPods 或 Carthage。它非常容易使用，并且集成到 Xcode 中，可以轻松上手并查看。你可以逐步浏览源代码。你可以确切地看到它的底层工作原理。

你可以提供非常好的反馈。或者，如果你愿意，你可以分叉它并进行更改。如果你想自己保留这些更改，请随意。我希望你能帮助我们。我非常反对那样做。是的。或者只是看看我们是如何实现某些事情的。也许当你正在处理我们尚未完成的一些自动检测时，你可能想看看我们已经完成的一些自动检测是如何完成的，然后对……

你编写的类进行建模，以匹配我们的类或与我们的类很好地配合。但我们希望，如果你了解 OpenTelemetry 追踪器是什么，你就可以开始使用追踪并创建追踪某些内容的检测。然后，如果你熟悉 OpenTelemetry 日志，你就可以开始使用记录器并创建写入日志的检测。你看到人们使用什么后端？

他们使用自己的后端吗？他们使用服务吗？你甚至知道吗？我不知道。开箱即用，你可以连接到我们的后端，并且有一个免费试用阶段等等。我认为对我们来说，当我们测试时，我们使用了 Grafana，因为熟悉，但是 OTLP 导出器……

我们在文档中的一些示例中使用它，它来自底层的 OpenTelemetry SDK。所以这不是我们编写的。这是直接来自消息来源的 OTLP 导出器。如果你想导出到支持 OTLP 协议的任何地方，这会有所帮助。当你拉取最新的 OTL 库供你使用时，它在你身上崩溃过多少次？

我们还没有这样做，但这是计划中的。我们确实需要进行升级。我也参与 OpenTelemetry SIG 的工作，所以我本人也对 Swift 包做了一些贡献，我们团队的成员也一样。所以我们很快就会升级。但大部分原因是因为它是标准的，并且因为我们参与了 SIG，我们

看到了所做的更改。我可以告诉你，我们没有升级，因为我们必须进行数据库迁移。我们只是推迟一下，以确保我们选择正确的版本进行升级，这样当这种情况发生时，我们就不需要进行多次数据库迁移。这又是你在野外遇到麻烦的另一件事。这不是你控制的数据库。它在某人的设备上。你积极参与酒店 SIG 有多重要？

哦，这非常重要。仅仅对我来说，在我对 Open Hotel 的理解中，仅仅是为了有一个途径来提问，我每周二参加客户端 SIG，每周四参加 Swift SIG，我们讨论不同的东西。客户端 SIG 涵盖 Android、iOS 和浏览器 JavaScript 内容，而 Swift SIG 只是针对 OpenTelemetry Swift 项目本身。这很棒，因为所做的贡献

以及在客户端 SIG 中提出的语义约定提案，其中许多都适用于移动设备，并且其中许多都是 Embrace 提出的。我的同事 Hanson 是……

是的。

我们必须遵循语义约定。否则，它就会破坏整个想法。目的是让网络跨度看起来像网络跨度。如果我将其发送到 Grafana 或其他供应商，它将被摄取并作为网络跨度读取。因此，限制供应商锁定也是我们的主要目标之一。我们只有参与社区才能做到这一点。所以我听到的是，如果你

不参与社区，你只是自己做自己的事情，我们仍然会有另一个老式的 Datadog 场景，那就是我们的库在这里，去使用我们的库。这是你唯一可以使用它的方式，对吧？是的，我想我从未使用过 Datadog。好吧，填空。它可以是任何人，对吧？我的意思是，如果你有一个完全专有的示例，并且你没有走 OTEL 的道路，并且没有真正进入 OTEL SIG 来真正了解社区正在做什么，

Embrace 在这个时候甚至会存在吗？我不知道。对。我的意思是，这将是艰难的。是的。五年前。答案是肯定的。对。但是今天，不是真的。是的。不，这个社区正在围绕移动设备构建，并且在过去六个月中，我们参加了这些会议，六到八个月，我们看到了它们的增长，以及越来越多的贡献和越来越多的参与，这真是太棒了。

即使我们从 OpenTelemetry 开始，并且我们没有参与，你也会自然地走自己的路，你会自然地偏离。参加这些会议并跟上社区已经决定的这些语义约定，这意味着我们可以限制这种差异，并尽可能地保持一致。对我来说有趣的是，你完全专注于移动设备。当你每周二和周四出现时，SIG 中有多少人？

客户端 SIG 每周大约有 8 到 12 人。每周都有一些核心贡献者在那里，并主持会议。然后人们根据自己的时间安排来来往往。Swift SIG，我认为我们中有四五个人

每周都在那里，这是一个更一致的四五个人，我们有几个人突然出现并提出问题，或者有一个 cncf 的 Slack 社区，OpenTelemetry 在其中有频道，因此 OpenTelemetry Swift 频道可用于提问。

很多时候，对话可能始于一个问题或拉取请求或 Slack，然后我们会问某人，哦，你能参加这个会议亲自与我们讨论一下吗，这样我们就可以，你知道，面对面的时间。这是无与伦比的，我们没有这种传话游戏。这里有一小撮人，那里有一小撮人。但是，如果那里有人在听，请加入。即使你加入只是旁听，它也很有价值。我觉得它很有价值。

如果你在会议期间有任何贡献或任何想法，很容易就能取消静音并开始说话。这是一个非常友好的环境。不要担心觉得自己不属于那里或其他什么。每个人都非常友好和善良。所以 Austin 为 Embrace 工作。我们已经讨论过了，embrace.io。显然，Embrace 发布了可以使用的 SDK。但是 Embrace 还做什么？

Embrace 是一个基于 OpenTelemetry 的移动应用程序可观察性平台。因此，我们的 SDK 是开源的。从它们那里，你可以导出到任何与 OTEL 兼容的工具。我们试图尽可能无缝地与这些供应商集成，以便你的数据可以位于你想要的位置。如果你是一个 DevOps 人员，

一个 SRE 监控服务器，并且你有一个移动团队，而这对你来说是一个黑盒，你不知道移动领域发生了什么，你可以使用像我们这样的工具来开始观察一些应用程序性能，并开始监控它在野外的运行情况。

我们有一个几周前才开始的 Slack 社区，人们可以在那里开始讨论 OpenTelemetry 以及我们做什么以及我们如何与之交互。或者你可以加入 CNCF Slack 社区并在那里与我交谈，并联系任何 SIG。每个 SIG 都有自己的 Slack 频道，这是一个开始对话的绝佳机会。这主要是 Embrace 所做的。是的。

当 Austin 说 SDK 是开源的时候，它确实是开源的，是一个 Apache 2.0 许可的开源。所以 Austin 的所有联系信息都将在剧集描述中。再次声明，Embrace 位于 embrace.io。Austin，感谢你今天与我们在一起。感谢你们的邀请。我们希望本集对您有所帮助。

如果你想讨论它或提出问题，请联系我们。我们的联系信息和 Slack 工作区的链接位于 devopsparadox.com/contact。如果你通过 Apple Podcasts 订阅，请务必在那里留下你的评论。这有助于其他人发现这个播客。现在就注册 devopsparadox.com，以便在我们发布最新剧集时收到电子邮件。感谢收听 DevOps Paradox。

♪