如何使用监视和故障排除实现 IoT Edge 可观测性
适用于：
IoT Edge 1.5 IoT Edge 1.4
重要
IoT Edge 1.5 LTS 和 IoT Edge 1.4 LTS 是受支持的版本。 IoT Edge 1.4 LTS 的生命周期结束日期为 2024 年 11 月 12 日。 如果你使用的是较低的版本，请参阅更新 IoT Edge。
在本文中，你将了解实现两种可观测性维度（测量和监视以及故障排除）的概念和技术。 你将了解以下主题：
- 定义要监视的服务性能指标
- 使用各种指标测量服务性能指标
- 监视这些指标并检测 Azure Monitor 工作簿的问题
- 使用精选工作簿执行基本故障排除
- 使用分布式跟踪和关联日志执行进一步的故障排除
- （可选）将示例方案部署到 Azure 以重现所学内容
场景
为了使描述不再抽象，我们将通过真实场景，将传感器上显示的海洋表面温度收集到 Azure IoT。
La Niña
La Niña 服务测量太平洋表面温度，以预测会出现拉尼娜现象的冬季。 海洋中有许多带 IoT Edge 设备的浮标，这些设备会将表面温度发送到 Azure 云。 温度的遥测数据先由 IoT Edge 设备上的自定义模块进行预处理，然后再发送到云。 在云中，数据由后端 Azure Functions 处理并保存到 Azure Blob 存储。 服务的客户端（ML 推理工作流、决策系统、各种 UI 等）可以从 Azure Blob 存储中获取带有温度数据的消息。
测量和监视
让我们构建一个测量和监视解决方案，使 La Niña 服务专注于其业务价值。
我们测量和监视的内容
要了解要监视的内容，必须先了解该服务的实际作用以及服务客户对系统有何期待。 在此场景中，一位使用 La Niña 服务的普通用户的期望可以按以下因素进行分类：
- 覆盖率。 数据来自大多数已安装的浮标
- 时效性。 浮标传来的是最新相关数据
- 吞吐量。 浮标传递的温度数据不会出现重大延迟
- 正确性。 信息丢失（错误）的比例很小
满足以上因素意味着服务按客户预期工作。
下一步是定义用于测量上述因素值的设备。 此任务可以通过以下服务级别指标 (SLI) 完成：
| 服务级别指标 | 因素 |
|---|---|
| 联机设备与总设备的比率 | 覆盖范围 |
| 频繁进行报告的设备数与进行报告的设备数的比率 | 时效性、吞吐量 |
| 成功传递消息的设备数与总设备数的比率 | 正确性 |
| 快速传送消息的设备数与总设备数的比率 | 吞吐量 |
完成上述工作后，我们就可以针对每个指标应用滑动量表，并定义准确的阈值，以表示客户“满意”程度。 对于这种情况，我们会选择下表中列出的具有正式服务级别目标 (SLO) 的样本阈值：
| 服务级别目标 | 因素 |
|---|---|
| 90% 的设备在观察间隔内报告指标的时间不超过 10 分钟（联机） | 覆盖范围 |
| 95% 的联机设备在观察间隔内每分钟发送 10 次温度数据 | 时效性、吞吐量 |
| 99% 的联机设备在观察间隔内成功传递消息，且错误率低于 5% | 正确性 |
| 95% 的联机设备在观察间隔的 50 毫秒内传递 90% 的消息 | 吞吐量 |
SLO 定义还必须描述测量指标值的方法：
- 观察间隔：24 小时。 过去 24 小时内的 SLO 报表都是真实可信的。 这意味着，如果 SLI 出现故障并破坏了相应的 SLO，则需要在 SLI 完成修复的 24 小时后，SLO 才能再次正常工作。
- 测量频率：5 分钟。 每隔 5 分钟进行一次测量以评估 SLI 值。
- 测量内容：IoT 设备与云之间的交互，温度数据的进一步使用不在测量范围之内。
测量方式
此刻，我们已经很清楚要测量的内容以及要使用什么阈值来确定服务是否按照预期运行。
借助“指标”来测量服务水平指标是一种常见做法（如我们定义的上述指标）。 我们通常认为此类可观测性数据的值相对较小。 这类数据由各种系统组件生成，并收集在中央可观测性后端中，以便通过仪表板、工作簿和警报进行监视。
我们将阐明 La Niña 服务包含的组件：
使用 Temperature Sensor 自定义模块 (C#) 的 IoT Edge 设备将生成一些温度值，并将其与遥测消息一起发送到上游。 消息将会路由到另一个自定义模块 Filter (C#)。 模块会根据阈值窗口（0-100 摄氏度）检查接收到的温度数据。 如果温度在阈值范围内，FilterModule 会将遥测消息发送到云。
在云中，消息由后端处理。 后端由两个 Azure Functions 和存储帐户组成。 Azure .NET 函数从 IoT 中心事件终结点中选取遥测消息，对其进行处理，然后将其发送到 Azure Java 函数。 Java 函数将消息保存到存储帐户 Blob 容器。
IoT 中心设备附带系统模块 edgeHub 和 edgeAgent。 这些模块通过 Prometheus 终结点公开内置指标列表。 这些指标由 IoT Edge 设备上运行的指标收集器模块进行收集，然后推送到 Azure Monitor Log Analytics 服务。 除系统模块之外，Temperature Sensor 和 Filter 模块也可以使用一些特定于业务的指标进行检测。 但我们定义的服务级别指标只能使用内置指标进行测量。 因此，目前我们不需要实现任何其他内容。
在此场景中，我们有 10 个浮标。 其中一个浮标是故意设置为发生故障的，以便我们可以演示问题检测和后续故障排除。
监视方式
我们将使用 Azure Monitor 工作簿监视服务级别目标 (SLO) 和相应的服务级别指标 (SLI)。 部署此方案包括将 La Nina SLO/SLI 工作簿分配给 IoT 中心。
为了获得最佳用户体验，工作簿的设计遵循“概览”->“扫描”->“提交”概念>>：
概览
在此层级，我们可概览总体情况。 对数据进行了粗略的聚合和展示：
从上图中我们可以看到，服务没有按照预期运行。 数据时效性 SLO 存在冲突。 只有 90% 的设备频繁发送数据，但服务客户期望达到 95%。
通过工作簿设置选项卡可配置所有 SLO 和阈值：
扫描
通过单击发生冲突的 SLO，我们可以进一步前往“扫描”层级，查看设备是如何聚合 SLI 值。
其中一个设备（共 10 个）“很少”发送遥测数据到云。 我们的 SLO 定义中指明了“频繁”是指每分钟至少发送 10 次。 此设备的发送频率远远低于该阈值。
提交
通过单击有问题的设备，可以进一步前往“提交”层级。 此层级是 IoT 中心监视产品/服务随附的一份现成“设备详细信息”精选工作簿。 La Nina SLO/SLI 工作簿对其进行重复使用，以提供特定设备性能的详细信息。
故障排除
通过测量和监视，我们可以观察和预测系统行为，将其与定义的预期行为进行比较，并最终检测现有或潜在的问题。 而通过故障排除，我们可以确定并找到问题的原因。
基本故障排除
提交级别工作簿提供了有关设备运行状况的大量详细信息。 其中包括模块和设备级别的资源使用情况、消息延迟、频率、QLen 等。在许多情况下，这些信息可帮助找出问题的根源。
在此场景中，故障设备的所有参数看起来都很正常，我们并不清楚设备发送消息的频率低于预期的原因。 设备级别工作簿的“消息”选项卡也证实了这一事实：
Temperature Sensor (tempSensor) 模块生成了 120 条遥测消息，但其中只有 49 条流向上游云。
我们要做的第一步是检查 Filter 模块生成的日志。 选择“实时故障排除!”，然后选择 Filter 模块。
分析模块日志未发现该问题。 模块收到消息，没有错误。 从这里看，一切良好。
深度故障排除
两种可观测性工具可用于深度故障排除：“跟踪”和“日志”。 在此场景中，跟踪显示携带海洋表面温度的遥测消息如何从传感器传输到云中的存储、调用了什么内容以及使用了什么参数。 日志则提供有关在此过程中每个系统组件内部发生的情况的信息。 结合使用“跟踪”和“日志”可以实现更强大的功能。 这样便可在处理特定遥测消息时，读取特定系统组件的日志，例如 IoT 设备上的模块或后端函数。
La Niña 服务使用 OpenTelemetry 在 Azure Monitor 中生成和收集跟踪和日志。
IoT Edge 模块 Temperature Sensor 和 Filter 通过 OTLP（OpenTelemetry 协议）将日志和跟踪数据导出到在同一边缘设备上运行的 OpenTelemetryCollector 模块。 OpenTelemetryCollector 模块反过来将日志和跟踪导出到 Azure Monitor Application Insights 服务。
Azure .NET 函数使用 Azure Monitor Open Telemetry 直接导出程序将跟踪数据发送到 Application Insights。 它还使用配置的 ILogger 实例将相关日志直接发送到 Application Insights。
Java 后端函数使用 OpenTelemetry 自动检测 Java 代理来生成跟踪数据和关联日志，并将其导出到 Application Insights 实例。
默认情况下，会对 La Niña 服务设备上的 IoT Edge 模块进行配置，使其不会生成任何跟踪数据，且其日志记录级别会设置为 Information。 生成的跟踪数据量由基于比率的采样器进行调节。 采样器会根据要跟踪的给定活动的所需概率进行配置。 默认情况下，概率设置为 0。 设置好之后，如果没有请求，设备不会向 Azure Monitor 事无巨细地发送所有可观测性数据。
我们分析了 Information 模块的 Filter 级别日志，意识到我们需要更深入地寻找问题的原因。 我们将更新 Temperature Sensor 和 Filter 模块孪生中的属性，并将 loggingLevel 上升为 Debug 并将 traceSampleRatio 从 0 更改为 1：
完成后，必须重启 Temperature Sensor 和 Filter 模块：
几分钟后，跟踪和详细日志将从故障设备送达到 Azure Monitor。 整个端到端消息流（从设备上的传感器到云中的存储）将可用于在 Application Insights 中通过应用程序映射进行监视：
在此映射中，我们可以向下钻取到跟踪，可以看到其中一些跟踪看起来正常并包含流的所有步骤，而其中一些步骤则较短，因此在 Filter 模块后不会发生任何操作。
让我们来分析其中一个短跟踪，并找出 Filter 模块中发生的情况，以及为何其未将消息发送到上游云。
由于日志与跟踪相关，因而我们可以查询指定 TraceId 和 SpanId 的日志，从而检索与 Filter 模块的执行实例完全对应的日志：
日志显示模块收到一条消息：温度为 70.465 度。 但此设备配置的筛选阈值为 30 到 70。 因此，消息只是没有通过阈值。 显然，这一特定设备的配置有误。 这是我们在使用工作簿监视 La Niña 服务性能时检测到的问题的原因。
让我们更新模块孪生中的属性，以此来修复该设备上的 Filter 模块配置。 我们还想要将 loggingLevel 降低回 Information，并将 traceSampleRatio 降低为 0：
完成操作后，我们需要重启模块。 几分钟后，设备会将新的指标值报告给 Azure Monitor。 会在工作簿图表中进行反映：
我们可以看到问题设备上的消息频率恢复正常。 如果配置观察间隔期间没有任何其他情况发生，则整个 SLO 值将再次变为绿色：
尝试使用示例
此时，你可能想要将场景示例部署到 Azure 以重现这些步骤并尝试自己的用例。
为了成功部署此解决方案，你需要以下内容：
- PowerShell。
- Azure CLI。
- 具有活动订阅的 Azure 帐户。 创建试用版订阅。
克隆 IoT ELM 存储库。
git clone https://github.com/Azure-Samples/iotedge-logging-and-monitoring-solution.git打开 PowerShell 控制台并运行
deploy-e2e-tutorial.ps1脚本。./Scripts/deploy-e2e-tutorial.ps1
后续步骤
在本文中，你设置了一个具备端到端可观测性功能的解决方案，用于进行监视和故障排除。 此类针对 IoT 系统的解决方案的一个常见困难在于将可观测性数据从设备传送到云。 此场景中的设备应该保持联机状态并与 Azure Monitor 建立稳定的连接，但现实生活中情况却并非总是如此。
继续跟进使用 IoT Edge 进行分布式跟踪等文章，了解相关建议和技术，以处理设备处于正常离线状态或与云中的可观测性后端连接有限或受限时的情况。