11、监控：获取知识的关键

监控：获取知识的关键

在当今的 IT 领域，自动化和监控是确保应用程序安全、可靠和高效运行的关键要素。下面我们将详细探讨监控策略的基础知识，以及如何利用 Azure 服务实现可观测性目标。

1. 运营意识

要想正确地监控解决方案，首先需要深入理解它们。然而，如今的解决方案架构复杂，DevOps/敏捷方法带来的快速变化使得全面理解解决方案的各个部分变得极具挑战性。运营意识对于明确需要监控的内容至关重要。在定义监控策略之前，需要回答以下问题：
- 运行环境 ：了解基础设施架构，明确解决方案在哪些环境中运行。
- 运行位置 ：确定服务类型（如 Azure VMs、WebApps、容器实例、AKS、SQL DB、Cosmos DB 等）、定价层和所在区域。
- 服务组成 ：理解应用程序架构，明确解决方案由哪些服务组成。
- 服务依赖 ：了解这些服务的依赖关系。
- 变更部署方式 ：明确是手动部署还是使用 CI/CD，是否有自动化或手动测试，以及采用了哪些部署策略。
- 服务所有者 ：确定服务的所有者以及可能受事件影响的利益相关者。

在全面理解解决方案后，可以根据过去的性能为解决方案的“正常”行为定义一个基线。Azure 工具可以借助机器学习算法提供这样的体验，例如后面会提到的 Application Insights 智能检测。

如果想提高解决方案的可靠性，还需要清晰地理解可靠性的概念。可靠性涉及多个方面，包括：
- 可用性 ：服务是“上线”还是“下线”。
- 延迟 ：请求和响应之间的延迟。
- 吞吐量 ：成功处理的数据量。
- 以及其他方面，如新鲜度、覆盖率和正确性等。

这些都是需要监控的服务方面。

2. SLI/SLO/SLA

回顾一下服务级别指标的相关概念：
- 服务级别指标（SLI） ：用于定义服务健康状况的指标，例如每小时对 API 的成功请求数量（响应状态码为 200 且响应时间低于 200ms）。
- 服务级别目标（SLO） ：基于跟踪的指标，团队设定的目标。例如，每小时对 API 的成功请求目标为 99.9%。SLO 由以下部分组成：
- 要测量的指标 ：明确需要监控的具体指标。
- 目标 ：可以随着时间的推移进行改进或更改，需与利益相关者达成一致。
- 时间间隔/持续时间 ：确定目标的时间范围。
- 服务级别协议（SLA） ：如果未达到 SLA，将提供补偿的合同协议。例如，向客户提供的 SLA 可能是 99% 的请求成功率。需要注意的是，要权衡 9 的数量（停机时间）、服务所需的投资和发布速度，目标始终是达到适当（或可接受）的可靠性水平。

作为 SRE，在定义 SLI/SLO/SLA 时，应从客户的角度考虑可靠性。例如，客户可能并不关心集群的 CPU 负载是否达到 90%，只要服务性能良好；或者当解决方案在多个副本上运行且仍能流畅响应时，客户可能并不关心某个工作负载实例是否下线。因此，定义的 SLI 应主要监控影响客户体验的指标，如成功请求百分比、特定服务的响应时间或数据的新鲜度。

3. 错误预算/消耗率

在定义 SLO 时，会给出一个错误预算（1 - SLO）。应该创建警报，以便在错误预算耗尽之前做出反应。当错误预算耗尽时，DevOps 团队可能需要放慢变更速度，先致力于稳定现有解决方案。

可以根据错误预算/消耗率（预算消耗的速度）创建警报。例如，假设以下情况：
- SLI ：上个月对 API 操作的调用应成功且响应时间低于 100ms。
- SLO ：将所有月度调用的目标设定为 98%。
- 错误预算 ：（1 - SLO）= 2%。
- 如果 API 每月接收 100,000 次调用，那么错误预算为每月 2000 次失败请求。

计算消耗率的公式为：Burn rate = 错误预算消耗 * 周期/警报窗口（错误预算消耗为 1 表示 100% 使用预算）。

例如，如果想测量过去一小时内错误预算的 2% 消耗（2% 的 2000 即 40 次失败请求，这意味着将在 50 小时内耗尽预算），消耗率为：Burn rate = 0.02 * (31d * 24h) / 1h = 14.88。

警报应在短时间窗口和长时间窗口进行评估。对于上述示例，可以同时评估 1 小时（长窗口）和 5 分钟（短窗口）的情况。

4. 可观测性与监控

如今，IT 团队经常使用并混淆“可观测性”和“监控”这两个术语。分布式应用程序带来了跟踪跨越多个服务和基础设施组件的请求等挑战。实际上，可观测性和监控并不是同一概念：
- 可观测性 ：基于系统的外部输出，提供理解系统内部状态的能力，具有信息性。
- 监控 ：收集数据、分析数据并根据信息做出决策的过程，具有可操作性。

对于复杂的解决方案，实现可观测性（全栈视图）后，可以获得创建可操作警报、报告/仪表板，甚至使用 AIOps 解决方案基于历史数据进行异常检测所需的可见性。可观测性有三个主要支柱：
- 日志 ：事件的时间戳描述，可能需要进行结构化和解析以进行进一步分析（查询）。
- 指标 ：时间点测量，主要是数值（比日志更一致），用于警报和仪表板展示。
- 跟踪 ：获取特定请求的详细信息以及它们在分布式系统中各个组件之间的流动情况。

5. Azure 服务健康

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

6. Azure 监控

当在 Azure 中托管解决方案时，需要考虑多个数据源以实现可观测性。Azure 监控提供了统一的体验，可以全面了解运行中的 Azure 服务（包括非 Azure 工作负载）的健康、性能和其他方面。默认情况下会收集指标，同时 Azure 监控使用以下两个工具来收集日志和跟踪信息（可观测性支柱）：
- Application Insights ：提供收集应用程序代码性能和功能数据的工具，使用跟踪、应用程序日志和用户遥测。新的 Application Insights 实例使用 Log Analytics 工作区作为数据存储。

Azure 监控可以收集以下用于监控的数据源/层级，并将其保留在 Log Analytics 工作区中进行进一步分析和报告：
- 应用程序 ：使用 Application Insights 跟踪应用程序的性能和使用情况，它提供了无代码和基于 SDK 的遥测收集选项。
- 操作系统 ：通过 Azure 监控代理（AMA）收集来宾操作系统（Azure 和非 Azure VM/服务器）的日志和指标。
- Azure 资源 ：Azure 云平台提供以下数据：
- 指标 ：默认收集 93 天的数据，如果摄入到 Log Analytics 工作区，可以保留更长时间。
- 资源日志 ：可以通过诊断设置进行配置。
- Azure 租户 ：收集与 Azure Active Directory 相关的操作数据，可通过 Azure Active Directory 的诊断日志设置导出。
- 自定义源 ：使用 Azure 监控提供的 REST API 将日志/指标导入 Log Analytics 工作区。

7. 数据可视化

收集数据后，需要考虑如何可视化这些数据。以下是一些可以使用的工具：
- Azure 仪表板 ：使用 Azure RBAC 允许他人查看仪表板，它可以像其他 Azure 资源一样处理。仪表板以 JSON 文件表示，可通过 Azure CLI 命令进行编程式更改和部署。编辑时，可以包含自定义的 Markdown 内容或使用图库中的预定义磁贴。
- 指标资源管理器（指标） ：用于根据从运行服务收集的指标绘制图表，可以在同一图表上关联多个 Azure 资源的指标，并使用过滤器选择所需的属性。
- Azure 工作簿 ：提供了一个用于丰富可视化和分析的画布，可以将多个数据源聚集在一个交互式“页面”中，供工程团队进行监控。可以结合 Markdown 文本、查询和指标图表，并通过指定参数让用户进行交互式修改。工作簿也可以作为 Azure 资源处理，并可以使用 ARM 模板进行操作。
- Azure 监控见解 ：提供对 Azure 服务的深入见解，帮助用户更好地理解服务的运行状况。
- Grafana ：一个知名的开源分析和交互式可视化解决方案。可以使用 Azure 监控数据源插件连接到 Grafana，将之前提到的指标/日志/跟踪信息实时整合到一个用户界面中。设置 Grafana 服务器有以下几种方式：
- 临时设置 ：在选定的 VM/服务器上安装 Grafana 解决方案。
- Grafana 云 ：由 Grafana Labs 提供的托管服务。
- Azure 托管 Grafana 服务 ：目前处于预览阶段，由 Microsoft 完全支持，无需处理设置和托管问题。可以与组织内外的人员共享仪表板，使用 Azure AD 进行身份验证和访问控制，并使用托管身份自动连接到 Azure 监控作为数据源。
- Power BI ：可以将查询和图表导出到 Power BI 进行进一步分析和可视化。

8. 数据分析

Azure 监控日志相关内容存在一些术语混淆。在将许多工具整合到 Azure 监控范围（Log Analytics 和 Application Insights）后，引入了以下命名更改：
- Log Analytics（以前使用且现在仍在使用）= Azure 监控日志 ：是 Azure 门户中用于编写和运行 Kusto 查询语言（KQL）查询已收集日志的服务（相当于日志的指标资源管理器）。可以从许多资源的“日志”选项卡或 Azure 监控的“日志”选项卡访问。
- Log Analytics 工作区 ：仍然是用于存储从选定源收集的日志的解决方案。可以使用 Azure RBAC（基于角色的访问控制）配置对工作区（以及收集的日志表）的访问权限。

一个工作区可能满足组织的需求，但如果需要定义不同的要求（如所有者、成本、数据保留、数据限制等），可以参考最佳实践：https://docs.microsoft.com/en-us/azure/azure-monitor/logs/workspace-design。在具备适当权限的情况下，仍然可以运行跨工作区查询：https://docs.microsoft.com/en-us/azure/azure-monitor/logs/cross-workspace-query。

Log Analytics（或 Azure 监控日志）允许用户创建和执行自己的查询。在许多资源的“日志”部分可以找到它。从 Azure 监控或 Log Analytics 工作区资源的“日志”部分，可以选择查询的范围；从资源的“日志”部分，查询范围将限于相关资源。操作步骤如下：
1. 选择查询范围 ：用户可以根据需要选择查询的范围。
2. 编写并执行查询 ：使用“运行”按钮执行查询，可以在查询中或顶部选项中指定时间范围。
3. 查看结果和图表 ：执行查询后，会显示结果和图表，图表可以通过右侧的选项进行修改。
4. 使用侧边栏工具 ：
- 表 ：显示查询范围内收集的数据，可以展开查看列信息。
- 查询 ：显示示例查询，用户可以执行或访问已保存的查询。
- 过滤器 ：帮助识别用于使查询更相关的字段，在运行查询后显示。
- 函数 ：可以在其他查询中作为命令使用的查询，用户可以使用预定义函数或创建自己的函数与团队共享。
5. 使用额外选项 ：
- 新建警报规则 ：根据查询结果创建警报规则。
- 导出 ：将查询/图表导出到其他解决方案，如 Azure 工作簿、Azure 仪表板、Power BI 或 Grafana。
6. 访问已保存的查询 ：可以使用查询包（默认或自定义）按组保存查询，方便后续访问。
7. 学习 KQL ：在页面右上角可以找到 KQL 的学习内容。

通过以上步骤，我们可以利用 Azure 的各种服务和工具构建全面的监控策略，实现解决方案的可观测性和可靠性提升。

监控：获取知识的关键

9. 可视化工具对比

为了更清晰地了解各种可视化工具的特点，我们可以通过以下表格进行对比：
| 可视化工具 | 特点 | 适用场景 | 配置难度 | 共享能力 |
| ---- | ---- | ---- | ---- | ---- |
| Azure 仪表板 | 使用 Azure RBAC 控制权限，以 JSON 文件表示，可编程式部署，可包含自定义 Markdown 内容和预定义磁贴 | 用于整体展示 Azure 资源的概况和关键指标，适合团队成员查看 | 较低，熟悉 Azure 操作即可 | 可通过 Azure RBAC 与他人共享 |
| 指标资源管理器（指标） | 可关联多资源指标并使用过滤器选择属性，绘制图表 | 专注于指标的可视化分析，对比不同资源的指标情况 | 中等，需要了解指标的含义和筛选条件 | 一般作为 Azure 监控的一部分，共享方式依赖于 Azure 监控的权限设置 |
| Azure 工作簿 | 提供交互式画布，可结合多种元素，使用 ARM 模板操作 | 用于详细的数据分析和展示，适合工程团队深入分析 | 中等，需要掌握一定的查询和参数设置知识 | 可作为 Azure 资源与团队成员共享 |
| Azure 监控见解 | 提供对 Azure 服务的深入见解 | 快速了解 Azure 服务的运行状况和潜在问题 | 较低，系统自动提供分析结果 | 依赖于 Azure 监控的权限设置 |
| Grafana | 开源，可连接多数据源，实时整合数据 | 适用于需要整合多种数据源进行统一可视化的场景，如混合云环境 | 较高，需要进行数据源配置和服务器设置 | 可通过不同方式与组织内外人员共享 |
| Power BI | 可将查询和图表导出进行进一步分析和可视化 | 用于企业级的数据分析和报表生成，与企业数据生态集成 | 中等，需要掌握 Power BI 的操作和数据建模知识 | 可在企业内部进行广泛共享 |

10. 监控流程示例

下面通过一个 mermaid 流程图展示一个基本的监控流程：

graph LR
    A[理解解决方案] --> B[定义监控策略]
    B --> C[收集数据]
    C --> D[数据存储（Log Analytics 工作区）]
    D --> E[数据可视化]
    E --> F[数据分析（KQL 查询）]
    F --> G{是否触发警报}
    G -- 是 --> H[采取行动（稳定解决方案等）]
    G -- 否 --> C

这个流程从理解解决方案开始，经过定义监控策略、收集数据、存储、可视化和分析等步骤，最后根据分析结果判断是否触发警报，若触发则采取相应行动，形成一个闭环的监控系统。

11. 最佳实践总结

在使用 Azure 服务进行监控时，有以下一些最佳实践：
- 运营意识方面
- 定期更新对解决方案的理解，随着架构和业务需求的变化，及时调整监控策略。
- 建立文档记录解决方案的架构、依赖关系和部署流程，方便团队成员查阅。
- SLI/SLO/SLA 定义方面
- 与业务团队和客户充分沟通，确保定义的指标和目标符合实际需求。
- 定期审查和调整 SLI/SLO/SLA，以适应业务的发展和变化。
- 错误预算和消耗率管理方面
- 建立合理的警报阈值，避免过度警报或警报不足。
- 当错误预算接近耗尽时，及时组织跨部门会议，共同商讨解决方案。
- 可观测性和监控工具使用方面
- 合理配置不同的可观测性支柱（日志、指标、跟踪），根据业务需求和系统特点进行重点关注。
- 定期清理 Log Analytics 工作区中的无用数据，控制存储成本。
- 可视化和分析方面
- 根据不同的受众和目的，选择合适的可视化工具和展示方式。
- 对常用的 KQL 查询进行整理和优化，提高查询效率。

12. 实际案例分析

假设一个在线电商应用托管在 Azure 上，我们可以看看如何应用上述监控知识。
- 运营意识 ：了解应用运行在 Azure VMs 和 WebApps 上，分布在多个区域，依赖于 Cosmos DB 存储数据，使用 CI/CD 进行部署。通过分析历史数据，确定了正常情况下的响应时间和吞吐量基线。
- SLI/SLO/SLA ：定义 SLI 为订单处理成功率和页面加载时间，SLO 为订单处理成功率 99%，页面加载时间在 3 秒内，SLA 为 98%。
- 错误预算/消耗率 ：根据 SLO 计算出错误预算，设置警报规则，当错误预算消耗速度过快时及时通知团队。
- 可观测性与监控 ：使用 Application Insights 收集应用的性能和用户行为数据，Azure 监控收集系统指标和日志。通过可观测性的三个支柱，全面了解应用的运行状况。
- Azure 服务健康 ：关注 Azure 服务健康信息，及时了解可能影响应用的服务问题和维护事件。
- Azure 监控和可视化 ：使用 Azure 监控将数据存储在 Log Analytics 工作区，通过 Azure 仪表板展示关键指标，使用 Grafana 进行深入的数据分析和可视化。
- 数据分析 ：使用 KQL 查询分析数据，发现订单处理成功率下降的原因是某个数据库查询性能问题，及时进行优化。

通过以上案例可以看出，综合运用 Azure 的各种监控服务和工具，可以有效地保障应用的可靠性和性能。

13. 未来趋势展望

随着技术的不断发展，监控领域也将面临新的挑战和机遇。未来可能会出现以下趋势：
- 智能化监控 ：更多地利用人工智能和机器学习技术，实现自动异常检测、预测性分析和智能决策。
- 混合云监控 ：随着混合云环境的普及，需要能够统一监控公有云和私有云资源的解决方案。
- 安全监控增强 ：在监控过程中更加注重安全相关的指标和事件，及时发现和防范安全威胁。
- 用户体验监控深化 ：不仅仅关注系统性能指标，还会更加深入地监控用户体验，如页面交互的流畅性、用户满意度等。

为了适应这些趋势，我们需要不断学习和掌握新的技术和工具，持续优化监控策略，以确保系统的可靠性和性能始终满足业务需求。

通过全面了解监控的各个方面，包括运营意识、指标定义、工具使用和流程设计等，我们可以构建一个高效、可靠的监控体系，为 IT 系统的稳定运行提供有力保障。同时，关注未来趋势，不断创新和改进，将有助于我们在不断变化的技术环境中保持领先地位。