数据聚合 & 分组：新一代系统监控的核心功能

遥想 2015 年 8 月 17 日，Cloud Insight 还在梳理功能原型，畅想 Cloud Insight 存在的意义：为何阿里云用户须要使用 Cloud Insight 来增强管理。

而今，咱们就已经实现了这样的功能：

使用标签来实现数据的聚合和分组。

相信使用过 OpenTSDB 或者 InfluxDB 的人都知道标签的存在：Tag。这也是为何愈来愈多 Zabbix 或者 Nagios 用户迁移至 OpentsDB 来自建运维监控系统的缘由。

若是所示，Zabbix 只提供单台 Host 的 Disk 使用量。若是 3 台主机，都同属于一个组 Mi-Kafka，想要知道这个组的整体 Disk 使用量，是没法得知的。

从而，就算线上系统发生了故障，要在短时间内知道，究竟是哪一个模块的哪一个部分出了哪样的问题，所须要的经验和时长都是很大的。

而 OpenTSDB 和 StatsD 的出现改变了现状。

运维 2.0 时代

在很是早期的时候，淘宝团队就引入了 OpenTSDB 来辅助他们的运维监控。详情见：OpenTSDB监控系统的研究和介绍。

随后的几年，云计算和 SaaS 的兴起，国外也出现了多种采用 StatsD 和 OpenTSDB 的开源工具搭建的 SaaS 服务：Boundary、CopperEgg、Datadog 等等。

他们都不约而同地采用了同一种产品逻辑，也是 Cloud Insight 的产品逻辑，也是时间序列数据库的逻辑：

• 任何的性能指标，都做为时间序列数据被采集、被处理；

• 任何的 Host 等归属于性能指标的属性，都做为指标的标签信息。

而在产品逻辑上，则表现为：

Cloud Insight 经过 3 个步骤达到操做系统、数据库、中间件，以及将来经过 Developer API 对接进来的全部 Metric 进行处理：

1. Cloud Insight Agent 采集并处理 Metric；

2. 在平台服务仪表盘和自定义仪表盘中，提供 Metric 聚合、分组、统计运算、基本数学运算等操做；

3. 针对操做的结果，提供曲线图、柱状图等多样化的展示形式。

数据聚合和分组

在 Beta v 0.2.1 中，咱们实现了数据的聚合和分组。沿袭了 OpenTSDB 的查询方式：用一种类 SQL 的方式来查询指标。

具体操做能够访问 Cloud Insight 文档中心 • Metric 查询。

接下来咱们会介绍 Cloud Insight 已经实现的 Metric 的查询，以及其中的数据聚合和分组。

语法

Aggregation: MetricName {FromTag} by {TagKey}

在介绍语法前，咱们先经过一组样原本解释 Metric 查询的语法。

Series	MetricName	TagValue: Host	TagValue: Owner
A	system.cpu.idle	ChengMoMacAir	chengmo
B	system.cpu.idle	UbuntuChengMo	chengmo
C	system.cpu.idle	WZL-CentOS	wangzhili

Series	00:00	01:00	02:00	03:00	04:00	05:00
A	0.3	0.5	0.1	0.2	0.8	0.1
B	0.8	0.3	0.7	0.8	0.9	0.3
C	0.6	0.2	0.4	0.6	0.1	0.1

Aggregation 和 FromTag

• Aggregation：聚合算子。指 Metric 查询范围 FromTag 所查询到的多条 series 经过 avg、max、min、sum 哪一种方式聚合。

• FromTag：查询范围。指 Metric 所需聚合的 series 的查询条件。

如：

max: system.cpu.idle {host:ChengMoMacAir, host:UbuntuChengMO}

所得的结果是：

Series	00:00	01:00	02:00	03:00	04:00	05:00
A	0.3	0.5	0.1	0.2	0.8	0.1
B	0.8	0.3	0.7	0.8	0.9	0.3
Output	0.8	0.5	0.7	0.8	0.9	0.3

一样，上述查询也能够简化成：

max: system.cpu.idle {owner:chengmo}

这就是标签管理在 Cloud Insight 的重要性啦。

by 其实就是 group_by

Cloud Insight 还支持相似 SQL 的 group_by 查询语法。这个在查看：

• 多个磁盘分区的容量

• Docker 中不一样 Container 的性能消耗

都是很是有用的。仍是以上诉例子举例，若是咱们想要看每一个 host 的 CPU 空闲率：

avg: system.cpu.idle {} by {host}

此时，第一个 {FromTag} 缺省表明从全部 Metrics 中查询数据。如图所示，获得如下图表：

在实际的测试环境中，因为咱们有 6 台测试主机，因此会获得以下的曲线。而且，当鼠标悬停至曲线时，下方的悬停窗口会分别显示 6 台主机的 system.cpu.idle。

灵活查询

聚合和分组并存

除开单纯的聚合和分组，Cloud Insight 还支持聚合和分组的复合查询。如：

avg: system.cpu.idle {} by {owner}

Series	MetricName	TagValue: Host	TagValue: Owner
A	system.cpu.idle	ChengMoMacAir	chengmo
B	system.cpu.idle	UbuntuChengMo	chengmo
C	system.cpu.idle	WZL-CentOS	wangzhili

此时，虽然有 3 个 host，可是分组是以 owner 来进行分组。因此，A 与 B 会聚合为一条曲线，而 C 和 A&B 的关系是分组的关系。

Series	00:00	01:00	02:00	03:00	04:00	05:00
A	0.3	0.5	0.1	0.2	0.8	0.1
B	0.8	0.3	0.7	0.8	0.9	0.3
C	0.6	0.2	0.4	0.6	0.1	0.1
Output A&B	0.55	0.4	0.4	0.5	0.85	0.2
Output C	0.6	0.2	0.4	0.6	0.1	0.1

多条件查询

FromTag 能够承接多个条件，如上文提到的：

max: system.cpu.idle {host:ChengMoMacAir, host:UbuntuChengMO}

查询到是两个 Host 的聚合结果。那么，若是是如下查询呢：

max: system.cpu.idle {host:ChengMoMacAir, owner:wangzhili}

此时，查询到结果为 NULL。由于，Metric 查询遵循如下原则：

• 同一 Tag Key，Metric 查询求并集；

• 不一样 Tag Key，Metric 查询求交集。

也就是说，上述查询分别表明：

• 我想查询 host 为 ChengMoMacAir 和 host:UbuntuChengMO 的聚合结果

• 我想查询 host 为 ChengMoMacAir 且 owner 为 wangzhili 的聚合结果

天然，根据表格，咱们发现这样的 Host 是不存在的，故而结果为 NULL。

咱们之因此这么设计，是由于此类思考更符合人的思惟习惯：

• 当人们选择多个 host 时，天然而然想到的是这些 host 的求和结果，即：同一 Tag Key 求并集；

• 当人们选择某个 host，又再次选择另外一个 Tag 时，想到的是在这个 host 下知足这些 tag 的结果，即：不一样 Tag Key 求交集。

参数查询

Cloud Insight 还添加了参数来提取出 {FromTag}，可让用户不用每次都修改 {FromTag} 来查看 Metric；而只需在参数下拉框中选择 {FromTag} 来动态查询 Metric。