數據聚合 & 分組：新一代系統監控的核心功能

遙想 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。