作者：来自 Elastic Akhilesh Pokhariyal, Cesar Munoz, Bryce Buchanan
实用于本机应用步调的 Elastic APM 提供传出 HTTP 哀求和视图加载的主动检测，捕获自定义事件、错误和瓦解，并包罗用于数据分析和故障排除目标的预构建仪表板。
实用于 iOS 和 Android 本机应用步调的 Elastic® APM 在堆栈版本 v8.12 中正式发布。 Elastic iOS 和 Android APM 代理是开源的，并且是在顶部开发的，即分别作为 OpenTelemetry Swift 和 Android SDK/API 的发行版。
移动 APM 解决方案概述
实用于 iOS 和 Android 的 OpenTelemetry SDK/API 支持主动检测 HTTP 哀求、手动检测 API、基于 OpenTelemetry 语义约定的数据模型以及缓冲支持等功能。 别的，Elastic APM 代理发行版还支持更简单的初始化过程和新奇的功能，例如长途设置和基于用户会话的采样。 Elastic iOS 和 Android APM 代理的发行版是根据 Elastic 的标准支持条款和条件进行维护的。
Kibana® 中提供了精选或预构建的仪表板，用于监控、数据分析和故障排除。 下面表现的 Sevice Overview 视图提供了相关的前端 KPI，例如瓦解率、http 哀求、平均应用步调加载时间等，包罗比力视图。
别的，用户流量的地理分布可在国家和地区级别的地图上得到。 服务概览仪表板还表现吞吐量、耽误、交易失败率以及按设备型号、网络毗连范例和应用步调版本分别的流量分布等指标趋势。
下面表现的事件视图突出表现了差别事件组的性能，包罗各个 transaction 的端到端分布式跟踪以及关联跨度、错误和瓦解的链接。 别的，用户可以一目了然地看到按设备品牌和型号、应用步调版本和操作体系版本分别的流量分布情况。
表格视图（例如下面突出表现的位于 “transactions” 选项卡底部的表格视图）可以相对轻松地查看设备制造商和型号、应用步调版本等如何影响耽误和瓦解率。
下面表现的 Errors & Crashes 视图可用于分析差别的错误和瓦解组。 此视图中还提供了单个错误或瓦解实例的未符号化 (iOS) 或模糊化 (Android) 堆栈跟踪。
下面表现的 Service Map 视图提供了端到端服务相互依靠关系的可视化，包罗任何第三方 API、代理服务器和数据库。
用于观察 Kibana 中的移动前端的全面预构建仪表板提供了对错误、瓦解和瓶颈来源的可见性，从而简化了生产环境中问题的故障排除。 底层 Elasticsearch® 平台还支持查询原始数据、构建自定义指标和自定义仪表板、警报、SLO 和异常检测的功能。 总而言之，该平台提供了一套全面的工具来加快根本原因分析和修复，从而促进高速创新。
一些错误场景的调试工作流程演练
接下来，我们将演练 iOS 和 Android 本机应用步调中的几个错误场景的设置详细信息和故障排除工作流程。
场景1
在此示例中，我们将使用 Apple 的瓦解报告 symbolication以 及 breadcrumbs 来调试异步方法中的瓦解，以推断瓦解的原因。
Symbolication
在这种情况下，用户留意到 “Errors & Crashes” 选项卡中特定瓦解组的瓦解发生次数激增，并决定进一步调查。 “Crashes” 选项卡上出现新的瓦解，开发人员按照以下步骤在本地表现瓦解报告。
1. 通过 UI 复制瓦解并将其粘贴到具有以下名称格式 ， 例如，<AppBinaryName>_<DateTime>. For example, “opbeans-swift_2024-01-18-114211.ips。
2. Apple 提供了有关如何通过 Xcode 主动或使用下令行手动在本地符号化此文件的详细说明。
Breadcrumbs
第一个线程的第二帧表现瓦解发生在 Worker 实例中。
这个实例实际上在很多地方都有使用，并且由于这个函数的异步特性，不大概立刻确定这个调用来自哪里。 尽管云云，我们可以使用开放遥测 SDK 的功能为这些瓦解添加更多上下文，然后将各个部分组合在一起以找到瓦解的位置。
通过在该 Worker 实例四周添加 “breadcrumbs”，可以追踪哪些对 Worker 的调用实际上与此次瓦解相关。
例子：
在 Worker 类中创建一个 loggerprovider 作为公共变量以便于访问，如下所示：
在调用 Worker.doWork() 函数的地方创建 breadcrumbs：
每个 breadcrumbs 都将使用相同的事件 name “worker_breadcrumb”，以便可以一致地查询它们，并且将使用 “source” 属性来完成区分。
在此示例中，Worker.doWork() 函数是从 CustomerRow 布局（执行 “onTapGesture” 的表行）调用的。 假如你要从 CustomerRow 布局中的多个位置调用此方法，你还可以向 “source” 属性值添加其他区别，例如关联函数（例如 “CustomerRow#onTapGesture”）。
现在应用步调正在报告这些 breadcrumbs，我们可以使用 Discover 来 query 它们，如下所示：
留意：代理发送的事件 names 将转换为 Elastic 通用架构 (ECS) 中的事件操作，因此请确保查询使用此字段。
- 你可以添加一个过滤器：`event.action: “worker_breadcrumb”`，它会表现从这个新 breadcrumb 生成的所有事件。
- 你还可以查看各种来源：ProductRow、CustomerRow、CartRow 等。
- 假如将 error.type: crash 添加到查询中，你可以在 breadcrumbs 旁边看到瓦解：
时间线中彼此相邻的瓦解和 breadcrumb 大概来自完全差别的设备，因此我们须要另一个区分器。 对于每次瓦解，我们都有包含与瓦解关联的 session.id 的元数据，可以从 “Metadata” 选项卡查看。 我们可以使用此 session.id 进行查询，以确保我们在 Discover 中查看的唯一数据来自导致瓦解的单个用户会话（即单个设备）。
在 Discover 中，我们现在可以通过 breadcrumbs 在单个设备上查看有关瓦解的会话事件流，如下所示：
场景 2
留意：此场景须要 Elastic Android 代理版本 “0.14.0” 或更高版本。
Android 示例应用步调有一个由两个屏幕组成的表单，这两个屏幕是使用两个片段（“FirstPage” 和 “SecondPage”）创建的。 在第一个屏幕中，应用步调进行后端 API 调用以获取标识表单提交的密钥。 该密钥存储在应用步调的内存中，并且必须在发送表单的最后一个屏幕上可用； 密钥必须与表单数据一起发送。
问题
当用户单击 “FINISH” 按钮时，我们开始在 “Errors & Crashes” 选项卡中看到 Kibana 中的瓦解发生率激增（空指针异常），这些瓦解似乎总是发生在表单的最后一个屏幕上。 然而，这并不总是可重现的，因此仅通过查看瓦解的堆栈跟踪并不清楚根本原因。 它看起来是如许的：
当我们查看堆栈跟踪中引用的代码时，我们可以看到以下内容：
这是发生瓦解的行，因此在执行此代码时，变量 “formId”（位于 “FirstPage” 中的静态字符串）似乎为空，导致引发空指针异常。 后端哀求完成以检索 id 后，此变量在 “FirstPage” 片段中设置。 到达 “SecondPage” 的唯一方法是穿过 “FirstPage”。 因此，单独的堆栈跟踪并没有多大帮助，因为页面必须按顺序打开，并且第一个页面始终会设置 “formId” 变量。 因此，“SecondPage” 中的 formId 似乎不太大概为空。
探求根本原因
除了查看瓦解的堆栈跟踪之外，查看补充数据也很有用，这些数据有助于将各个部分组合在一起，并更全面地了解瓦解发生时我们的应用步调运行时发生的其他事情。 对于这种情况，我们知道表单 ID 必须来自我们的后端服务，因此我们可以首先排除后端调用存在错误。 我们通过在事件详细信息视图中检查执行表单 ID 哀求的 FirstPage 片段创建过程中的跟踪来完成此操作：
"Created” span 表现创建第一个片段所耗费的时间。 最上面的表现了 Activity 创建，然后是 NavHostFragment，最后是 “FirstScreen”。 创建后不久，我们看到向后端发出了 GET HTTP 哀求来检索表单 ID，并且根据跟踪，GET 哀求成功。 因此，我们可以排除该问题是后端通讯存在问题。
另一种选择大概是查看发生瓦解的应用步调中整个会话期间发送的日志（我们也可以查看来自我们应用步调的所有日志，但它们太多，无法分析这一问题）。 为此，我们首先复制一个跨度的 “session.id” 值（任何 span 都可以工作，因为在瓦解发生期间从我们的应用步调发送的所有数据中都可以使用相同的会话 ID） 在跨度详细信息弹出窗口中。
留意：在瓦解元数据中也可以找到相同的会话 ID。
现在我们已经确定了会话，我们可以打开日志资源管理器视图并查看同一会话中应用步调的所有日志，如下所示：
通过查看日志并添加一些字段来表现应用步调的生命周期状态和错误范例，我们可以看到从应用步调主动收集的日志事件。 我们可以看到列表顶部的瓦解事件是最新的。 我们还可以看到应用步调的生命周期事件，假如继承滚动，我们将看到一些生命周期事件，这些事件将有助于找到根本原因：
我们可以看到有几个生命周期事件告诉我们应用步调在会话期间重新启动。 这是一个重要的提示，因为它意味着 Android 操作体系在某个时刻杀死了我们的应用步调，当应用步调在背景停留一段时间时，这种情况很常见。 有了这些信息，我们可以尝试通过强制操作体系在背景终止我们的应用步调来重现该问题，然后查看它从迩来打开的应用步调菜单重新打开时的行为。
尝试后，我们可以重现该问题，我们发现应用步调重新启动时静态 “formId” 变量丢失，导致当 SecondPage 片段哀求它时它为空。 我们现在可以研究将参数通报给片段的最佳实践，如许我们就可以更改代码以防止依靠静态字段，而是在屏幕之间存储和共享值，从而防止再次发生这种瓦解。
额外的好处：对于这个场景，我们依靠 APM 代理主动发送的事件就足够了； 但是，假如这些对于其他情况还不够，我们始终可以通过 OpenTelemetry 事件 API 在想要跟踪应用步调状态更改的位置发送自定义事件，如下面的代码片段所示：
充实使用你的 Elastic APM 体验
在这篇文章中，我们回首了 Elastic 8.12 中提供的新移动 APM 解决方案。 新解决方案使用 Elastic 的新 iOS 和 Android APM 代理，这些代理是开源的，并且是在顶部开发的，即分别作为 OpenTelemetry Swift 和 Android SDK/API 的发行版。
我们还检察了 iOS 和 Android 本机应用步调中两种错误场景的设置详细信息和故障排除工作流程。
- iOS 场景：使用 Apple 的瓦解报告符号和面包屑来调试异步方法中的瓦解，以推断瓦解的原因。
- Android 场景：分析为什么用户点击表单的 “FINISH” 按钮时，最后一屏出现空指针异常。 通过查看瓦解的堆栈跟踪来分析这一点并不总是很清楚，而且不容易重现。
在这两种情况下，我们都使用移动设备的分布式跟踪以及相关日志找到了瓦解的根本原因。 希望本博客回首了 Elastic 如何帮助管理和监控移动本机应用步调。
Elastic 约请 SRE 和开发人员亲身体验我们的移动 APM 解决方案，并开启他们数据任务的新视野。 本日就尝试一下 https://ela.st/free-Trial。
原文：Elastic APM for iOS and Android Native apps | Elastic Blog
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
