你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关设计和创建监视系统的建议
适用于此 Azure 精心构建的框架卓越运营清单建议：
| OE:07 | 设计和实施监视系统，以验证设计选择并影响未来的设计和业务决策。 此系统捕获并公开从工作负荷的基础结构和代码发出的操作遥测、指标和日志。 |
|---|
相关指南： 检测应用程序的建议
本指南介绍设计和创建监视系统的建议。 为了有效地监视工作负荷的安全性、性能和可靠性，需要一个包含其自己的堆栈的综合系统，为所有监视、检测和警报功能提供基础。
定义
| 术语 | 定义 |
|---|---|
| 日志 | 记录的系统事件。 日志可以包含结构化或自由格式文本格式的不同类型的数据。 它们包含时间戳。 |
| 指标 | 定期收集的数值。 指标描述特定时间系统的某些方面。 |
关键设计策略
若要为工作负荷实施全面的监视系统设计，请遵循以下核心原则：
无论何时可行，都可以利用平台提供的监视工具，这些工具通常需要很少的配置，并且可以提供对工作负荷的深入见解，否则可能难以实现。
从整个工作负荷堆栈收集日志和指标。 应将所有基础结构资源和应用程序功能配置为生成标准化、有意义的数据，并且需要收集数据。
将收集的数据存储在标准化、可靠且安全的存储解决方案中。
处理存储的数据，以便可以通过分析和可视化解决方案处理这些数据。
分析已处理的数据，以准确确定工作负荷的状态。
在针对工作负荷团队和其他利益干系人有意义的仪表板或报表中可视化工作负荷的状态。
配置可操作的警报和其他自动响应，以智能定义的阈值，以在出现问题时通知工作负荷团队。
在总体工作负荷测试实践中包括监视和警报系统。
确保监视和警报系统处于持续改进的范围内。 生产中的应用程序和基础结构行为提供了持续学习机会。 将这些课程纳入监视和警报设计。
将收集和分析 的监视数据与系统流和用户流 相关联，以将流的运行状况与工作负荷的总体运行状况相关联。 分析流方面的数据将有助于将可观测性策略与 运行状况模型保持一致。
应尽可能自动执行监视系统的所有功能，并且它们应每天都持续运行。
此工作流管道演示了监视系统：
收集检测数据
注意
需要检测应用程序才能启用日志记录。 有关详细信息，请参阅 检测指南。
应将所有工作负荷组件（无论是基础结构资源还是应用程序功能）配置为捕获遥测数据和/或日志和指标等事件。
日志主要用于检测和调查异常。 通常，日志由工作负荷组件生成，然后通过自动化发送到监视平台或由监视平台拉取。
指标主要用于 生成运行状况模型 并确定工作负荷性能和可靠性的趋势。 指标还可用于识别客户使用行为的趋势。 这些趋势有助于从客户角度指导有关改进的决策。 通常，指标在监视平台中定义，监视平台和其他工具轮询工作负荷以捕获指标。
应用程序数据
对于应用程序，收集服务可以是应用程序性能管理（APM）工具，该工具可以从生成检测数据的应用程序中自主运行。 启用 APM 后，可以实时和历史上清楚地了解重要指标。 使用适当的日志记录级别。 详细日志记录可能会产生大量成本。 根据环境设置日志级别。 例如，较低环境不需要与生产相同的详细级别。
应用程序日志支持端到端的应用程序生命周期。 日志记录对于了解应用程序如何在各种环境中运行、哪些事件以及它们发生的条件至关重要。
建议跨所有主要环境收集应用程序日志和事件。 如果这样做是可行的，请为每个环境使用不同的数据存储来尽可能多地分隔环境之间的数据。 使用筛选器来确保非关键环境不会使生产日志的解释复杂化。 最后，整个应用程序的相应日志条目应为其各自的事务捕获相关 ID。
应使用计算机可读数据点（而不是非结构化字符串类型）在结构化数据类型中捕获应用程序事件。 使用已知架构的结构化格式可以更轻松地解析和分析日志。 此外，可以轻松为结构化数据编制索引和进行搜索，并且可以大大简化报表。
数据应采用独立于计算机、操作系统或网络协议的不可知格式。 例如，以自描述格式（如 JSON、MessagePack 或 Protobuf）而不是 ETL/ETW 发出信息。 标准格式使系统能够构造处理管道。 可以轻松集成以标准格式读取、转换和发送数据的组件。
基础结构数据
对于工作负荷中的基础结构资源，请确保同时收集日志和指标。 对于基础结构即服务（IaaS）系统，除了与工作负荷运行状况相关的指标外，还捕获 OS、应用程序层和诊断日志。 对于平台即服务（PaaS）资源，你可能受限于捕获与底层基础结构相关的日志，但请确保除了与工作负荷运行状况相关的指标外，还可以捕获诊断日志。
尽可能多地从云平台收集日志。 你可能能够收集订阅的活动日志和管理平面的诊断日志。
收集策略
避免从每个组件手动检索遥测数据。 将数据移动到中心位置并将其合并到该位置。 对于多区域解决方案，建议先逐区域收集、合并和存储数据，然后将区域数据聚合到单个中央系统。
权衡：请注意，具有区域和集中式数据存储会产生成本影响。
要优化带宽的使用，请根据数据的重要性进行优先级排序。 可以批量传输不太紧急的数据。 但是，此数据不得无限期延迟，尤其是在它包含时间敏感信息时。
收集服务可以使用两个主要模型来收集检测数据：
拉取模型：主动从应用程序的每个实例的各种日志和其他源中检索数据。
推送模型：被动地等待从构成应用程序每个实例的组件发送数据。
监视代理
可以在拉取模型中使用监视代理。 代理在单独的进程中与应用程序的每个实例一起在本地运行，定期拉取数据并将信息直接写入应用程序的所有实例共享的常见存储。
注意
监视代理非常适合用于捕获从数据源自然提取的检测数据。 它适用于在单个位置的有限数量的节点上运行的小型应用程序。 示例包括 SQL Server 动态管理视图中的信息或Azure 服务总线队列的长度。
性能注意事项
复杂且高度可缩放的应用程序可能会生成大量数据。 数据量很容易使可用于单个中心位置的 I/O 带宽不堪重负。 遥测解决方案不能成为瓶颈，并且必须随着系统的扩展而扩展。 理想情况下，如果系统的一部分发生故障，解决方案应包含一定程度的冗余，以减少丢失重要监视信息（例如审核或计费数据）的风险。
缓冲检测数据的一种方法是使用队列：
在此体系结构中，数据收集服务将数据发布到队列。 消息队列合适，因为它提供“至少一次”语义，有助于确保在发布队列数据后不会丢失。 可以使用单独的辅助角色实现存储写入服务。 可以使用 优先级队列模式 来实现此体系结构。
为实现可伸缩性，可以运行存储写入服务的多个实例。 如果正在监视大量事件或大量数据点，则可以使用Azure 事件中心将数据调度到其他计算实例进行处理和存储。
合并策略
从应用程序的单个实例收集的数据提供该实例的运行状况和性能的本地化视图。 若要评估系统的整体运行状况，需要从本地视图中合并数据的某些方面。 可以在存储数据后执行此操作，但在某些情况下，可以在收集数据时执行此操作。
通过独立的数据合并服务传递检测数据，此服务可以合并数据，并可充当筛选器和清理进程。 例如，可以合并包含相同关联信息（如活动 ID）的检测数据。 （用户可能会在一个节点上启动业务操作，然后在第一个节点发生故障或由于配置负载均衡的方式而转移到另一个节点。此过程还可以检测和删除任何重复的数据。 （如果遥测服务使用消息队列将检测数据推送到存储，则可能发生重复。
存储用于查询和分析的数据
选择存储解决方案时，请考虑数据类型、数据的使用方式以及所需的紧急程度。
注意
将单独的存储解决方案用于非生产环境和生产环境，以确保来自每个环境的数据易于识别和管理。
存储技术
考虑一种多边形持久性方法，其中不同类型的信息存储在最适合每种类型使用方式的技术中。
例如，可通过类似的方式访问Azure Blob 存储和 Azure 表存储。 但是，可以对其执行的操作有所不同，它们持有的数据粒度也不同。 如果需要运行更多的分析操作或需要对数据使用全文搜索功能，可能更适合使用数据存储，因为它提供的功能已针对特定类型的查询和数据访问进行优化。 例如：
性能计数器数据可以存储在 SQL 数据库中以启用即时分析。
最好在 Azure Monitor 日志或 Azure 数据资源管理器中存储跟踪日志。
可以将安全信息存储在 HDFS 解决方案中。
可能会出于多个目的而需要同一检测数据。 例如，可以使用性能计数器来提供一段时间内系统性能的历史视图。 此信息也可能与其他使用情况数据结合来生成客户帐单信息。 在这些情况下，同一数据可能会发送到多个目标，例如文档数据库，该数据库可以是用于保存计费信息的长期存储，也可以发送到多维存储来处理复杂的性能分析。
请务必启用功能，防止意外删除数据，例如资源锁和软删除。
此外，请确保使用基于角色的访问控制来保护对存储的访问，以帮助确保只有需要访问数据的个人才能执行此操作。
合并服务
你可以实现另一个服务，该服务定期从共享存储、分区和按其用途筛选数据，然后将其写入适当的数据存储集。
另一种方法是在合并和清理过程中包含此功能，并在检索到数据时直接将它写入这些存储，而不是将它存储在中间共享存储区域。
每一种方法有其优点和缺点。 实现单独的分区服务可减少合并和清理服务上的负载，并在必要时至少重新生成部分已分区数据（具体取决于共享存储中保留的数据量）。 但是，此方法会消耗其他资源。 此外，在从每个应用程序实例接收检测数据与将此数据转换成有用信息之间可能出现延迟。
查询注意事项
考虑需要数据的紧急程度。 生成警报的数据必须快速访问，因此应该保留在快速数据存储中，并编制索引或结构化以优化警报系统运行的查询。 在某些情况下，收集服务可能需要在本地格式化和保存数据，以便警报系统的本地实例可以快速发送通知。 同一数据可以发送到前面图表中显示的存储写入服务，如果出于其他目的而需要它，则集中存储。
数据保留注意事项
在某些情况下，在处理和传输数据后，可以删除本地存储的原始原始源数据。 在其他情况下，可能有必要保存原始信息，或者这样做会有用。 例如，你可能希望保留生成的数据，以便在原始表单中提供调试，但在解决任何 bug 后迅速放弃它。
性能数据通常具有更长的生存期，因此可以使用这些数据来发现性能趋势和容量规划。 此数据的合并视图通常在一段有限的时间内保持联机以实现快速访问。 过了这段时间后，可以将其存档或丢弃。
存储能够找出长期趋势的历史数据很有用。 你也许能够向下采样数据，以降低其分辨率并节省存储成本，而不是完全保存旧数据。 例如，可以合并一个多月的数据，而不是逐分钟保存性能指标，以形成按小时查看的数据。
针对客户计量和计费收集的数据可能需要无限期保存。 此外，法规要求可能规定需要存档和保存为审核和安全收集的信息。 此数据也很机密，因此可能需要加密或进行保护，以防止篡改。 不应记录可能用于提交标识欺诈的用户密码或其他信息。 在存储数据之前，应从数据中清理这些详细信息。
若要确保遵守法律和法规，请尽量减少存储任何可识别的信息。 如果需要存储可识别的信息，请确保在设计解决方案时考虑到允许个人请求删除其信息的要求。
分析数据以了解工作负荷的运行状况
从各种数据源收集数据后，对其进行分析以评估系统的整体福祉。 对于此分析，请清楚地了解：
如何根据定义的 KPI 和性能指标来构建数据。
如何关联在不同指标和日志文件中捕获的数据。 跟踪事件序列并有助于诊断问题时，此关联非常重要。
在大多数情况下，体系结构的每个组件的数据都是在本地捕获的，然后准确结合由其他组件生成的数据。
例如，三层应用程序可能具有：
允许用户连接到网站的演示层。
托管一组处理业务逻辑的微服务的中间层。
存储与操作关联的数据的数据库层。
单个业务操作的使用情况数据可能跨越所有三个层。 此信息必须关联在一起，以提供操作的资源和处理使用情况的整体视图。 关联可能涉及在数据库层上的一些数据预处理和筛选。 在中间层上，聚合和格式设置是常见任务。
建议
关联应用程序级别和资源级日志。 评估两个级别的数据，以优化问题检测和这些问题的故障排除。 可以在单个数据接收器中聚合数据，或者利用跨两个级别查询事件的方法。 建议使用统一的解决方案（如 Azure Log Analytics）来聚合和查询应用程序级和资源级日志。
为冷分析定义存储的明确保留时间。 建议这种做法在特定时间段内启用历史分析。 它还可以帮助你控制存储成本。 实现确保数据存档到更便宜的存储和聚合数据以用于长期趋势分析的过程。
分析长期趋势，预测操作问题。 评估长期数据以形成操作策略，并预测可能发生的操作问题以及何时发生。 例如，你可能会注意到，平均响应时间随着时间推移而缓慢增加，并接近最大目标。
有关这些建议的详细指南，请参阅 分析云应用程序的监视数据。
可视化工作负荷运行状况报告
仪表板
可视化数据的最常见方法是使用仪表板，这些仪表板可以将信息显示为一系列图表或图形，或者以某种其他视觉形式显示信息。 这些项可以参数化，分析师可以选择重要参数（如时间段）以用于任何特定情况。
使仪表板与 运行状况模型 保持一致，以便它们指示工作负荷的工作负荷或组件何时正常运行、降级或运行不正常。
要使仪表板系统有效工作，它必须对工作负荷团队有意义。 直观显示与工作负荷运行状况相关的信息，以及该运行状况也是可操作的。 当工作负荷或组件降级或运行不正常时，工作负荷团队成员应能够轻松确定问题的来源，并开始其纠正措施或调查。 相反，包括不可操作或与工作负荷运行状况无关的信息，可能会使仪表板变得不必要复杂和令人沮丧，而团队成员试图从可操作数据中辨别背景噪音。
你可能拥有针对利益干系人或开发人员的仪表板，这些仪表板仅显示他们找到的相关工作负载的数据。 确保工作负荷团队了解其他团队感兴趣的数据点类型，并在共享仪表板之前预览仪表板，以检查其清晰度。 为利益干系人提供有关工作负荷的仪表板是让他们了解工作负荷运行状况的好方法，但如果利益干系人无法清楚地了解他们看到的数据，则可能会适得其反。
良好的仪表板不只是显示信息。 它还使分析师能够就这些信息提出即兴的问题。 某些系统为操作员提供了管理工具用于完成这些任务和浏览底层数据。 相反，根据用于保存信息的存储库，可以直接查询数据或将其导入到 Excel 等工具，以便进一步分析和报告。
注意
限制对授权人员的仪表板访问。 有关仪表板的信息可能具有商业敏感性。 还应保护基础数据，以防止用户更改它。
正在报告
报告用于生成系统的整体视图。 它可能包含历史数据和当前信息。 报告要求划分为两大类：操作报告和安全报告。
操作报告通常包括以下内容：
聚合统计信息，用于了解指定时间范围内整个系统或指定子系统的资源利用率。
识别整个系统或指定子系统在指定时间段内的资源使用趋势。
监视整个系统或指定子系统在指定时间段发生的异常。
确定应用程序对已部署资源的效率，并了解资源量及其关联的成本是否可以降低，而不会影响不必要的性能。
安全报告跟踪客户的系统使用情况。 其中可能包括：
审核用户操作。 此任务需要记录每个用户完成的各个请求以及日期和时间。 应构建数据，使管理员能够快速重新构造用户在指定时间段内完成的操作序列。
按用户跟踪资源使用情况。 此任务需要记录来自用户的每个请求如何访问组成系统的各种资源，以及多长时间。 管理员可以使用此数据根据用户生成一个可能用于计费的指定时间段的利用率报告。
在许多情况下，批处理进程可以根据定义的计划生成报告。 正常情况下，延迟不是问题。 你还应该有批处理进程，可以根据需要自发生成报表。 例如，如果将数据存储在关系数据库中（如Azure SQL 数据库），则可以使用 SQL Server Reporting Services 等工具提取和格式化数据并将其呈现为一组报表。
定义关键事件的警报
为了帮助确保系统保持正常运行、响应和安全，请设置警报，以便操作员能够及时响应它们。 警报可以包含足够的上下文信息，帮助他们快速开始诊断活动。 警报可用于调用修正功能，例如 自动缩放或其他自我修复机制。 警报还可以通过提供预算和限制的可见性来实现成本感知。
建议
定义一个警报响应流程，以确定负责任的所有者和行动。
为明确定义的范围（资源类型和资源组）配置警报并调整详细程度以最大限度地减少噪音。
使用自动化警报解决方案（如 Splunk 或 Azure Monitor），而不是要求人们积极查找问题。
使用警报操作修正过程。 例如，自动创建票证以跟踪问题和解决方案。
跟踪区域中云平台服务的运行状况、有关中断的通信、计划内维护活动和其他运行状况公告。
阈值
当阈值超出时，系统会根据监视系统检测到的阈值生成警报。 确保设置的阈值通常提供足够的时间来实施对工作负荷的必要更改，以避免降级或中断。 例如，设置自动缩放阈值，以便在任何正在运行的系统变得不知所措之前启动缩放，达到降级的用户体验点。 根据过去在管理基础结构方面的经验分配的阈值，并通过在测试实践中执行的测试来验证这些阈值。
有关警报用例和其他注意事项的详细指南，请参阅 设计可靠的监视和警报策略。
Azure 便利化
Azure Monitor 是一个全面的监视解决方案，可用于收集、分析和响应来自云和本地环境的监视数据。
Log Analytics 是Azure 门户中的一种工具，可用于编辑和运行 Log Analytics 工作区中的数据的日志查询。
如果使用多个工作区，请参阅 Log Analytics 工作区 体系结构指南 ，了解最佳做法。
Application Insights 是 Azure Monitor 的扩展。 它提供 APM 功能。
Azure Monitor Insights 是针对特定 Azure 技术（如 VM、应用服务和容器）的高级分析工具。 这些工具是 Azure Monitor 和 Log Analytics 的一部分。
适用于 SAP 解决方案 的 Azure Monitor 是适用于在 Azure 上运行的 SAP 环境的 Azure 监视工具。
Azure Policy 可帮助你执行组织标准并大规模评估合规性。
相关链接
社区链接
- Azure Monitor 基线警报（AMBA）是警报定义的中心存储库， 客户和合作伙伴可以通过采用 Azure Monitor 来提高其可观测性体验。
卓越运营清单
请参阅完整的建议集。