监视和诊断指南

云中运行的分布式应用程序和服务本质上是构成许多移动部件的复杂软件片段。 在生产环境中，必须能够跟踪用户使用系统的方式、跟踪资源利用率，并通常监视系统的运行状况和性能。 可以使用本文中的信息作为诊断辅助，来检测和更正问题，同时帮助找出潜在的问题并避免其发生。

监视和诊断方案

可以使用监视来深入了解系统运行情况。 监视是维护服务质量目标的关键部分。 收集监视数据的常见方案包括：

• 确保系统保持正常运行。
• 跟踪系统及其组件元素的可用性。
• 保持性能，以确保系统吞吐量不会意外下降，因为工作量增加。
• 保证系统满足与客户建立的任何服务级别协议（SLA）。
• 保护系统、用户及其数据的隐私和安全性。
• 跟踪为审核或法规目的执行的作。
• 监视系统的日常使用情况，并发现可能导致问题（如果未解决问题）的趋势。
• 跟踪发生的问题，从初始报告到分析可能的原因、纠正、后续软件更新和部署。
• 跟踪作和调试软件版本。

以下部分更详细地介绍了这些方案。 每种方案的信息都采用以下格式进行讨论：

1. 方案的简要概述。
2. 此方案的典型要求。
3. 支持方案所需的原始检测数据，以及此信息的可能来源。
4. 如何分析和组合此原始数据以生成有意义的诊断信息。

运行状况监视

如果系统正在运行且能够处理请求，则系统正常。 运行状况监视的目的是生成系统当前运行状况的快照，以便可以验证系统的所有组件是否按预期运行。

运行状况监视要求

如果系统的任何部分被视为不正常，作员应快速（在几秒钟内）发出警报。 作员应能够确定系统的哪些部分正常运行，以及哪些部件遇到问题。 可以通过交通灯系统突出显示系统运行状况：

• 红色不正常（系统已停止）
• 部分运行状况为黄色（系统运行功能减少）
• 绿色，完全健康

全面的运行状况监视系统使作员能够向下钻取系统以查看子系统和组件的运行状况。 例如，如果整个系统被描述为部分正常，则作员应能够放大并确定当前不可用的功能。

数据源、检测和数据收集要求

可以生成支持运行状况监视所需的原始数据，原因如下：

• 跟踪用户请求的执行。 此信息可用于确定哪些请求成功、哪些请求失败以及每个请求需要多长时间。
• 综合用户监视。 此过程模拟用户执行的步骤，并遵循预定义的步骤系列。 应捕获每个步骤的结果。
• 记录异常、错误和警告。 此信息可以捕获为嵌入到应用程序代码中的跟踪语句，以及从系统引用的任何服务的事件日志中检索信息。
• 监视系统使用的任何第三方服务的运行状况。 此监视可能需要检索和分析这些服务提供的运行状况数据。 此信息可能采用多种格式。
• 终结点监视。 “可用性监视”部分更详细地介绍了此机制。
• 收集环境性能信息，例如后台 CPU 使用率或 I/O（包括网络）活动。

分析运行状况数据

运行状况监视的主要重点是快速指示系统是否正在运行。 如果检测到关键组件不正常，则即时数据的热分析可能会触发警报。 （例如，它无法响应连续的一系列 ping。然后，作员可以采取适当的纠正措施。

更高级的系统可能包括一个预测元素，用于对最近和当前工作负荷执行冷分析。 冷分析可以发现趋势，并确定系统是否可能保持正常运行，或者系统是否需要额外的资源。 此预测元素应基于关键性能指标，例如：

• 针对每个服务或子系统的请求速率。
• 这些请求的响应时间。
• 流入和流出每个服务的数据量。

如果任何指标的值超过定义的阈值，系统可能会引发警报，以启用作员或自动缩放（如果可用），以采取维护系统运行状况所需的预防性作。 这些作可能涉及添加资源、重启一个或多个失败的服务，或将限制应用于低优先级请求。

可用性监视

真正正常的系统要求组成系统的组件和子系统都可用。 可用性监视与运行状况监视密切相关。 但是，虽然运行状况监视提供了系统当前运行状况的即时视图，但可用性监视涉及跟踪系统的可用性及其组件，以生成有关系统运行时间的统计信息。

在许多系统中，某些组件（例如数据库）配置为内置冗余，以允许在发生严重故障或连接丢失时快速故障转移。 理想情况下，用户不应意识到发生了此类故障。 但是，从可用性监视的角度来看，必须收集尽可能多的有关此类失败的信息，以确定原因并采取纠正措施以防止其重复发生。

跟踪可用性所需的数据可能取决于许多较低级别的因素。 其中许多因素可能特定于应用程序、系统和环境。 有效的监视系统捕获与这些低级别因素相对应的可用性数据，然后聚合它们，以全面了解系统。 例如，在电子商务系统中，使客户能够下订单的业务功能可能取决于存储订单详细信息的存储库，以及处理支付这些订单的货币交易的支付系统。 因此，系统的订单放置部分的可用性是存储库和付款子系统的可用性功能。

可用性监视要求

作员还应能够查看每个系统和子系统的历史可用性，并使用此信息来发现可能导致一个或多个子系统定期失败的任何趋势。 （服务是否在与高峰处理时间相对应的特定时间开始失败？）

监视解决方案应提供每个子系统的可用性或不可用的即时和历史视图。 当一个或多个服务发生故障或用户无法连接到服务时，它还应该能够快速向作员发出警报。 这不仅监视每个服务，而且还检查每个用户在尝试与服务通信时这些作失败时执行的作。 在某种程度上，连接失败程度正常，可能是由于暂时性错误造成的。 但是，允许系统针对在特定时间段内发生的指定子系统的连接失败数发出警报可能很有用。

数据源、检测和数据收集要求

与运行状况监视一样，由于综合用户监视和记录可能发生的任何异常、故障和警告，可以生成支持可用性监视所需的原始数据。 此外，可以从执行终结点监视获取可用性数据。 应用程序可以公开一个或多个运行状况终结点，每次测试对系统中某个功能区域的访问。 监视系统可以按照定义的计划对每个终结点执行 ping作，并收集结果（成功或失败）。

必须记录所有超时、网络连接失败和连接重试尝试。 所有数据都应加时间戳。

分析可用性数据

检测数据必须聚合并关联以支持以下类型的分析：

• 系统和子系统的即时可用性。
• 系统和子系统的可用性故障率。 理想情况下，作员应该能够将故障与特定活动相关联：系统发生故障时发生了什么情况？
• 系统或任何子系统在任何指定时间段内故障率的历史视图，以及发生故障时系统（例如用户请求数）上的负载。
• 系统或任何子系统不可用的原因。 例如，原因可能是服务未运行、连接丢失、已连接但超时以及已连接但返回错误。

可以使用以下公式计算服务在一段时间内的可用性百分比：

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

这对于 SLA 用途非常有用。 （本指南稍后将更详细地介绍 SLA 监视 。 停机时间 的定义取决于服务。 例如，Visual Studio Team Services 生成服务将停机时间定义为生成服务不可用的时间段（总累计分钟数）。 如果生成服务的所有连续 HTTP 请求在一分钟内执行客户启动的作导致错误代码或不返回响应，则被视为不可用。

性能监视

由于系统受到越来越多的压力（通过增加用户数量），这些用户访问的数据集的大小会增大，并且一个或多个组件发生故障的可能性会更大。 组件故障通常先于性能下降。 如果能够检测到这种减少，可以采取主动步骤来纠正这种情况。

系统性能取决于多种因素。 每个因素通常通过关键绩效指标（KPI）来度量，例如每秒数据库事务数或在特定时间范围内成功提供服务的网络请求量。 其中一些 KPI 可能作为特定的性能度量值提供，而其他 KPI 可能派生自指标的组合。

性能监视要求

若要检查系统性能，作员通常需要查看包括：

• 用户请求的响应速率。
• 并发用户请求数。
• 网络流量。
• 正在完成业务交易的费率。
• 请求的平均处理时间。

它还有助于提供使作员能够帮助发现相关性的工具，例如：

• 并发用户数与请求延迟时间（用户发送请求后开始处理请求所需的时间）。
• 并发用户数与平均响应时间（启动处理后完成请求所需的时间）。
• 请求量与处理错误数。

除了此高级功能信息之外，作员应能够获取系统中每个组件性能的详细视图。 此数据通常通过低级别性能计数器提供，这些计数器跟踪信息，例如：

• 内存利用率。
• 线程数。
• CPU 处理时间。
• 请求队列长度。
• 磁盘或网络 I/O 速率和错误。
• 写入或读取的字节数。
• 中间件指示器，如队列长度。

所有可视化效果都应允许作员指定时间段。 显示的数据可能是当前情况的快照或性能的历史视图。

作员应能够根据任何指定时间间隔内任何指定值的任何性能度量值引发警报。

数据源、检测和数据收集要求

可以通过监视用户请求到达并通过系统时监视请求的进度来收集高级性能数据（吞吐量、并发用户数、业务事务数、错误率等）。 这涉及到将跟踪语句合并到应用程序代码的关键点，以及计时信息。 应使用足够的数据捕获所有故障、异常和警告，以便将它们与导致故障的请求相关联。 Internet Information Services （IIS） 日志是另一个有用的源。

如果可能，还应捕获应用程序使用的任何外部系统的性能数据。 这些外部系统可能提供自己的性能计数器或其他功能来请求性能数据。 如果无法执行此作，请记录对外部系统发出的每个请求的开始时间和结束时间等信息，以及作的状态（成功、失败或警告）。 例如，可以使用秒表方法来计时请求：在请求启动时启动计时器，然后在请求完成时停止计时器。

系统中各个组件的低级别性能数据可能通过 Windows 性能计数器和 Azure 诊断等功能和服务提供。

分析性能数据

大部分分析工作都由用户请求类型或每个请求发送到的子系统或服务聚合性能数据组成。 用户请求的示例是将商品添加到购物车或在电子商务系统中执行结帐过程。

另一个常见要求是汇总所选百分位中的性能数据。 例如，作员可以确定 99% 的请求的响应时间、95% 的请求和 70% 的请求。 可能为每个百分位设置了 SLA 目标或其他目标。 应近乎实时地报告正在进行的结果，以帮助检测即时问题。 出于统计目的，结果还应在较长时间内聚合。

对于影响性能的延迟问题，作员应能够通过检查每个请求执行的每个步骤的延迟来快速识别瓶颈的原因。 因此，性能数据必须提供一种将每个步骤的性能度量值关联起来的方法，以将它们绑定到特定请求。

根据可视化要求，生成和存储包含原始数据视图的数据多维数据集可能很有用。 此数据多维数据集可以允许对性能信息进行复杂的即席查询和分析。

安全监视

包含敏感数据的所有商业系统都必须实现安全结构。 安全机制的复杂性通常是数据敏感度的功能。 在要求用户进行身份验证的系统中，应记录：

• 无论登录尝试失败还是成功，所有登录尝试都会失败。
• 通过身份验证的用户执行的所有作以及访问的所有资源的详细信息。
• 当用户结束会话并注销时。

监视可能有助于检测系统上的攻击。 例如，大量失败的登录尝试可能表示暴力攻击。 请求意外激增可能是分布式拒绝服务 （DDoS） 攻击的结果。 必须准备好监视对所有资源的所有请求，而不考虑这些请求的来源。 具有登录漏洞的系统可能会意外地向外部公开资源，而无需用户实际登录。

安全监视要求

安全监视的最关键方面应使作员能够快速：

• 检测未经身份验证的实体尝试入侵。
• 确定实体对尚未向其授予访问权限的数据执行作的尝试。
• 确定系统或系统的某些部分是否受到外部或内部的攻击。 （例如，经过恶意身份验证的用户可能正在尝试关闭系统。

若要支持这些要求，应在以下情况下通知作员：

• 一个帐户在指定时间段内进行重复失败的登录尝试。
• 一个经过身份验证的帐户在指定时间段内反复尝试访问禁止的资源。
• 在指定时间段内发生大量未经身份验证或未经授权的请求。

提供给作员的信息应包括每个请求的源的主机地址。 如果安全冲突经常来自特定地址范围，则可能会阻止这些主机。

维护系统安全性的关键部分是能够快速检测偏离常规模式的作。 可以直观显示失败或成功的登录请求数等信息，以帮助检测活动是否在异常时间出现峰值。 （此活动的示例是用户在凌晨 3：00 登录，并在工作日上午 9：00 开始时执行大量作）。 此信息还可用于帮助配置基于时间的自动缩放。 例如，如果作员观察到大量用户在特定时间定期登录，作员可以安排启动其他身份验证服务来处理工作量，然后在高峰通过时关闭这些附加服务。

数据源、检测和数据收集要求

安全性是大多数分布式系统的一个包罗万象的方面。 相关数据可能在整个系统中的多个点生成。 应考虑采用安全信息和事件管理（SIEM）方法来收集应用程序、网络设备、服务器、防火墙、防病毒软件和其他入侵防护元素引发的事件产生的安全相关信息。

安全监视可以从不属于应用程序的工具合并数据。 这些工具可以包括用于识别外部机构端口扫描活动的实用工具，或检测尝试获取对应用程序和数据的未经身份验证的访问的网络筛选器。

在所有情况下，收集的数据都必须使管理员能够确定任何攻击的性质并采取适当的对策。

分析安全数据

安全监视的一项功能是数据从中出现的各种源。 不同的格式和细节级别通常需要对捕获的数据进行复杂的分析，以将其关联到一致的信息线程中。 除了最简单的情况（例如检测大量失败的登录，或反复尝试获得对关键资源的未经授权的访问），可能无法执行任何复杂的安全数据自动处理。 相反，最好将此数据（时间戳为时间戳）写入安全存储库，以允许专家手动分析。

SLA 监视

许多支持付费客户的商业系统以 SLA 的形式保证系统的性能。 实质上，SLA 表示系统可以在商定的时间段内处理定义的工作量，而不会丢失关键信息。 SLA 监视涉及确保系统能够满足可衡量的 SLA。

SLA 通常按以下方式定义：

• 总体系统可用性。 例如，组织可能保证系统在 99.9% 的时间内可用。 这相当于每年的停机时间不超过 9 小时，或每周大约 10 分钟。
• 作吞吐量。 此方面通常表示为一个或多个高水线，例如保证系统最多可以支持 100,000 个并发用户请求或处理 10,000 个并发业务事务。
• 作响应时间。 系统还可以保证处理请求的速率。 例如，99% 的业务事务将在 2 秒内完成，并且任何一个事务都不会超过 10 秒。

SLA 监视要求

在最高级别，作员应能够一目了然地确定系统是否满足商定的 SLA。 如果没有，作员应能够向下钻取并检查基础因素，以确定不合格性能的原因。

可直观描述的典型高级指示器包括：

• 服务运行时间百分比。
• 应用程序吞吐量（以每秒成功事务或作数计算）。
• 成功/失败的应用程序请求数。
• 应用程序和系统故障数、异常和警告数。

所有这些指标都应能够按指定时间段进行筛选。

云应用程序可能包含许多子系统和组件。 运算符应能够选择高级指示器，并查看它如何从基础元素的运行状况构成。 例如，如果整个系统的运行时间低于可接受的值，作员应能够放大并确定导致此故障的元素。

出于警报目的，如果任何高级指示器超过指定的阈值，系统应能够引发事件。 构成高级指示器的各种因素的较低级别详细信息应作为上下文数据提供给警报系统。

数据源、检测和数据收集要求

支持 SLA 监视所需的原始数据类似于性能监视所需的原始数据，以及运行状况和可用性监视的某些方面。 （有关更多详细信息，请参阅这些部分。可以通过以下方式捕获此数据：

• 执行终结点监视。
• 记录异常、错误和警告。
• 跟踪用户请求的执行。
• 监视系统使用的任何第三方服务的可用性。
• 使用性能指标和计数器。

所有数据都必须计时和时间戳。

分析 SLA 数据

必须聚合检测数据才能生成系统整体性能的图片。 聚合数据还必须支持向下钻取，以便检查基础子系统的性能。 例如，应该能够：

• 计算指定时间段内的用户请求总数，并确定这些请求的成功和失败率。
• 合并用户请求的响应时间，以生成系统响应时间的总体视图。
• 分析用户请求的进度，将请求的总体响应时间分解为该请求中各个工作项的响应时间。
• 将系统的总体可用性确定为任何特定时间段的运行时间百分比。
• 分析系统中各个组件和服务的时间可用性百分比。 这可能涉及分析第三方服务生成的日志。

许多商业系统需要针对指定时间段（通常是一个月）根据商定的 SLA 报告实际性能数据。 如果在此期间未满足 SLA，此信息可用于计算客户的信用额度或其他形式的还款。 可以使用 “分析可用性数据”部分中介绍的技术来计算服务的可用性。

出于内部目的，组织还可以跟踪导致服务失败的事件的数量和性质。 了解如何快速解决这些问题或完全消除这些问题将有助于减少停机时间并满足 SLA。

审计

根据应用程序的性质，可能有法定或其他法律法规指定审核用户作和记录所有数据访问的要求。 审核可以提供将客户链接到特定请求的证据。 不可否认性是许多电子商务系统中的一个重要因素，可帮助维护客户与负责应用程序或服务的组织之间的信任。

审核要求

分析师必须能够跟踪用户正在执行的业务作序列，以便重新构造用户的作。 这可能需要只是记录问题，或作为法医调查的一部分。

审核信息高度敏感。 它可能包含标识系统用户的数据以及他们正在执行的任务。 因此，审核信息很可能采用仅供受信任的分析师使用的报表形式，而不是支持向下钻取图形作的交互式系统。 分析师应能够生成一系列报表。 例如，报表可能会列出指定时间段内发生的所有用户活动、详细说明单个用户的活动的计时顺序，或列出针对一个或多个资源执行的作序列。

数据源、检测和数据收集要求

用于审核的主要信息来源可能包括：

• 管理用户身份验证的安全系统。
• 跟踪记录用户活动的日志。
• 跟踪所有可识别和无法识别的网络请求的安全日志。

审核数据的格式及其存储方式可能由法规要求驱动。 例如，可能无法以任何方式清理数据。 （必须以原始格式记录它。必须保护对保存存储库的访问，以防止篡改。

分析审核数据

分析师必须能够以原始形式完全访问原始数据。 除了生成常见审核报告的要求之外，用于分析此数据的工具可能专用化，并且保留在系统外部。

使用情况监视

使用情况监视跟踪应用程序的功能和组件的使用方式。 作员可以使用收集的数据来：

• 确定哪些功能被大量使用，并确定系统中的任何潜在热点。 高流量元素可能受益于功能分区，甚至复制以更均匀地分散负载。 作员还可以使用此信息来确定哪些功能不常使用，并且可能是在系统的未来版本中停用或更换的候选项。

• 获取有关正常使用中系统作事件的信息。 例如，在电子商务网站中，可以记录有关交易数和负责交易的客户数量的统计信息。 随着客户数量的增长，此信息可用于容量规划。

• 检测（可能间接）用户对系统的性能或功能的满意度。 例如，如果电子商务系统中大量客户定期放弃购物车，这可能是由于结帐功能出现问题。

• 生成计费信息。 商业应用程序或多租户服务可能会向客户收取他们使用的资源费用。

• 强制实施配额。 如果多租户系统中的用户在指定时间段内超过其付费的处理时间或资源使用量配额，则可以限制其访问或限制处理。

使用情况监视要求

若要检查系统使用情况，作员通常需要查看包括：

• 每个子系统处理并定向到每个资源的请求数。
• 每个用户正在执行的工作。
• 每个用户占用的数据存储量。
• 每个用户访问的资源。

运算符还应能够生成图形。 例如，图形可能会显示资源最多的用户，或者最常访问的资源或系统功能。

数据源、检测和数据收集要求

可以在相对较高的级别执行使用情况跟踪。 它可以记下每个请求的开始和结束时间以及请求的性质（读取、写入等，具体取决于相关资源）。 可以通过以下方式获取此信息：

• 跟踪用户活动。
• 捕获测量每个资源利用率的性能计数器。
• 监视每个用户的资源消耗量。

出于计量目的，还需要能够确定哪些用户负责执行哪些作以及这些作使用的资源。 收集的信息应足够详细，以实现准确的计费。

问题跟踪

如果系统中发生意外事件或行为，客户和其他用户可能会报告问题。 问题跟踪涉及管理这些问题，将这些问题与解决系统中任何根本问题的努力相关联，并告知客户可能的解决方法。

问题跟踪要求

作员通常使用单独的系统执行问题跟踪，使系统能够记录和报告用户报告的问题的详细信息。 这些详细信息可能包括用户尝试执行的任务、问题的症状、事件序列以及发出的任何错误或警告消息。

数据源、检测和数据收集要求

问题跟踪数据的初始数据源是首先报告问题的用户。 用户可以提供其他数据，例如：

• 故障转储（如果应用程序包含在用户的桌面上运行的组件）。
• 屏幕快照。
• 发生错误的日期和时间，以及任何其他环境信息，例如用户的位置。

此信息可用于帮助调试工作，并帮助为软件的未来版本构建积压工作。

分析问题跟踪数据

不同的用户可能会报告相同的问题。 问题跟踪系统应关联常见报告。

应根据每个问题报告记录调试工作进度。 解决问题后，可以通知客户解决方案。

如果用户报告问题跟踪系统中存在已知解决方案的问题，作员应能够立即通知用户解决方案。

跟踪作和调试软件版本

当用户报告问题时，用户通常只知道它对其作具有的直接影响。 用户只能将自己的体验结果报告给负责维护系统的作员。 这些体验通常只是一个或多个根本问题的明显症状。 在许多情况下，分析师需要挖掘基础作的时序，以确定问题的根本原因。 此过程称为 根本原因分析。

跟踪和调试的要求

对于跟踪意外事件和其他问题，监视数据提供足够的信息，使分析人员能够追溯到这些问题的来源，并重新构造所发生的事件序列至关重要。 此信息必须足以让分析师诊断任何问题的根本原因。 然后，开发人员可以进行必要的修改，以防止它们定期进行。

数据源、检测和数据收集要求

故障排除可能涉及跟踪作为作的一部分调用的所有方法（及其参数），以在客户发出特定请求时构建描述系统逻辑流的树。 系统因此流而生成的异常和警告需要捕获和记录。

为了支持调试，系统可以提供挂钩，使作员能够在系统中的关键点捕获状态信息。 或者，系统可以在所选作进度时提供详细的分步信息。 在此级别的详细信息中捕获数据可能会对系统施加额外的负载，并且应该是一个临时过程。 作员主要在发生异常的一系列事件且难以复制时，或者当将一个或多个元素新版本发布到系统中时，需要仔细监视以确保元素按预期运行。

监视和诊断管道

监视大规模分布式系统是一个很大的难题。 上一部分所述的每个方案不一定是隔离的。 在监视和诊断数据中，每个情况都可能存在明显的重叠，尽管可能需要以不同的方式处理和显示这些数据。 出于这些原因，应全面了解监视和诊断。

可以将整个监视和诊断过程设想为包含图 1 所示阶段的管道。

图 1 - 监视和诊断管道中的阶段。

图 1 突出显示了用于监视和诊断的数据如何来自各种数据源。 检测和收集阶段涉及确定需要捕获数据的源、确定要捕获的数据、捕获数据的方式以及如何设置此数据的格式，以便可以轻松检查这些数据。 分析/诊断阶段采用原始数据，并使用它来生成作员可用于确定系统状态的有意义的信息。 作员可以使用此信息来决定可能执行的作，然后将结果馈送回检测和收集阶段。 可视化/警报阶段阶段提供系统状态的易耗型视图。 它可以使用一系列仪表板以近乎实时的方式显示信息。 它可生成报表、图形和图表，以提供有助于识别长期趋势的数据的历史视图。 如果信息指示 KPI 可能超过可接受的边界，则此阶段还可以触发作员的警报。 在某些情况下，警报还可用于触发尝试采取纠正措施（例如自动缩放）的自动化过程。

请注意，这些步骤构成了一个连续流过程，其中阶段并行发生。 理想情况下，所有阶段都应动态配置。 在某些时候，尤其是在系统已新部署或遇到问题时，可能需要更频繁地收集扩展数据。 在其他情况下，应可以还原为捕获基本级别的基本基本信息，以验证系统是否正常运行。

此外，应将整个监视过程视为一种实时持续的解决方案，因为反馈会进行微调和改进。 例如，可以首先测量许多因素来确定系统运行状况。 随着时间的推移，分析可能会导致优化，因为放弃不相关的度量值，使你能够更准确地专注于所需的数据，同时最大程度地减少背景噪音。

监视和诊断数据的源

监视过程使用的信息可能来自多个源，如图 1 所示。 在应用程序级别，信息来自合并到系统代码中的跟踪日志。 开发人员应遵循一种标准方法，通过代码跟踪控制流。 例如，方法的条目可以发出一条跟踪消息，该消息指定方法的名称、当前时间、每个参数的值以及任何其他相关信息。 记录进入和退出时间也很有用。

应记录所有异常和警告，并确保保留任何嵌套异常和警告的完整跟踪。 理想情况下，还应捕获用于标识运行代码的用户以及活动相关性信息（在请求通过系统时跟踪请求） 的信息。 应该记录访问所有资源（如消息队列、数据库、文件和其他依赖服务）的尝试。 此信息可用于计量和审核目的。

许多应用程序使用库和框架来执行常见任务，例如访问数据存储或通过网络通信。 这些框架可以配置为提供自己的跟踪消息和原始诊断信息，例如事务速率和数据传输成功和失败。

运行应用程序的作系统可以是低级系统范围的信息的源，例如指示 I/O 速率、内存利用率和 CPU 使用率的性能计数器。 可能还会报告作系统错误（例如无法打开文件失败）。

还应考虑运行系统的基础基础结构和组件。 虚拟机、虚拟网络和存储服务都可以是重要的基础结构级性能计数器和其他诊断数据的源。

如果应用程序使用其他外部服务（例如 Web 服务器或数据库管理系统），这些服务可能会发布自己的跟踪信息、日志和性能计数器。 示例包括用于跟踪针对 SQL Server 数据库执行的跟踪作的 SQL Server 动态管理视图，以及用于记录对 Web 服务器发出的请求的 IIS 跟踪日志。

随着系统组件的修改和新版本的部署，必须能够将问题、事件和指标归因于每个版本。 此信息应关联回发布管道，以便快速跟踪特定版本的组件问题并得到纠正。

系统中的任何时间点都可能出现安全问题。 例如，用户可能尝试使用无效的用户 ID 或密码登录。 经过身份验证的用户可能会尝试获取对资源的未经授权的访问。 或者，用户可能会提供无效或过时的密钥来访问加密的信息。 应始终记录成功和失败请求的安全相关信息。

检测应用程序部分包含有关应捕获的信息的更多指导。 但是，可以使用各种策略来收集此信息：

• 应用程序/系统监视。 此策略在应用程序、应用程序框架、作系统和基础结构中使用内部源。 应用程序代码可以在客户端请求的生命周期内生成自己的监视数据。 应用程序可以包括跟踪语句，这些语句可能会根据情况进行选择性地启用或禁用。 也可以使用诊断框架动态注入诊断。 这些框架通常提供插件，这些插件可以附加到代码中的各种检测点，并捕获这些点的跟踪数据。

  此外，代码或底层基础结构可能会在关键点引发事件。 配置为侦听这些事件的监视代理可以记录事件信息。

• 真正的用户监视。 此方法记录用户与应用程序之间的交互，并观察每个请求和响应的流。 此信息可以有两倍的用途：它可用于计量每个用户的使用情况，并且可用于确定用户是否收到合适的服务质量（例如，快速响应时间、低延迟和最小错误）。 可以使用捕获的数据来识别最常发生故障的问题区域。 还可以使用数据来识别系统速度变慢的元素，可能是由于应用程序中的热点或其他某种形式的瓶颈。 如果仔细实施此方法，则可能可以重新构造用户流，以便进行调试和测试。

  重要

  应考虑通过监视真实用户捕获的数据高度敏感，因为它可能包含机密材料。 如果保存捕获的数据，请安全地存储它。 如果要将数据用于性能监视或调试目的，请先去除所有个人数据。

• 综合用户监视。 在此方法中，编写自己的测试客户端来模拟用户并执行可配置但典型的一系列作。 可以跟踪测试客户端的性能，以帮助确定系统的状态。 还可以使用测试客户端的多个实例作为负载测试作的一部分，以建立系统在压力下响应的方式，以及在这些条件下生成的监视输出类型。

  注释

  可以通过包括跟踪和时间执行方法调用以及应用程序的其他关键部分的代码来实现真实和综合用户监视。

• 分析。 此方法主要针对监视和提高应用程序性能。 它无需在实际和综合用户监视的功能级别运行，而是在应用程序运行时捕获较低级别的信息。 可以使用应用程序的执行状态定期采样来实现分析（确定应用程序在给定时间点运行的代码片段）。 还可以使用检测在重要时刻（例如方法调用的开始和结束）将探测插入代码，并记录调用方法的时间、时间以及每个调用花费的时间。 然后，可以分析此数据，以确定应用程序的哪些部分可能会导致性能问题。

• 终结点监视。 此方法使用应用程序专门公开的一个或多个诊断终结点来启用监视。 终结点提供应用程序代码的路径，并可以返回有关系统运行状况的信息。 不同的终结点可以专注于功能的各个方面。 可以编写自己的诊断客户端，用于向这些终结点发送定期请求并吸收响应。 有关详细信息，请参阅 运行状况终结点监视模式。

为了获得最大覆盖率，应结合使用这些技术。

检测应用程序

检测是监视过程的关键部分。 只有在首次捕获能够做出这些决策的数据时，才能对系统的性能和运行状况做出有意义的决策。 使用检测收集的信息应该足以让你评估性能、诊断问题并做出决策，而无需登录到远程生产服务器以手动执行跟踪（和调试）。 检测数据通常包括写入到跟踪日志的指标和信息。

如果应用程序使用 Windows 事件跟踪（ETW），则跟踪日志的内容可以是由应用程序写入的文本数据的结果，或者创建为跟踪事件生成的二进制数据的结果。 还可以从系统日志生成它们，这些日志记录基础结构部分（例如 Web 服务器）产生的事件。 文本日志消息通常设计为人可读，但它们也应采用一种格式编写，使自动化系统能够轻松分析它们。

还应对日志进行分类。 不要将所有跟踪数据写入单个日志，但使用单独的日志记录系统不同作方面的跟踪输出。 然后，可以通过从相应的日志中读取来快速筛选日志消息，而无需处理单个冗长的文件。 切勿将具有不同安全要求的信息（例如审核信息和调试数据）写入同一日志。

指标通常是特定时间系统中某些方面或资源的度量值或计数，具有一个或多个关联的标记或维度（有时称为 示例）。 指标的单个实例通常不可用于隔离。 相反，必须随着时间的推移捕获指标。 要考虑的关键问题是应记录的指标以及频率。 为指标生成数据太频繁可能会给系统带来重大的额外负载，而不经常捕获指标可能会导致错过导致重大事件的情况。 注意事项因指标而异。 例如，服务器上的 CPU 使用率可能会从秒到秒显著变化，但高利用率仅当长时间生存超过几分钟时，才会成为问题。

关联数据的信息

可以轻松监视各个系统级性能计数器、捕获资源的指标，以及从各种日志文件中获取应用程序跟踪信息。 但某些形式的监视需要监视管道中的分析和诊断阶段来关联从多个源检索到的数据。 此数据可能采用原始数据中的多种形式，并且必须提供足够的检测数据来映射这些不同表单的分析过程。 例如，在应用程序框架级别，任务可能由线程 ID 标识。 在应用程序中，相同的工作可能与执行该任务的用户的用户 ID 相关联。

此外，线程和用户请求之间不太可能有 1：1 映射，因为异步作可能会重复使用同一线程来代表多个用户执行作。 为了进一步使问题复杂化，当执行流经系统时，单个请求可能会被多个线程处理。 如果可能，请将每个请求与作为请求上下文的一部分通过系统传播的唯一活动 ID 相关联。 （在跟踪信息中生成和包括活动 ID 的技术取决于用于捕获跟踪数据的技术。

所有监视数据都应以相同的方式进行时间戳。 为了保持一致性，请使用协调世界时记录所有日期和时间。 这有助于更轻松地跟踪事件序列。

要包含在检测数据中的信息

确定需要收集的检测数据时，请考虑以下几点：

• 确保跟踪事件捕获的信息是计算机和人工可读的。 为此信息采用定义完善的架构，以便跨系统自动处理日志数据，并为读取日志的作和工程人员提供一致性。 包括环境信息，例如部署环境、运行进程的计算机、进程的详细信息和调用堆栈。

• 仅在必要时启用分析，因为它可能会给系统带来重大开销。 每次发生事件时，都使用检测记录事件（例如方法调用），而采样仅记录所选事件。 选择可以是基于时间（每 n 秒一次）或基于频率（每 n 个请求一次）。 如果事件非常频繁发生，则检测分析可能会导致过多负担，本身会影响整体性能。 在这种情况下，采样方法可能更可取。 但是，如果事件频率较低，采样可能会错过它们。 在这种情况下，检测可能是更好的方法。

• 提供足够的上下文，使开发人员或管理员能够确定每个请求的源。 这可能包括标识请求的特定实例的某种形式的活动 ID。 它还可能包括可用于将此活动与执行的计算工作和所使用的资源相关联的信息。 请注意，这项工作可能跨越进程和计算机边界。 对于计量，上下文还应包括（直接或间接地通过其他相关信息）对导致发出请求的客户的引用。 此上下文提供有关捕获监视数据时应用程序状态的宝贵信息。

• 记录所有请求以及从中发出这些请求的位置或区域。 此信息有助于确定是否存在任何特定于位置的热点。 此信息还可用于确定是重新分区应用程序还是应用程序使用的数据。

• 仔细记录和捕获异常的详细信息。 通常，由于异常处理不佳，关键调试信息会丢失。 捕获应用程序引发的异常的完整详细信息，包括任何内部异常和其他上下文信息。 如果可能，请包含调用堆栈。

• 在应用程序捕获的不同元素的数据中保持一致，因为这可以帮助分析事件并将其与用户请求相关联。 请考虑使用全面的可配置日志记录包来收集信息，而不是依赖于开发人员采用与实现系统不同部分相同的方法。 从关键性能计数器收集数据，例如正在执行的 I/O 量、网络利用率、请求数、内存使用和 CPU 利用率。 某些基础结构服务可能会提供自己的特定性能计数器，例如与数据库的连接数、正在执行的事务的速率以及成功或失败的事务数。 应用程序还可以定义自己的特定性能计数器。

• 记录对外部服务（如数据库系统、Web 服务或其他属于基础结构一部分）的所有调用。 记录有关执行每个调用所花费的时间以及调用成功或失败的信息。 如果可能，请捕获有关发生的任何暂时性错误的所有重试尝试和失败的信息。

确保与遥测系统的兼容性

在许多情况下，检测生成的信息将生成为一系列事件，并传递给单独的遥测系统进行处理和分析。 遥测系统通常独立于任何特定应用程序或技术，但需要信息遵循通常由架构定义的特定格式。 架构有效地指定了一个协定，用于定义遥测系统可以引入的数据字段和类型。 架构应通用化，以允许从一系列平台和设备到达的数据。

通用架构应包括所有检测事件通用的字段，例如事件名称、事件时间、发送方的 IP 地址，以及与其他事件（例如用户 ID、设备 ID 和应用程序 ID）关联所需的详细信息。 请记住，任意数量的设备可能会引发事件，因此架构不应依赖于设备类型。 此外，各种设备可能会引发同一应用程序的事件;应用程序可能支持漫游或其他某种形式的跨设备分发。

该架构还可能包含与不同应用程序通用的特定方案相关的域字段。 这可能是有关异常、应用程序启动和结束事件以及 Web 服务 API 调用成功或失败的信息。 使用同一组域字段的所有应用程序都应发出同一组事件，从而生成一组通用报表和分析。

最后，架构可能包含用于捕获应用程序特定事件详细信息的自定义字段。

检测应用程序的最佳做法

以下列表汇总了检测在云中运行的分布式应用程序的最佳做法。

• 使日志易于读取并易于分析。 尽可能使用结构化日志记录。 在日志消息中简洁和描述性。

• 在所有日志中，标识源，并在写入每个日志记录时提供上下文和计时信息。

• 对所有时间戳使用相同的时区和格式。 这有助于关联跨不同地理区域运行的硬件和服务的作的事件。

• 对日志进行分类，并将消息写入相应的日志文件。

• 请勿披露有关系统的敏感信息或有关用户的个人信息。 在记录此信息之前清理此信息，但请确保保留相关详细信息。 例如，从任何数据库连接字符串中删除 ID 和密码，但将剩余信息写入日志，以便分析人员可以确定系统正在访问正确的数据库。 记录所有关键异常，但使管理员能够打开和关闭较低级别的异常和警告。 此外，捕获和记录所有重试逻辑信息。 此数据可用于监视系统的暂时性运行状况。

• 跟踪进程外调用，例如对外部 Web 服务或数据库的请求。

• 不要将日志消息与同一日志文件中的不同安全要求混合使用。 例如，不要将调试和审核信息写入同一日志。

• 除了审核事件之外，请确保所有日志记录调用都是不阻止业务运营进度的触发和忘记作。 审核事件非常出色，因为它们对业务至关重要，并且可以归类为业务运营的基本部分。

• 确保日志记录是可扩展的，并且没有对具体目标的任何直接依赖项。 例如，而不是使用 System.Diagnostics.Trace 编写信息，而是定义一个抽象接口（例如 ILogger），该接口公开日志记录方法，并且可以通过任何适当的方式实现。

• 确保所有日志记录都是安全的，并且永远不会触发任何级联错误。 日志记录不得引发任何异常。

• 将检测视为正在进行的迭代过程，并定期查看日志，而不仅仅是出现问题时。

收集和存储数据

监视过程的收集阶段涉及检索检测生成的信息，设置此数据的格式，以便分析/诊断阶段更易于使用，并将转换后的数据保存在可靠存储中。 从分布式系统的不同部分收集的检测数据可以保存在各种位置，并采用不同的格式。 例如，应用程序代码可能会生成跟踪日志文件并生成应用程序事件日志数据，而监视应用程序使用基础结构的关键方面的性能计数器可以通过其他技术捕获。 应用程序使用的任何第三方组件和服务都可能通过单独的跟踪文件、Blob 存储甚至自定义数据存储以不同的格式提供检测信息。

数据收集通常通过集合服务执行，该服务可以从生成检测数据的应用程序自主运行。 图 2 演示了此体系结构的示例，其中突出显示了检测数据收集子系统。

图 2 - 收集检测数据。

请注意，这是简化的视图。 收集服务不一定是单个进程，并且可能包含在不同计算机上运行的许多构成部分，如以下部分所述。 此外，如果必须快速执行某些遥测数据的分析（如本文档后面的 支持热分析、暖分析和冷分析 部分中所述），则集合服务外部运行的本地组件可能会立即执行分析任务。 图 2 描述了所选事件的这种情况。 分析处理后，结果可以直接发送到可视化和警报子系统。 在等待处理时，受暖分析或冷分析的数据保存在存储中。

对于 Azure 应用程序和服务，Azure 诊断提供了用于捕获数据的可能解决方案。 Azure 诊断从每个计算节点的以下源收集数据，对其进行聚合，然后将其上传到 Azure 存储：

• IIS 日志
• IIS 失败的请求日志
• Windows 事件日志
• 性能计数器
• 故障转储
• Azure 诊断基础结构日志
• 自定义错误日志
• .NET EventSource
• 基于清单的 ETW

有关详细信息，请参阅 Azure：遥测基础知识和故障排除文章。

收集检测数据的策略

考虑到云的弹性性质，并避免需要从系统中的每个节点手动检索遥测数据，应安排将数据传输到中心位置并合并。 在跨多个数据中心的系统中，首先按区域收集、合并和存储数据，然后将区域数据聚合到单个中心系统中可能很有用。

若要优化带宽的使用，可以选择将不太紧急的数据以区块的形式传输成批。 但是，数据不得无限期延迟，尤其是在数据包含时间敏感信息时。

拉取和推送检测数据

检测数据收集子系统可以主动从应用程序的每个实例（ 拉取模型）的各种日志和其他源中检索检测数据。 或者，它可以充当被动接收器，等待数据从构成应用程序的每个实例（ 推送模型）的组件发送数据。

实现拉取模型的一种方法是使用监视代理，这些代理在本地运行的每个应用程序实例。 监视代理是一个单独的过程，用于定期检索本地节点上收集的（拉取）遥测数据，并将此信息直接写入应用程序的所有实例共享的集中式存储。 这是 Azure 诊断实现的机制。 可将 Azure Web 角色或辅助角色的每个实例配置为捕获本地存储的诊断和其他跟踪信息。 与每个实例一起运行的监视代理会将指定的数据复制到 Azure 存储。 在 Azure 云服务和虚拟机中启用诊断 文章提供了有关此过程的更多详细信息。 某些元素（如 IIS 日志、故障转储和自定义错误日志）将写入 Blob 存储。 Windows 事件日志、ETW 事件和性能计数器中的数据记录在表存储中。 图 3 说明了此机制。

图 3 - 使用监视代理拉取信息和写入共享存储。

可以使用刚刚描述的方法为在单个位置的有限数量的节点上运行的小型应用程序存储遥测数据。 但是，复杂且高度可缩放的全局云应用程序可能会从数百个 Web 角色和辅助角色、数据库分片和其他服务生成大量数据。 这种数据泛滥很容易使单个中心位置可用的 I/O 带宽不知所措。 因此，遥测解决方案必须可缩放，以防止它在系统扩展时充当瓶颈。 理想情况下，如果系统的一部分发生故障，解决方案应包含一定程度的冗余，以减少丢失重要监视信息（例如审核或计费数据）的风险。

若要解决这些问题，可以实施队列，如图 4 所示。 在此体系结构中，本地监视代理（如果可以正确配置）或自定义数据收集服务（如果不是）将数据发布到队列。 异步运行的独立进程（图 4 中的存储写入服务）会获取此队列中的数据，并将其写入共享存储。 消息队列适用于此方案，因为它提供“至少一次”语义，有助于确保在发布队列数据后不会丢失。 可以使用单独的辅助角色实现存储写入服务。

图 4 - 使用队列来缓冲检测数据。

本地数据收集服务可以在收到数据后立即将数据添加到队列。 队列充当缓冲区，存储写入服务可以按自己的速度检索和写入数据。 默认情况下，队列按先入先出的方式运行。 但是，如果消息包含必须更快地处理的数据，则可以确定消息的优先级，以加速它们通过队列。 有关详细信息，请参阅 优先级队列模式。 或者，可以使用不同的通道（例如服务总线主题）将数据定向到不同的目标，具体取决于所需的分析处理形式。

为了获得可伸缩性，可以运行存储写入服务的多个实例。 如果有大量事件，可以使用事件中心将数据调度到不同的计算资源进行处理和存储。

合并检测数据

数据收集服务从应用程序的单个实例中检索的检测数据提供了该实例的运行状况和性能的本地化视图。 若要评估系统的整体运行状况，必须在本地视图中合并数据的某些方面。 可以在存储数据后执行此作，但在某些情况下，也可以在收集数据时实现此目的。 检测数据无需直接写入共享存储，而是可以传递单独的数据合并服务，该服务将数据合并并充当筛选器和清理过程。 例如，可以合并包含相同关联信息的检测数据，例如活动 ID。 （用户可能开始在一个节点上执行业务作，然后在节点发生故障时传输到另一个节点，或者取决于负载均衡的配置方式。此过程还可以检测和删除任何重复的数据（如果遥测服务使用消息队列将检测数据推送到存储，则始终有可能）。 图 5 说明了此结构的示例。

图 5 - 使用单独的服务合并和清理检测数据。

存储检测数据

前面的讨论描述了检测数据的存储方式的简单化视图。 实际上，通过使用最适合每种类型使用方式的技术来存储不同类型的信息是有意义的。

例如，Azure Blob 和表存储在访问时具有一些相似之处。 但是，它们对可以使用它们执行的作具有限制，并且它们保存的数据粒度大相径庭。 如果需要对数据执行更多分析作或需要全文搜索功能，则使用为特定类型的查询和数据访问优化的功能的数据存储可能更合适。 例如：

• 性能计数器数据可以存储在 SQL 数据库中以启用即席分析。
• 跟踪日志可能更好地存储在 Azure Cosmos DB 中。
• 安全信息可以写入 HDFS。
• 需要全文搜索的信息可以通过 Elasticsearch 进行存储（也可以使用丰富的索引加快搜索速度）。

你可以实现一个附加服务，该服务会定期根据共享存储、分区和筛选数据，然后将其写入适当的数据存储集，如图 6 所示。 另一种方法是在合并和清理过程中包括此功能，并在检索数据时直接将数据写入这些存储，而不是将其保存在中间共享存储区域中。 每种方法都有其优点和缺点。 实现单独的分区服务可减少合并和清理服务上的负载，并在必要时至少重新生成一些已分区数据（具体取决于共享存储中保留的数据量）。 但是，它会消耗其他资源。 此外，从每个应用程序实例接收检测数据以及将此数据转换为可作信息之间可能存在延迟。

图 6 - 根据分析和存储要求对数据进行分区。

出于多个目的，可能需要相同的检测数据。 例如，性能计数器可用于提供系统性能随时间推移的历史视图。 此信息可能与其他使用情况数据相结合，以生成客户计费信息。 在这些情况下，相同的数据可能会发送到多个目标，例如可以充当长期存储来保存计费信息的文档数据库，以及用于处理复杂性能分析的多维存储。

还应考虑数据需要多大程度。 必须快速访问提供警报信息的数据，因此应将其保存在快速数据存储中，并编制索引或结构化以优化警报系统执行的查询。 在某些情况下，遥测服务可能需要在每个节点上收集数据以在本地格式化和保存数据，以便警报系统的本地实例可以快速通知你任何问题。 如果出于其他目的，也可以将相同的数据调度到上图中显示的存储写入服务，并集中存储。

用于更考虑的分析、报告和发现历史趋势的信息不太紧迫，可以采用支持数据挖掘和临时查询的方式存储。 有关详细信息，请参阅本文档后面的 支持热、暖和冷分析 部分。

日志轮换和数据保留

检测可以生成大量数据。 此数据可以保存在多个位置，从在每个节点上捕获的原始日志文件、跟踪文件和其他信息开始，到共享存储中保存的此数据的合并、清理和分区视图。 在某些情况下，在处理和传输数据后，可以从每个节点中删除原始原始源数据。 在其他情况下，保存原始信息可能是必需的或只是有用。 例如，出于调试目的而生成的数据可能最好以原始形式提供，但在纠正任何 bug 后可以快速放弃。

性能数据通常具有更长的寿命，因此可用于发现性能趋势和容量规划。 此数据的合并视图通常在有限时间内保持联机状态，以实现快速访问。 之后，可以存档或丢弃它。 为计量和计费客户收集的数据可能需要无限期保存。 此外，法规要求可能规定，出于审核和安全目的收集的信息也需要存档和保存。 这些数据还是敏感的，可能需要加密或以其他方式进行保护以防止篡改。 不应记录用户的密码或其他可能用于提交标识欺诈的信息。 在存储数据之前，应从数据中清理此类详细信息。

向下采样

存储历史数据非常有用，以便可以发现长期趋势。 可以降低数据的分辨率并节省存储成本，而不是完全保存旧数据。 例如，可以合并一个多月的数据，而不是逐分钟保存性能指标，以形成每小时视图。

收集和存储日志记录信息的最佳做法

以下列表汇总了捕获和存储日志记录信息的最佳做法：

• 监视代理或数据收集服务应作为进程外服务运行，并且应该易于部署。

• 监视代理或数据收集服务的所有输出都应是独立于计算机、作系统或网络协议的不可知格式。 例如，以自描述格式（如 JSON、MessagePack 或 Protobuf）而不是 ETL/ETW 发出信息。 使用标准格式使系统能够构造处理管道;可以轻松集成读取、转换和发送采用同意格式的数据的组件。

• 监视和数据收集过程必须安全，并且不得触发任何级联错误条件。

• 如果向数据接收器发送信息时出现暂时性故障，监视代理或数据收集服务应准备好重新排序遥测数据，以便先发送最新的信息。 （监视代理/数据收集服务可能会选择删除较旧的数据，或将其保存在本地，并在以后进行传输以自行跟进。

分析数据和诊断问题

监视和诊断过程的一个重要部分是分析收集的数据，以获取系统整体福祉的图片。 你应该已经定义了自己的 KPI 和性能指标，并且必须了解如何构建收集的数据以满足分析要求。 了解在不同指标和日志文件中捕获的数据如何相关也很重要，因为此信息对于跟踪事件序列并帮助诊断出现的问题至关重要。

如 合并检测数据部分中所述，系统的每个部分的数据通常在本地捕获，但通常需要与参与系统的其他站点生成的数据相结合。 此信息需要仔细关联，以确保数据准确组合。 例如，作的使用数据可能跨越托管用户连接到的网站的节点、运行作为此作一部分访问的单独服务的节点，以及在另一个节点上保存的数据存储。 此信息需要绑定在一起，以提供作的资源和处理使用情况的总体视图。 某些预处理和筛选数据可能发生在捕获数据的节点上，而聚合和格式设置更有可能发生在中心节点上。

支持热、暖和冷分析

为了可视化、报告和警报目的分析和重新格式化数据，可能是一个复杂的过程，它消耗了自己的一组资源。 某些形式的监视是时间关键型，需要立即分析数据才能有效。 这称为 热分析。 示例包括警报所需的分析以及安全监视的某些方面（例如检测系统攻击）。 这些目的所需的数据必须快速可用并结构化，以便高效处理。 在某些情况下，可能需要将分析处理移动到保存数据的单个节点。

其他形式的分析时间越少，在收到原始数据后可能需要一些计算和聚合。 这称为 热分析。 性能分析通常属于此类别。 在这种情况下，隔离的单一性能事件在统计上不太可能显著。 （这可能是由突然峰值或故障引起的。来自一系列事件的数据应提供更可靠的系统性能图片。

热分析还可用于帮助诊断运行状况问题。 运行状况事件通常通过热分析进行处理，可以立即引发警报。 作员应能够通过检查暖路径中的数据来钻取运行状况事件的原因。 此数据应包含导致运行状况事件的事件的相关信息。

某些类型的监视会生成更多的长期数据。 此分析可以在以后执行，可能根据预定义的计划执行。 在某些情况下，分析可能需要对一段时间内捕获的大量数据执行复杂的筛选。 这称为 冷分析。 关键要求是数据在捕获后安全存储。 例如，使用情况监视和审核需要准确了解系统在常规时间点的状态，但收集系统后无需立即处理此状态信息。

作员还可以使用冷分析来提供预测运行状况分析的数据。 作员可以在指定时间段内收集历史信息，并将其与当前运行状况数据（从热路径检索）结合使用，以发现可能很快导致运行状况问题的趋势。 在这些情况下，可能需要发出警报，以便可以采取纠正措施。

关联数据

检测捕获的数据可以提供系统状态的快照，但分析的目的是使这些数据可作。 例如：

• 是什么导致了在特定时间在系统级别进行激烈的 I/O 加载？
• 是否是大量数据库作的结果？
• 这是否反映在数据库响应时间、每秒事务数和应用程序响应时间相同的时刻？

如果是这样，可能会减少负载的一个修正作可能是将数据分片到更多服务器上。 此外，由于系统的任何级别出现故障，可能会引发异常。 一个级别的异常通常会触发上述级别的另一个故障。

出于这些原因，你需要能够关联每个级别的不同类型的监视数据，以生成系统状态的总体视图以及其上运行的应用程序。 然后，可以使用此信息来决定系统是否可接受运行，并确定可以做些什么来提高系统的质量。

如有关 关联数据的“信息”部分中所述，必须确保原始检测数据包含足够的上下文和活动 ID 信息，以支持关联事件所需的聚合。 此外，这些数据可能采用不同的格式保存，并且可能需要分析此信息以将其转换为标准化格式进行分析。

排查和诊断问题

诊断需要能够确定错误或意外行为的原因，包括执行根本原因分析。 所需的信息通常包括：

• 事件日志和跟踪中的详细信息，无论是针对整个系统，还是在指定时间范围内指定子系统。
• 完成堆栈跟踪，由系统内或指定子系统内在指定时间段内发生的任何指定级别的异常和故障导致的。
• 针对系统中的任何位置或指定子系统在指定时间范围内的任何失败进程进行故障转储。
• 记录所有用户或在指定时间段内为所选用户执行的作的活动日志。

出于故障排除目的分析数据通常需要对系统体系结构和构成解决方案的各种组件有深入的技术了解。 因此，通常需要大量的手动干预来解释数据，建立问题的原因，并建议采取适当的策略来纠正这些问题。 它可能很合适，只需以原始格式存储此信息的副本，并使其可供专家进行冷分析。

可视化数据和引发警报

任何监视系统的重要方面是能够以作员快速发现任何趋势或问题的方式呈现数据。 此外，重要的是，如果发生了可能需要注意的重要事件，快速通知作员。

数据呈现可以采用多种形式，包括使用仪表板、警报和报告进行可视化。

使用仪表板进行可视化

可视化数据的最常见方法是使用仪表板，这些仪表板可以将信息显示为一系列图表、图形或其他一些插图。 这些项可以参数化，分析师应能够针对任何特定情况选择重要参数（如时间段）。

仪表板可以按层次结构进行组织。 顶级仪表板可以全面查看系统的各个方面，但使作员能够向下钻取详细信息。 例如，描述系统的总体磁盘 I/O 的仪表板应允许分析人员查看每个磁盘的 I/O 速率，以确定一个或多个特定设备是否占不成比例的流量。 理想情况下，仪表板还应显示相关信息，例如生成此 I/O 的每个请求（用户或活动）的来源。 然后，此信息可用于确定（以及如何）在设备之间更均匀地分布负载，以及是否在添加更多设备时系统性能更好。

仪表板还可以使用颜色编码或其他视觉提示来指示出现异常或超出预期范围的值。 使用前面的示例：

• I/O 速率接近长时间（热磁盘）的最大容量的磁盘可以红色突出显示。
• 具有 I/O 速率的磁盘，可在短时间内以最大限制定期运行（暖磁盘）以黄色突出显示。
• 显示正常使用情况的磁盘可以显示为绿色。

请注意，要使仪表板系统有效工作，它必须具有要使用的原始数据。 如果要构建自己的仪表板系统，或使用另一个组织开发的仪表板，则必须了解需要收集哪些检测数据、在粒度级别以及应如何设置仪表板的格式以供仪表板使用。

良好的仪表板不仅显示信息，还使分析师能够就该信息提出临时问题。 某些系统提供作员可用于执行这些任务的管理工具并浏览基础数据。 或者，根据用于保存此信息的存储库，可以直接查询此数据，或将其导入到 Microsoft Excel 等工具，以便进一步分析和报告。

引发警报

警报是分析监视和检测数据并在检测到重要事件时生成通知的过程。

警报有助于确保系统保持正常运行、响应和安全。 这是任何使性能、可用性和隐私保证的用户（可能需要立即处理数据）的系统的重要组成部分。 作员可能需要收到触发警报的事件的通知。 警报还可用于调用系统功能，例如自动缩放。

警报通常取决于以下检测数据：

• 安全事件。 如果事件日志指示发生了重复的身份验证或授权失败，系统可能会受到攻击，并且应通知作员。
• 性能指标。 如果特定性能指标超过指定的阈值，系统必须快速响应。
• 可用性信息。 如果检测到故障，可能需要快速重启一个或多个子系统，或故障转移到备份资源。 子系统中的重复故障可能表示更严重的问题。

作员可以使用许多传递渠道（如电子邮件、寻呼设备或短信）接收警报信息。 警报还可能包括指示情况有多严重。 许多警报系统支持订阅者组，属于同一组成员的所有作员都可以接收同一组警报。

警报系统应可自定义，并且可以将基础检测数据中的相应值作为参数提供。 此方法使作员能够筛选数据并专注于感兴趣的值阈值或组合。 请注意，在某些情况下，可以将原始检测数据提供给警报系统。 在其他情况下，提供聚合数据可能更合适。 （例如，如果节点的 CPU 使用率在过去 10 分钟内超过 90%），则可以触发警报。 提供给警报系统的详细信息还应包括任何适当的摘要和上下文信息。 此数据有助于降低误报事件将触发警报的可能性。

报告

报告用于生成总体的系统视图。 除了当前信息之外，它还可能包含历史数据。 报告要求本身分为两大类：作报告和安全报告。

作报告通常包括以下方面：

• 聚合统计信息，可用于了解指定时间窗口内整个系统或指定子系统的资源利用率。
• 确定在指定期间内整个系统或指定子系统的资源使用趋势。
• 监视在指定时间段内在整个系统或指定子系统中发生的异常。
• 在部署的资源方面确定应用程序的效率，并了解资源量（及其关联的成本）是否可以减少，而不会造成不必要的性能影响。

安全报告涉及跟踪客户的系统使用情况。 它可以包括：

• 审核用户作。 这需要记录每个用户执行的各个请求以及日期和时间。 应构建数据，使管理员能够快速重新构造用户在指定时间段内执行的作序列。
• 跟踪用户使用的资源。 这需要记录用户每次请求如何访问构成系统的各种资源，以及多长时间。 管理员必须能够使用此数据在指定时间段内按用户生成利用率报告，可能出于计费目的。

在许多情况下，批处理可以根据定义的计划生成报告。 （延迟通常不是问题。但是，如果需要，它们也应该临时生成。 例如，如果要将数据存储在关系数据库中（如 Azure SQL 数据库），则可以使用 SQL Server Reporting Services 等工具提取和格式化数据并将其呈现为一组报表。

后续步骤

• Azure Monitor 概述
• 监视、诊断和排查 Microsoft Azure 存储问题
• Microsoft Azure 中的警报概述
• 使用 Azure 门户查看服务运行状况通知
• 什么是 Application Insights？
• Azure 虚拟机的性能诊断
• 下载并安装适用于 Visual Studio 的 SQL Server Data Tools （SSDT）

相关资源

• 自动缩放指南 介绍了如何通过减少作员持续监视系统性能以及决定添加或删除资源来减少管理开销。
• 运行状况终结点监视模式 介绍如何在应用程序中实现功能检查，外部工具可以定期通过公开的终结点进行访问。
• 优先级队列模式 显示如何确定排队消息的优先级，以便接收紧急请求，并且可以在不太紧急的消息之前进行处理。