6. 监控作为知识的关键

第6章 监控作为知识的关键

© Unai Huete Beloki 2025
U. H. Beloki，《The Art of Site Reliability Engineering (SRE) with Azure》，
https://doi.org/10.1007/979-8-8688-1545-4_6

本章将介绍监控策略的基础知识，重点讨论相关概念，并解释应用于实现可观测性目标的广泛 Azure 服务。

学完本章后，你应该能够：

• 理解运维认知以及监控与可观测性的区别
• 回顾第2章的 SRE 概念：SLI/SLO/SLA 和错误预算
• 了解燃烧率（错误预算）
• 了解 Azure Service Health
• 了解 Azure Monitor 和 Log Analytics
• 学习如何使用 Application Insights 并对其进行自定义
• 学习如何使用 Kusto（KQL）查询
• 学习如何使用 Azure Alerts

运维认知

图6-1. Dickerson 的可靠性层级：监控

很明显，理解你的解决方案对于以正确的方式进行监控至关重要。这个想法看似简单，但实施起来并不容易。如今创建的解决方案具有复杂的架构，而 DevOps + 敏捷方法论带来的快速变化使得理解构成解决方案的所有组件变得困难。运维认知是了解需要监控什么的关键。在定义监控策略之前，需要回答一些问题：

• 我们的环境上运行着什么？了解我们正在运行的解决方案类型。
• 组件运行在哪里？服务类型（Azure VM、WebApp、容器实例、AKS、SQL 数据库、Cosmos DB 等）、定价层、区域和其他配置。
• 它由哪些服务组成？了解应用程序架构。
• 这些服务的依赖项有哪些？
  • 你如何对这些服务进行变更部署？手动？CI/CD？是否有任何自动化/手动测试？是否有任何部署策略？是否有任何安全措施（自动化/手动）？了解 DevOps 流程（如第5章所述）。
• 这些服务的所有者是谁？受可能事件影响的利益相关者？

一旦完全理解了解决方案，你还可以根据过去的性能定义解决方案“正常”行为的基线。本章将展示 Azure 工具如何通过机器学习算法提供这种体验（稍后请参阅 Application Insights 智能检测）。

那么下一步是什么？如果你想要提高解决方案的可靠性，就需要对可靠性概念有清晰的认识。回顾第2章中的“理解可靠性”部分可能会有所帮助。请记住，可靠性与许多方面相关：

• 可用性：服务是“正常运行”还是“停机”？
• 延迟：请求与响应之间的延迟
• 吞吐量：成功处理的数据量
• 以及其他许多方面，如第2章中介绍的：新鲜度、覆盖率和正确性

这些是你希望为所提供的服务监控的解决方案的各个方面。

SLI/SLO/SLA

回顾第2章“服务级指标”部分中介绍的概念可能会有所帮助：

• 服务级指标 (SLI)：为定义服务健康状态而测量的一种指标。它是被监控的度量。例如，一个 API 每小时成功请求的数量（响应码 200 且响应时间低于 200ms）。
• 服务级目标 (SLO)：基于追踪的指标，由团队设定目标。基于前面的例子，一个 SLO 可能是 API 每小时成功请求（响应码 200 且响应时间低于 200ms）达到 99.9%。SLO 由以下部分组成：
  • 要测量的指标
  • 目标：可以随时间改进/改变（与利益相关者商定）
  • 时间间隔/持续时间
• 服务级协议 (SLA)：如果未达到 SLA，会导致赔偿的合同协议。基于前面的例子，提供给客户的 SLA 可能是请求的 99%。请记住，9 的数量（停机时间）、对服务所需的投资以及发布速度之间存在权衡。目标始终应该是达到适当（或可接受）的可靠性水平（如第1章所述）。

作为 SRE，考虑到前述的可靠性方面，应从客户的角度衡量可靠性。在定义 SLI/SLO/SLA 时，请设身处地为客户着想。你对产品的期望是什么？例如：

• 如果服务的性能足够好，客户真的关心集群的 CPU 负载是否达到 90% 吗？
• 如果你的解决方案运行在多个副本上并且仍然流畅地提供响应，客户真的关心一个工作负载实例是否宕机吗？

当然，你应该就应用程序中的异常行为或潜在事件收到警报；但是，定义的 SLI 主要应监控影响客户体验的指标：成功请求百分比、特定服务的响应时间或数据新鲜度（体育赛事、选举等）。

错误预算/燃烧率

请记住第2章的内容：当定义 SLO 时，会给出一个错误预算 (1-SLO)。你应该创建警报，以便在错误预算消耗完之前做出反应！当错误预算消耗完时，DevOps 团队可能会被鼓励放慢变更速度，并首先着手稳定现有解决方案。

基于错误预算/燃烧率（预算消耗的速度）创建警报。例如，设想以下情况：

• SLI ➤ 对 API 操作的调用应成功，且响应时间低于 100ms。
• SLO ➤ 你为所有月度调用定义了一个目标为 98%。
• 错误预算 = (1-SLO) ➤ 2%。
• 如果你的 API 每月接收 100,000 次调用，那么错误预算将是每月 2000 次失败请求。
  • 如何基于燃烧率（错误预算消耗的速度）定义警报？对于月度 SLO 周期，燃烧率为 1 意味着在月底消耗完所有预算。请查看 Google 的视频：https://www.youtube.com/watch?v=t1BGo-Il1AM：
    • 燃烧率 = 错误预算消耗量 * 周期/警报窗口
    • 错误预算消耗量：若预算已使用 100%，则为 1
  • 如果你想测量过去一小时内错误预算的 2% 消耗量（2000 的 2% ➤ 40 次失败请求 ➤ 这将在 50 小时内消耗完预算！），那么燃烧率为：
    • 燃烧率 = 0.02 * (31d * 24h) / 1h = 14.88
  • 当分别使用短窗口和长窗口评估时，应定义警报。对于前面的例子，我们可以同时评估 1 小时（长）和 5 分钟（短）窗口。

那么，我们如何跟踪/测量这些指标呢？

本章的目的是解释 Azure 提供的工具，以定义实现它们的方法，并为你的解决方案设计最佳的监控方案。

可观测性与监控

如今，这两个术语经常被 IT 团队使用（并混淆）。最近设计的分布式应用程序带来了挑战，例如追踪可能跨越多个服务和基础设施组件的请求。但是监控和可观测性是同一个概念吗？

不是。社区中对这两个术语有很多定义，但让我们以最简单的方式解释：

• 可观测性：提供根据系统外部输出来理解其内部状态的能力。它是信息性的。
• 监控：收集数据、分析数据并根据信息做出决策的过程。它是可操作的。

在复杂的解决方案（全栈视图）中实现可观测性后，你将获得所需的可见性，以创建可操作的警报、报告/仪表板，甚至基于历史数据使用 AIOps 解决方案进行异常检测。可观测性可以识别出三个主要支柱：

• 日志：事件的时间戳描述。日志可能需要结构化和解析以便进一步分析（查询）。
• 指标：时间点的测量值，主要是数值，用于警报和报告。
• 追踪：获取特定请求的详细信息，以及它们在分布式系统中如何流经所使用的组件。

让我们看看如何在 Azure 中实现我们的可观测性目标。

Azure Service Health

https://docs.microsoft.com/en-us/azure/service-health/overview

图6-2. Azure Service Health

• 服务问题：提供查看实时问题的方法。可以为这些问题定义警报。
• 计划维护：即将发生的维护事件信息。
• 健康建议：Azure 服务可能影响工作负载的变更。
• 安全建议：与安全相关的通知。
• 资源健康：报告 Azure 服务的过去和当前健康状态，依靠预定义信号来评估资源是否不健康。

https://status.azure.com/

图6-3. Azure 状态网站

Azure Monitor

当你在 Azure 中托管解决方案时，需要考虑多个数据源以满足可观测性需求。Azure Monitor 提供了一个统一的体验，使你可以全面了解运行中 Azure 服务（以及非 Azure 工作负载）的健康状态、性能和其他方面。默认情况下会收集指标（无需设置，免费，通常存储 90 天），但 Azure Monitor 使用以下两个工具进行日志和追踪的收集（记住可观测性支柱）：

图6-4. Azure Monitor

• Application Insights：提供收集应用程序代码性能和功能数据的工具：使用追踪、应用程序日志和用户遥测。新的 Application Insights 实例使用 Log Analytics 工作区作为数据存储。

数据源

图6-4（注：此图编号与上重复，原文如此）

• 应用程序：如前所述，你可以使用 Application Insights 来跟踪应用程序的性能和使用情况。Application Insights 为我们提供了不同的遥测收集选项（无代码和基于 SDK 的体验，稍后介绍）。

• 操作系统：通过使用 Azure Monitor 代理 (AMA)，我们可以从未访客操作系统（Azure 和非 Azure VM/服务器）收集日志和指标。

• Azure 资源：Azure 云平台提供以下数据：

  • 指标：默认收集 93 天。如果引入 Log Analytics 工作区，可以保留更长时间。

    https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs-schema

  图6-5. Cosmos DB 的诊断设置

  • 资源日志：提供 Azure 资源内部操作的丰富、频繁的数据。Azure 资源的诊断设置允许用户流式传输此日志。设置如下：Azure Monitor ➤ 诊断设置 ➤ 添加诊断设置 ➤ 选择日志类别（例如，对于 Cosmos DB：DataPlaneRequests、QueryRuntimeStatistics 等）➤ 发送到 Log Analytics 工作区。

    图6-6. 活动日志导出选项

• **## 可视化

一旦使用 Application Insights、Log Analytics 或默认提供的指标收集了数据，你就应该开始考虑数据可视化的方式。以下是一些可用的工具。

Azure 仪表板

Azure 仪表板允许你在一个集中视图中将 Azure 资源的不同图表和视图分组。你可以基于 Application Insights、Log Analytics 查询或 Azure Monitor 指标创建磁贴。

TIP

使用仪表板创建运维团队和利益相关者的实时状态概览。可以共享并固定到 Azure 门户。

工作簿

工作簿（Azure Monitor 工作簿）提供了一种更灵活的交互式报告方式。你可以结合文本、查询、指标和参数来创建可自定义的数据分析。工作簿非常适合创建故障排除指南或运维手册。

视图设计器

视图设计器是一种较旧的可视化工具，用于创建基于 Log Analytics 工作区的自定义视图。但请注意，微软已宣布视图设计器即将弃用，并推荐使用工作簿替代。

Grafana

Azure 支持将 Azure Monitor 数据源集成到 Grafana 中。Grafana 是一个开源的数据可视化和仪表板工具，可以连接多种数据源。你可以使用 Azure Monitor 数据源在 Grafana 中创建仪表板，并利用丰富的图形和告警功能。

分析

Azure Monitor 提供了强大的分析功能，主要通过 Log Analytics 和 Application Insights 中的查询语言（Kusto 查询语言，KQL）实现。

Application Insights 和分析

Application Insights 内置了分析工具，允许你运行 KQL 查询、创建图表和设置警报。你可以深入分析请求、依赖项、异常等数据。

Azure Monitor 日志

所有发送到 Log Analytics 工作区的数据都可以通过 Log Analytics 查询接口进行分析。你可以编写 KQL 查询来筛选、聚合和可视化数据。

警报

有效的监控需要及时响应。Azure 提供了以下警报功能：

Azure Monitor 警报

Azure Monitor 警报允许你基于条件（例如指标阈值、日志搜索结果、活动日志事件、资源健康状况等）定义警报规则。每个警报规则可以触发操作组（例如发送电子邮件、短信、调用 Webhook、运行 Azure 函数等）。

WARNING

确保为警报设置清晰的操作和升级路径，并定义标准的响应流程。

基于指标的警报

可以为 Azure 平台指标（例如 CPU 使用率、请求计数）或从 Application Insights 收集的自定义指标创建警报。支持多个条件、动态阈值（使用机器学习自动学习基线）和多信号警报（预览）。

基于日志的警报

通过定期运行 Log Analytics 查询来检查特定条件。如果查询结果匹配定义的阈值，则触发警报。这类警报适合用于检测特定错误模式或异常事件。

预计停机成本警报

这是 SRE 相关的高级功能，用于评估服务停机对预算的影响。

Application Insights 中的警报

Application Insights 提供了专门针对应用性能监控的警报功能：

• 智能检测：使用机器学习自动检测应用程序中的失败模式、性能异常和潜在问题，无需手动配置。
• 可用性测试：可以创建周期性 ping 测试或多步骤 Web 测试，以监控应用程序的对外可用性。

总结

本章介绍了监控策略的核心概念：运维认知、SLI/SLO/SLA、错误预算与燃烧率，以及可观测性与监控的区别。你学习了 Azure 中的可观测性服务栈：Azure Service Health 用于平台级健康信息，Azure Monitor 提供统一监控体验，Application Insights 用于应用层遥测，以及 Log Analytics 用于日志和指标分析。使用 KQL 查询可以深入分析数据，通过仪表板、工作簿和 Grafana 进行可视化，并通过警报及时响应。这些工具和概念共同支持了 SRE 的可靠性目标，即从客户角度度量并维护适当水平的服务质量。

第6章 监控作为知识的关键

可视化

数据收集完成后（无论是使用Application Insights、Log Analytics还是默认提供的指标），你就应该开始考虑如何可视化数据。以下是一些可用的工具。

Azure仪表板

图6-7 Application Insights 默认仪表板

使用Azure RBAC允许其他人查看你的仪表板。它们可以像其他Azure资源一样被管理。由于仪表板由JSON文件表示（点击“导出”），你也可以通过编程方式更改和部署它们，例如使用Azure CLI命令。在编辑时，你可以包含自定义Markdown内容，或使用库中的预定义磁贴。

指标资源管理器（指标）

该服务用于根据从运行服务收集的指标绘制图表。这些解决方案允许你在同一图表上关联来自多个Azure资源的指标，并使用过滤器选择所需属性。

图6-8 WebApp和Cosmos DB的指标图表

Azure工作簿

Azure工作簿（https://docs.microsoft.com/zh-cn/azure/azure-monitor/visualize/workbooks-overview）提供了一个出色的画布，可用于丰富的可视化和分析。将多个数据源收集到一个交互式“页面”中，供你的工程团队用于监控。

你可以组合Markdown文本、查询和指标图表，使用者可以通过你指定的参数进行交互式修改。工作簿也可以被视为Azure资源；它们提供了将其作为ARM模板使用的方式（https://docs.microsoft.com/zh-cn/azure/azure-monitor/visualize/workbooks-automate）。

图6-9 警报管理工作簿

Azure Monitor Insights

图6-10 Azure Monitor中的Insights

图6-11 存储账户资源中的Insights

Grafana

Grafana是一个知名的开源解决方案，用于提供分析和交互式可视化。Grafana可以连接到多个数据源，作为主要的可观测性平台。

如果使用Azure Monitor（Log Analytics/Application Insights）进行数据收集，你可以选择通过Azure Monitor数据源插件（https://grafana.com/docs/grafana/latest/datasources/azure-monitor/）连接到Grafana。该插件能够检索前面提到的指标/日志/跟踪，并将它们实时整合到单个用户界面中。

设置Grafana服务器有两种不同的方式：

• 临时设置（在你选择的VM/服务器上）通过安装Grafana解决方案。
• Grafana Cloud：由Grafana Labs提供的托管服务（https://grafana.com/products/cloud/）。
• 创建Azure托管Grafana服务（https://docs.microsoft.com/zh-cn/azure/managed-grafana/）（撰写本文时为预览版）：
  • 完全由微软支持，无需处理设置和托管。
  • 可以与组织内外部人员共享仪表板。
  • 使用Azure AD进行身份验证和访问控制。
  • 使用托管标识自动连接Azure Monitor作为数据源进行身份验证。

图6-12 从Azure门户将日志查询图表导出到Grafana

图6-13 导出的查询图表在Azure托管Grafana中

Power BI

图6-14 导出用于Power BI的M查询

分析

Azure Monitor日志

最近关于这些产品的术语混淆很多。在将许多工具整合到Azure Monitor范围（Log Analytics和Application Insights）之后，引入了以下命名更改：

• Log Analytics工作区（以前且仍在使用）= Azure Monitor日志（现在）：这是在Azure门户中用于收集、分析和操作遥测数据的服务。Azure Monitor日志使用Log Analytics工作区来收集和管理日志数据。可以通过许多资源提供的“日志”选项卡或Azure Monitor中的“日志”选项卡访问。

图6-15 存储账户日志中未找到数据的警告

单个工作区可能满足你组织的需求。然而，如果你想定义不同的要求（所有者、成本、数据保留、数据限制等），请查看https://docs.microsoft.com/zh-cn/azure/azure-monitor/logs/workspace-design 中介绍的最佳实践。拥有适当权限后，你仍然可以运行跨工作区查询：https://docs.microsoft.com/zh-cn/azure/azure-monitor/logs/cross-workspace-query。

Log Analytics / Azure Monitor日志

Log Analytics（或Azure Monitor日志）提供了创建和执行我们自己查询的选项。你可以在许多资源的“日志”部分找到它。从Azure Monitor、单个资源或Log Analytics工作区资源中，“日志”部分允许你选择要查询的范围。从资源的“日志”部分，范围将限于相关资源。

图6-16 日志用户界面

1. 用户选择的范围（“查询”旁边的“…”）。
2. 要执行的查询（使用“运行”按钮）。时间范围可以在查询中和顶部选项中指定。
3. 结果显示/图表显示已执行的查询。可以使用右侧提供的选项修改图表。
4. 侧边栏提供多个工具： a. 表显示范围的收集数据；可以展开以显示列。 b. 查询显示示例查询；你可以执行或访问已保存的查询。 c. 函数是一个可以在其他查询中作为命令使用的查询。你可以使用预定义函数或创建自己的函数与团队共享。 d. 查询历史记录
5. 一些额外选项： a. 新建警报规则允许你根据查询结果创建警报规则（“共享”旁边的“…”）。 b. 保存并共享允许你将查询/图表移动到其他解决方案，如Azure工作簿、Azure仪表板、Power BI或Grafana。
6. 查询中心可用于访问以前保存的预定义或自定义创建的查询。可以使用查询包（默认或自定义）将查询分组保存（https://docs.microsoft.com/zh-cn/azure/azure-monitor/logs/query-packs）。

Kusto查询语言 (KQL)

Kusto或KQL是一种丰富的查询语言，设计得易于阅读和编写。它是用于分析在工作区中收集的数据的查询语言。它也用于Azure Data Explorer（https://docs.microsoft.com/zh-cn/azure/data-explorer/data-explorer-overview）；实际上，它是为此而创建的，现在已扩展到Azure Monitor和其他产品（并非所有运算符都受支持）。

对于那些有SQL和Splunk经验的人，该产品提供了文档来帮助你理解这些语言之间的差异：

• SQL到Kusto：https://docs.microsoft.com/zh-cn/azure/data-explorer/kusto/query/sqlcheatsheet
• Splunk到Kusto：https://docs.microsoft.com/zh-cn/azure/data-explorer/kusto/query/splunk-cheat-sheet

如果你没有上述工具的经验（即使有），也提供了大量免费文档/教程来学习Kusto语言。一整本书可能都用来教授这种查询语言，但这并非本书的重点。

请查看以下链接中分享的材料/链接；它包括速查表、Microsoft Learn模块和社区博客/内容：https://docs.microsoft.com/zh-cn/azure/sentinel/kusto-resources。查看由Rod Trent维护的GitHub仓库（指向他的电子书、视频频道，甚至商品商店）：https://github.com/rod-trent/MustLearnKQL。

本章末尾的演示将展示使用这种查询语言的一些实用方法。

Azure Resource Graph

Azure Resource Graph（https://docs.microsoft.com/zh-cn/azure/governance/resource-graph/overview）是一种用于帮助你管理Azure云环境的服务，提供由Kusto查询（KQL）驱动的查询体验。跨订阅探索资源（及其属性）以帮助你治理环境。你甚至可以查询过去14天内更改的资源属性。Azure Resource Graph为Azure门户的搜索栏、新的“浏览所有资源”体验以及Azure Policy的更改历史提供支持。

图6-17 Azure Resource Graph Explorer 范围

GitHub 仓库：https://github.com/Azure-Samples/Governance/tree/master/src/resource-graph/portal-dashboards

图6-18 Azure仪表板及相关Resource Graph查询

Application Insights

Application Insights（https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/app-insights-overview）是Azure Monitor生态系统提供的应用程序性能管理（APM）工具。它将帮助你理解复杂应用程序架构中的所有动态部分。

Application Insights是开发人员必须采用的工具，以便让应用程序代码执行的操作可见。SRE/DevOps应拥抱这种文化变革：监控不仅仅是运维工程师的责任，而是每个人的责任。当为解决方案设计新功能时，应附带其SLO/SLI以及需要从代码中衡量的指标。开发人员需要使用Application Insights SDK来充分发挥这个强大工具的潜力。

检测选项/设置

Application Insights提供了不同的数据收集选项：

• 自动检测（无代码）：开发人员只需启用自动遥测收集，即可用最少的努力检测其应用程序。它能够收集应用程序发出的指标、请求或依赖项调用。你可能在Azure App Services或Azure Functions中看到过Application Insights选项卡。许多环境/语言支持此选项；甚至可以使用Application Insights代理检测本地应用。在此查看完整列表：https://learn.microsoft.com/zh-cn/azure/azure-monitor/app/codeless-overview。

NOTE

就个人而言，我仅在不使用SDK的情况下才推荐此选项（例如，开发外包，你无法访问自定义代码）。SDK在功能和自定义方面释放了该工具的全部潜力。

• SDK：Application Insights为多种编程语言提供SDK，如.NET、Java、Node.js、Python和JavaScript。它释放了该工具的全部潜力，因为我们可以完全自定义“什么”遥测数据会被收集，“如何”创建（过滤/添加额外属性），甚至如何发送（采样）到云中的Application Insights实例进行收集。本节将提供其中一些示例。几乎任何编写的应用程序…

第6章 监控作为知识的关键

第194页

在支持的语言中，并且与 Azure 建立了连接，无论是前端、中间件还是后端，几乎任何应用程序都可以通过此选项进行监控。

• OpenTelemetry 发行版（Distro）： 基于开源遥测项目（https://opentelemetry.io/）的未来选项。OpenTelemetry 包含所有主要云和应用程序性能管理（APM）供应商的贡献，并归属于云原生计算基金会（CNCF），但目前尚未与 SDK 选项的特性完全一致（https://learn.microsoft.com/zh-cn/azure/azure-monitor/app/opentelemetry-help-support-feedback?tabs=aspnetcore#whats-the-current-release-state-of-features-within-the-azure-monitor-opentelemetry-distro）。当使用 OpenTelemetry 厂商中立的检测 SDK 时，可将 Application Insights 用作数据存储。由于缺少某些特性，本书将重点介绍 Application Insights SDK 选项。请查看网站获取未来更新：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/opentelemetry-overview。

第195页

新的 Application Insights 实例将使用 Log Analytics 工作区作为数据存储（之前经典选项使用自己的后端存储数据）。创建实例时，提供以下选项来从应用程序代码向 Application Insights 实例进行身份验证/连接（主要在使用 SDK 时）：

• 检测密钥（Instrumentation key）： Application Insights 实例的标识符。早期的 Application Insights SDK 仅使用检测密钥即可允许数据引入。建议迁移到以下选项（检测密钥支持将于 2025 年结束）：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/migrate-from-instrumentation-keys-to-connection-strings#new-capabilities。
• 连接字符串（Connection string）： 定义遥测数据必须发送到哪里。连接字符串可针对代理重定向进行自定义（用于某些本地解决方案）。将连接字符串作为环境变量（或使用 Azure 应用程序配置）保存，变量名为 APPLICATIONINSIGHTS_CONNECTION_STRING。
• 基于 Azure AD 的身份验证（预览，推荐）： 用于仅允许使用 Azure AD 进行身份验证的遥测。你可以禁用本地身份验证，以确保仅允许 Azure AD 标识（如托管标识或服务主体）引入遥测：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/azure-ad-authentication?tabs=net。

特性

下面介绍 Application Insights 提供的一些特性。

应用程序地图（Application Map）

快速获取应用程序及其组件的表示，以快速检测故障和瓶颈。组件主要是应用程序对外部解决方案（如 API、SQL 数据库、Cosmos DB、存储队列、存储表等）的调用。即使使用不同 Application Insights 资源的应用程序，如果组件相关，也可以一起显示在地图中。

第196页

点击外部组件时，将显示最常见的错误（如失败或最慢的请求）以供进一步调查。预览版智能视图（Intelligent View）应用机器学习，根据过去的表现帮助识别可能的问题：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/app-map?tabs=net#application-map-intelligent-view-public-preview。

图 6-19.  应用程序地图

（注：原始文本中为图 6-19 的占位说明，此处保留描述。）

第197页

智能检测（Smart Detection）

Application Insights 的智能检测功能通过学习应用程序的过往行为，利用机器学习检测异常，并针对慢响应或服务退化等问题发出警报。它有自己的警报系统，可发送通知邮件，但现在可以迁移到 Azure 警报，该警报可使用操作组/操作规则来集中管理警报体验（预览）：https://docs.microsoft.com/zh-cn/azure/azure-monitor/alerts/alerts-smart-detections-migration。

实时指标流（Live Metrics Stream）

图 6-20

实时指标使用与数据引入功能（https://dc.applicationinsights.azure.com）不同的终结点（https://live.applicationinsights.azure.com）。它的行为也与指标资源管理器或 Log Analytics 解决方案不同。对于实时指标，数据仅在打开窗格时发送，在一秒内显示，显示后即丢弃。对于指标资源管理器和 Log Analytics，数据始终会收集，以分钟为单位进行聚合，并保留 90 天（默认）至 2 年。

第198页

图 6-20.  实时指标流

事务搜索（Transaction Search）

图 6-21

图 6-21.  事务搜索

第199页

可用性（Availability）

Application Insights 提供了运行和监控针对环境可用性测试的选项。提供以下选项：

• 经典测试（Classic test）： 验证终结点的简单测试。
• 标准测试（Standard test）： 新一代 URL Ping 测试，提供更多自定义功能。
• 使用 TrackAvailability 的自定义测试： 使用 Application Insights SDK 从任何应用程序运行自定义测试并发送结果。

前三个选项使用来自 16 个不同全球点的预定义机器。对于在防火墙规则后面运行的解决方案，这可能不是最佳选择（你必须为所有这些机器开放流量）。使用 TrackAvailability 选项，你可以从任何基础设施/应用程序运行测试。例如，你可以使用 Azure 函数运行测试：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/availability-azure-functions。

第200页

图 6-22.  可用性测试

故障/性能（Failures/Performance）

故障和性能选项卡都会显示按服务器/浏览器视图划分的最新信息。

作为性能选项的一部分，可以启用 Profiler 来识别执行“较慢”的“热”代码路径。代码优化（Code Optimizations）是 Azure Application Insights 中的一项新的 AI 驱动服务，它与 Application Insights Profiler for .NET 协作。它识别与 CPU 和内存使用相关的代码级性能问题，并提供解决建议。Profiler 支持以下场景：https://learn.microsoft.com/zh-cn/azure/azure-monitor/insights/code-optimizations-profiler-overview#supported-in-profiler。

在故障方面，有一个名为快照调试器（Snapshot Debugger）的功能，它可以在异常发生时自动收集调试快照，让你有机会查看失败时的代码状态。支持以下场景：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/snapshot-debugger#enable-application-insights-snapshot-debugger-for-your-application。

第201页

故障排除指南（Troubleshooting Guides）

这是一个基于 Azure 工作簿的解决方案，开发人员可以在其中托管 Azure 工作簿，用于分析现有环境并记录已知问题的可能缓解措施。

日志（Logs）

图 6-23

图 6-23.  Application Insights 的监控部分

使用情况（用户行为）（Usage (User Behavior)）

我们之前提到，监控应始终关注客户。Application Insights 的“使用情况”部分提供了了解用户如何使用我们解决方案的工具。为了获得最佳体验，应同时跟踪服务器端和客户端代码（需在 JavaScript 中包含代码片段）。

第202页

该解决方案提供多种不同的视图（基于 Azure 工作簿）来分析用户行为（可以定义群组来将分析范围限定到用户群体）：

• 用户/会话页面： 了解用户所在位置以及使用的浏览器和操作系统。这可能是关键信息；例如，可用于将解决方案更贴近用户本地化，或创建针对最常见浏览器/操作系统组合的自动化测试工作。

• 留存率页面： 用于识别留存率。

• 事件页面： 分析最常用的 PageView 或自定义事件，如购买商品（使用 SDK 中的 TrackEvent API）。

• 漏斗页面： 让你定义解决方案中的重要工作流，并帮助分析从一个步骤到下一个步骤的转化率（以及可能的影响属性）。例如，如果你的应用程序是电子商务网站，你可以定义以下步骤并衡量转化率：1. 主页 ➤ 2. 将商品添加到购物车 ➤ 3. 开始结账 ➤ 4. 订单成功。

  这是一个非常有趣的解决方案，可用于识别哪些因素可能影响转化率。例如，假设在前一个漏斗中，步骤 3 和步骤 4 之间的转化率为 50%。漏斗工具将能够告诉你什么可能影响转化率。假设 Edge 浏览器用户的转化率为 70%，而 Safari 浏览器用户的转化率为 30%；该工具有助于识别这些问题。

第203页

• 图 6-24

图 6-24.  用户流

使用 SDK 自定义 Application Insights

如前所述，Application Insights SDK 使你可以充分利用产品的全部潜力，从行为自定义到自定义遥测选项。本节将介绍其中一些选项。

Application Insights API

即使 Application Insights 默认能够收集大量遥测数据，使用 SDK 对于收集应用程序逻辑数据仍然至关重要。例如，默认情况下，Application Insights 能够检测许多 HTTP 请求或依赖项调用，但它并不真正知道我们运行的是电子商务网站还是银行系统。利用以下参考中的 API，你有权决定要收集的遥测数据，使用自定义遥测（例如 TrackDependency()）来收集默认未检测到的依赖项：https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/api-custom-events-metrics#api-summary。

第204页

可以向自定义遥测提供属性（字符串值）和指标（数值），稍后用于创建图表和筛选。例如：

// 设置一些属性和指标:
var properties = new Dictionary <string, string>
    {{"game", currentGame.Name}, {"difficulty", currentGame.Difficulty}};
var metrics = new Dictionary <string, double>
    {{"Score", currentGame.Score}, {"Opponents", currentGame.OpponentCount}};
 
// 发送事件:
telemetry.TrackEvent("WinGame", properties, metrics);

Application Insights 高级配置

Application Insights 的行为可以通过 SDK 提供的以下选项进行修改：

• 在代码中启用/禁用服务： 每种语言的 SDK 都会提供选项来在代码中修改已启用/禁用的服务。你也可以通过删除负责收集自动遥测的模块来完全删除服务。例如，如果你对依赖项信息不感兴趣，只需删除相应的模块即可。
• 采样： 默认启用自适应采样，但也支持固定频率采样（https://docs.microsoft.com/zh-cn/azure/azure-monitor/app/sampling#configuring-adaptive-sampling-for-aspnet-core-applications）。

第6章 监控作为知识的关键

页码：178-233
内容： 讲解可观测性、Azure Monitor、Application Insights 和警报。

从第 204 页继续（上下文已在上部分处理）

• 采样：默认启用自适应采样，但支持固定速率采样（ASP.NET Core 应用程序配置自适应采样）。

第 6 章 监控作为知识的关键

第 205 页

• TelemetryInitializer：可用于丰富遥测属性；例如，你可以将应用程序版本添加到每个创建的遥测项中。

• RoleName/RoleInstance：这两个属性通常在 TelemetryInitializer 上定义，以便在使用应用程序映射时标识正在运行的实例。例如，如果你的解决方案由三台 VM 组成前端，你可以在 VM1 上定义 RoleName=app-frontend 和 RoleInstance=app-frontend-vm1。

• TelemetryProcessors：初始化器使用后，遥测被创建；然后它可以通过多个处理器，在发送到 Application Insights 资源之前修改和过滤遥测。

• 日志跟踪：对于使用诊断跟踪日志的 ASP.NET 解决方案（如 ILogger、NLog、log4net 和 System.Diagnostics.Trace）的客户，你可以在 Application Insights 中收集这些跟踪。

• 6-25
  使用 Azure CLI 创建发布注释

第 206 页

Azure Monitor 警报

前面提到的大多数监控工具都涉及“被动”方法：在问题发生后修复问题。另一方面，警报应用于“主动”方法：在用户注意到这些问题之前得到通知。

Azure 提供警报服务，可以在 Azure Monitor 的警报部分（此处集中管理警报）或单个 Azure 资源（警报限定于该资源）中找到。在 Azure 中定义的警报可以使用以下信号：

• Log Analytics 和 Application Insights 收集的日志/指标/跟踪。此外，还有 Application Insights 提供的智能检测或可用性测试。
• 平台指标（默认给出，保留 93 天）
• 活动日志警报

第 207 页

• 6-27

第 208 页

第 209 页

• 警报处理规则：当满足规则条件时，你可以通过抑制警报（例如，用于维护窗口）或基于过滤器自动分配操作组给警报（而不是逐个警报操作）来修改预期行为。这有助于在你的组织中管理警报。

• 操作组：一旦警报被触发（并由处理规则评估），触发自动化或通知：

  • 通知：电子邮件、推送通知
  • 自动化：Runbook、Logic Apps、Functions、Webhook、ITSM 集成或事件中心

• 6-28

第 210 页

• 用户响应（状态）：用户可以将警报状态定义为“新建”、“已确认”或“已关闭”。

为复杂环境定义的警报应该是“可操作的”。避免为成功的操作/状态创建警报；你只希望在可能危及到 SLO 的异常情况下得到通知。

一旦你的组织在此实践上变得更加成熟，你将能够过滤噪音（不可操作的警报），并触发可能自动修复或解决警报引发的问题的自动化。

弹性帮助你从故障中恢复。可用性让用户随时访问你的工作负载。设计预期故障并从故障中恢复的监控解决方案。

第 211 页

[演示] 使用 Application Insights 和 Log Analytics 跟踪 SLI/SLO/SLA

• 6-29
  SRE_with_Azure_v2 GitHub 仓库

第 212 页

.NET 8 网站使用 Application Insights SDK 从正在运行的应用程序收集遥测。Application Insights 按以下方式设置：

• 使用遥测初始化器（MyTelemetryInitializer.cs）在每个遥测中包含应用程序版本和 RoleName 属性。

• 使用初始器，并通过从 Azure App Configuration 资源获取的 connectionString 连接 Application Insights 实例（从 Program.cs 第53行）。

• 6-30

• 6-31

第 213 页

托管在 Azure Container App 中的网站提供了一个选项卡，用于向用户提供天气预报信息。在 ApiHelper.cs 文件中，创建了一个自定义的 TrackEvent() 遥测，用于跟踪对该服务调用的状态，提供全局位置（纬度/经度）、响应代码以及在 weatherForecast API 后端调用中使用的 API 密钥。

对于该服务，作为演示的 SRE，已定义以下内容：

• SLI：在过去 31 天内对天气预报功能（使用前面提到的 TrackEvent）发出的请求，并对用户返回成功响应。
• SLO：每月 98% 的调用应成功。
• 总错误预算：每月调用量的 2%。

第 214 页

customEvents
| where timestamp > ago(31d)
| extend success = tostring(customDimensions["status"])
| summarize succeed=count(success == "OK"), total=count() by bin(timestamp, 1h)
| extend SLI = succeed * 100.00/ total
| extend SLO = 98
| project SLI, SLO, timestamp
| render timechart

第 215 页

customEvents
| where timestamp > ago(31d)
| extend success = tostring(customDimensions["status"])
| summarize succeed=count(success == "OK"), total=count() by bin(timestamp, 1h)
| extend SLI = succeed * 100.00/ total
| extend SLO = 98
| project SLI, SLO, timestamp
| render timechart
//ERROR BUDGET
let total_requests_week=toscalar(
customEvents
| where timestamp > ago (7d)
| count
);
customEvents
| where timestamp > ago (31d)
| extend success = tostring(customDimensions["status"])
| summarize succeed=count(success == "OK"), total=count(), 
failed=count(success != "OK") by bin(timestamp, 1h)
| order by timestamp asc
| extend SLO=98
| extend total_budget=total_requests_week*(100-98)/100 //imagine you get 100000 requests per month and SLO is 98%, you can have 2000 failed requests per month
| serialize Available_budget = total_budget - row_cumsum(total-succeed)
| project Available_budget, failed, timestamp
| render timechart

第 216 页

//Burnrate 1h window
let total_requests_month=toscalar(
customEvents
| where timestamp > ago (31d)
| count
);
customEvents
| where timestamp > ago (31d)
| extend success = tostring(customDimensions["status"])
| summarize succeed=count(success == "OK"), total=count(), 
failed=count(success != "OK") by bin(timestamp, 60m)

第 217 页

| order by timestamp asc
| extend SLO=98
| extend monthly_budget=total_requests_month*0.02
| extend burn_rate_1h_limit=10
| extend burn_rate_hourwindow=(failed/monthly_budget)*(31*24)/1
// Burn rate = error budget consumed * period/alert window
| project burn_rate_hourwindow, burn_rate_1h_limit, timestamp
| render timechart

Azure DevOps

Azure DevOps 状态页

第 218 页

你可能希望在感知到异常行为时监控平台本身的状态（见图 6-35）。建议订阅通知。

• 6-36
  Azure DevOps 仪表板小部件目录

第 219 页

对于更高级的报告，可以将其外部化到 Power BI 等工具，你应该查看 Azure DevOps 提供的 Analytics 服务。Analytics 是报告平台，提供来自 ADO 项目的历史数据；它包括更高级的集成报告以及使用 Power BI/OData 查询进行数据外部化的选项。以下文档提供了通过该服务可用的数据（和选项）：Analytics 服务中可用的数据。

GitHub

GitHub 状态页

• 6-37

第 220 页

• 6-38

第 221 页

第 222 页

总结

在本章中，你了解了 Dickerson 可靠性层级中提到的基础实践：监控。

本章重点解释了监控和可观测性的基本概念，以及当今组织创建的复杂解决方案中操作感知的重要性。在介绍 Azure 监控技术之前，本章回顾了第 2 章中的概念，如 SLI/SLO/SLA 以及错误预算/燃烧速率的概念，因为这些指标对 SRE 至关重要。

本章重点介绍了 Azure 技术栈，这些技术可用于实现可观测性目标，并帮助你跟踪前述指标。

下一章将重点展示处理事件的有效方法，并解释如何通过无指责事后复盘从以前的经验中学习。

---

NOTE

本章中的图片引用（如 Figure 6-25 等）在原始文本中以占位符形式出现，在最终文档中应替换为实际图像。所有代码块和查询均按原样保留。