收集、聚合和存储云应用程序的监视数据

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在分布式系统中，检测可以从许多组件中生成大量数据，这些数据保存在不同的位置，并以不同的格式保存。

例如，应用程序代码可能会生成跟踪日志文件和应用程序事件日志数据。 从基础结构的角度来看，性能计数器是通过其他技术捕获的。 此外，应用程序使用的任何第三方组件和服务可以使用独立的跟踪文件、Blob 存储甚至自定义数据存储提供不同格式的自有检测信息。

本文提供了从各种源收集数据、合并和清理各种格式以及存储在可靠存储中的最佳做法。

具备各种技术，以便收集和聚合各环境中的应用程序日志、来自应用程序资源、基础结构和其他关键依赖项的诊断日志。

收集服务应该作为进程外服务运行，并且应易于部署。

收集服务的所有输出都应该是结构化的和不可知的格式。

监视和数据收集进程必须是故障安全的，并且不得触发任何级联错误状况。

将信息发送到数据接收器时，如果发生暂时性故障，收集服务应该已准备好重新排列遥测数据的顺序，以便首先发送最新的信息。 （监视代理/数据收集服务可以自行选择删除较旧数据，或将其存储在本地，并在稍后将其传输以便与新版本同步。）

此图显示了一个典型的检测数据收集过程。

分析模式中汇总了热、暖和冷分析模式。

对于应用程序，收集服务可以是 应用程序性能管理 (APM) 工具 ，该工具可以从生成检测数据的应用程序自主运行。 启用 APM 后，可以实时以及从历史角度清晰了解重要指标。 请考虑适当的日志记录级别。 详细日志记录可能会产生大量成本。

APM 的示例是应用程序Insights聚合应用程序级别日志和事件以供后续分析。

应用程序日志支持端到端的应用程序生命周期。 日志记录对于了解应用程序在不同环境中的运行方式、发生什么事件以及在哪些情况下发生非常重要。

建议在所有主要环境中收集应用程序日志和事件。 尽可能将环境之间的数据分开。 实现筛选器，以确保非关键环境不会使生产日志解释复杂化。 此外，应用程序中的相应日志条目应该为它们各自的事务捕获一个相关 ID。

应将应用程序事件捕获为具有 计算机可读数据点而不是非结构化字符串类型的结构化数据类型。 采用结构化格式，遵循已知架构有助于分析和分析日志。 此外，可以轻松为结构化数据编制索引和进行搜索，并且可以大大简化报表。

数据还应该是独立于计算机、操作系统或网络协议的不可知格式。 例如，以自我描述格式发出信息，例如 JSON、MessagePack 或 Protobuf，而不是 ETL/ETW。 使用标准格式能够使系统构造处理管道；以议定的格式读取、转换和发送数据的组件可以轻松集成。

你还需要收集平台诊断信息以获得整体视图。 例如，Windows 事件日志、性能计数器、诊断基础结构日志和来自管理平面的日志。 Azure 平台日志可满足所有这些需求。 以下是一些建议：

用于聚合基础结构和资源日志的收集服务有许多选项。 Azure Log Analytics 或 Splunk 是一种常用选项，用于跨所有应用程序组件整理日志和指标，以供后续评估。 资源可能包括 Azure IaaS、PaaS 服务和第三方设备，例如应用程序中使用的防火墙或反恶意软件解决方案。 例如，如果使用 Azure 事件中心，则诊断设置应配置为将日志和指标推送到数据接收器。

了解使用情况有助于正确调整工作负载的大小，但需要接受日志记录的额外成本，并将其包含在成本模型中。

避免从每个组件手动检索遥测数据。 通过一种方法将数据移动到中心位置并进行合并。 对于多区域解决方案，建议你首先按区域收集、合并和存储数据，然后将区域数据聚合到单个中央系统中。

要优化带宽的使用，请根据数据的重要性进行优先级排序。 可以批量传输不太紧急的数据。 不过，数据不得无限期延迟，特别是当它包含时间敏感的信息时。

收集服务主要可以通过两种模型收集检测数据：

监视代理在拉取模型中工作。 代理与应用程序的每个实例在单独的进程中本地运行，并定期拉取数据并将此信息直接写入应用程序的所有实例共享的集中式存储中。

有关详细信息，请参阅Azure 诊断扩展。

注意

监视代理非常适合用于捕获从数据源自然提取的检测数据。 这适用于在单个位置的有限数量节点上运行的小规模应用程序。 例如来自 SQL Server 管理视图的信息或 Azure 服务总线队列的长度。

一个复杂的、高度可扩展的应用程序可能会生成大量数据。 数据量很容易使单个中心位置可用的 I/O 带宽不知所措。 遥测解决方案不能成为瓶颈，并且必须随着系统的扩展而扩展。 在理想情况下，解决方案应包括一定程度的冗余，以降低系统部件发生故障时丢失重要监视信息（例如审核或计费数据）的风险。

一种方法是通过队列。

在此体系结构中，数据收集服务将数据发布到队列。 消息队列很合适，因为它提供“至少一次”语义，帮助确保排队的数据在发布后不会丢失。 可以使用独立的辅助角色来实施存储写入服务。 你可以使用优先队列模式来实现这一点。

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

从应用程序的单个实例收集的数据提供了该实例的运行状况和性能的本地化视图。 要评估系统的整体运行状况，需要将本地视图中某些层面的数据合并在一起。 这可以在存储数据之后执行，但在某些情况下，也可以在收集数据时进行。

通过独立的数据合并服务传递检测数据，此服务可以合并数据，并可充当筛选器和清理进程。 例如，包含相同关联信息（例如活动 ID）的检测数据可以合并。 (用户可能开始在一个节点上执行业务操作，然后在节点发生故障时传输到另一个节点，或者取决于配置负载均衡的方式。) 此过程还可以检测和删除任何重复数据， (遥测服务使用消息队列将检测数据推送到存储) 始终可能。

在决定存储能力时，请考虑数据的类型、使用方式以及需要数据的紧急程度。

考虑一种多语言持久化方法，其中使用最适合每种类型的可能使用方式的技术来存储不同类型的信息。

例如，Azure Blob 和表存储在访问方式方面有一些相似之处。 但是，它们在你可以为它们执行的操作以及它们所持有的数据的粒度方面存在差异。 如果需要运行更多的分析操作或需要对数据使用全文搜索功能，可能更适合使用数据存储，因为它提供的功能已针对特定类型的查询和数据访问进行优化。 例如：

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

可以实现另一个服务，该服务会定期从共享存储、分区和筛选数据，并根据其用途筛选数据，然后将其写入适当的数据存储集。

另一种方法是在合并和清理过程中包含此功能，并在检索到数据时直接将它写入这些存储，而不是将它存储在中间共享存储区域。

每一种方法有其优点和缺点。 实施独立分区服务可以减少合并与清理服务的负载，至少可在需要时重新生成某些分区的数据（取决于共享存储中保留的数据量）。 但是，这会消耗更多的资源。 此外，在从每个应用程序实例接收检测数据与将此数据转换成有用信息之间可能出现延迟。

考虑需要数据的紧急程度。 生成警报的数据必须快速访问，因此应该保留在快速数据存储中，并编制索引或结构化以优化警报系统运行的查询。 在某些情况下，收集服务可能需要在本地格式化和保存数据，以便警报系统的本地实例可以快速发送通知。 同一数据可以发送到前面图像中显示的存储写入服务，如果出于其他目的而需要它，则集中存储。

在某些情况下，处理并传输数据后，可以删除本地存储的原始源数据。 在其他情况下，可能有必要保存原始信息，或者这样做会有用。 例如，出于调试目的而生成的数据最好能够保留原始格式，但是纠正任何 Bug 之后，就可以迅速将其丢弃。

性能数据通常有较长的寿命，因此可用于找出性能趋势，以及进行容量规划。 此数据的合并视图通常在一段有限的时间内保持联机以实现快速访问。 过了这段时间后，可以将其存档或丢弃。

存储能够找出长期趋势的历史数据很有用。 无需保存整个旧数据，而可以向下采样数据，以降低其分辨率并节省存储成本。 举例来说，无需保存每分钟的性能指标，而可以合并超过一个月的数据，以构成每小时的视图。

针对客户计量和计费收集的数据可能需要无限期保存。 此外，法规要求可能规定，针对审核和安全目的收集的信息也需要存档和保存。 此数据也很机密，因此可能需要加密或进行保护，以防止篡改。 切勿记录诸如用户密码或其他可用于实行身份诈骗的信息。 应该先从数据中清除此类详细信息，再存储数据。

用于更深入分析、报告和找出历史趋势的信息较不紧急，并且可用支持数据采矿和即席查询的方式存储。

分析监视数据