远程监控 – 数据采集管道

数据采集​​管道是远程监控解决方案的核心所在，后者是 Windows Azure 中云服务基础项目的一部分。该管道是 Wiki系列中第三篇文章的主题。它在解决方案中的角色是从各个存储库中提取不同的信息并将其聚合到一个关系数据库。之后可以将该数据库用于关联和分析捕获指标的长期趋势、深入到具体问题和事件，以及订阅预定义和动态报表与仪表板（但是别急，这将是我们下一篇文章的主题）。以下是一些可以通过该管道调查的示例问题，“客户报告性能下降时，我的应用程序组件出现了什么状况？”或“应用程序在 UTC 时间上午 12 点至下午 1 点之间产生超时错误时，我的数据层发生了什么变化？”这些问题正是我们希望我们的端到端远程监控解决方案能够解决的。

图 1 - 数据采集​​管道是整个远程监控解决方案体系结构中的重点

从体系结构的角度来看，我们可以将数据采集管道的设计细分为三个主要部分：

1. 一个执行导入和转换任务的可配置计划程序引擎。

2. 一组查询各种信息源、应用一些转换逻辑并将结果推送到集中存储库的可扩展任务。

3. 一个将这些数据存储在常规关系架构中的 Windows Azure SQL 数据库实例，可用于执行分析查询并提取有意义的信息。

实施计划程序引擎时，我们决定采用“拉”的机制，按一定的时间间隔查询各种数据源。采用这一方法而非更复杂的“推”和“流化”方法的原因有很多。主要原因是，数据已经存储在中间库中，如 Windows Azure 存储（存储 Windows Azure Diagnostics 生成的信息）或 Windows Azure SQL 数据库内部数据结构（存储动态管理视图）。我们对实时持续分析没有严格的要求，我们也希望将实施过程尽量简化。在当前版本中，我们的计划程序作为 Windows Azure worker role 进行实施，它可以从托管在 Windows Azure 存储 Blob 容器中的 XML 文件读取其配置。该文件定义了要执行的计划作业的数量和类型及其执行频率，以及各数据源和目标位置的所有配置选项与连接字符串。可以随时更改配置文件，即添加或删除任务或更改特定配置，worker role 将使用更新后的文件开始执行。我们多次运行了此计划程序组件的生产部署，与客户及合作伙伴一起监控其解决方案。我们发现，用一个“小型”VM部署此 worker role足以处理数百个目标计算实例和数据库。

我们还实施了连接到两个主要诊断源系列的多个导入任务：

·Windows AzureDiagnostics (WAD) 生成的数据

·通过 DMV 提供的 Windows Azure SQL 数据库内部状态

由于 WAD 将大多数信息存储在 Windows Azure 存储表中，因此许多导入任务都非常相似。它们主要使用Windows Azure Storage Client Library v2.0, 在给定时间范围（从开始日期到结束日期）内查询源表、应用一些即时筛选器（例如关键事件或错误事件）、重新动态设定或转换数据行的格式，并将新信息批量复制到目标数据库。此类信息包括 Windows Azure 计算节点性能计数器、Windows 事件日志和跟踪日志，等等。更加复杂的实施涉及通过 WAD 收集所有 Web role 中的 IIS 日志，这些日志存储在以特定结构组织的 Blob 容器中。为此，我们首先必须查询表（其中包含对在特定时间范围内生成的所有日志文件的引用），然后在 worker role 本地存储中下载这些 IIS 日志文件以分析和提取有意义的信息，如网页和 API 响应时间。

对于 SQL 数据库实例，我们需创建具体的导入任务，用于跨所有目标数据库查询公共可用的 DMV（使用并行扇出库），并提取各种有用信息，包括从查询和请求统计数据到连接错误、缺少的索引以及数据库大小。

作为未来改进，我们正在考虑添加 Windows Azure 存储分析和缓存的诊断信息。

所有此类诊断信息之后会使用基于时间的通用键定义，存储在单独的关系架构中（同样托管在 SQL 数据库中），且已针对时间间隔查询进行优化。这样做的原因很简单，即您很可能会使用此信息来调查特定事件或了解随时间变化的趋势。

我之前曾提到，在下一篇文章中，我们将说明如何从 OpsStatsDB 中查询和提取感兴趣的信息，并将重点介绍表值函数 (TVF) 层。我们创建这些 TVF 是为了使用 Excel 来简化即席报表的实施。我们还研究了一组随云服务基础代码包提供的 Windows Azure SQL Reporting Services 报告和仪表板。

您可在云服务基础 TechNet Wiki 登录页面上找到整个系列。

本文翻译自：

http://blogs.msdn.com/b/windowsazure/archive/2013/08/08/telemetry-data-acquisition-pipeline.aspx