摘要：靈活查詢，聚合分組并存除開單純的聚合和分組，還支持聚合和分組的復(fù)合查詢。所以，與會聚合為一條曲線，而和的關(guān)系則是分組的關(guān)系。當(dāng)然，的功能在未來，還遠(yuǎn)遠(yuǎn)不止這些，高效運(yùn)維的時代才剛剛開啟。

運(yùn)維 2.0 是指，從技術(shù)運(yùn)維升級為服務(wù)運(yùn)維，向公司提供可依賴的專業(yè)服務(wù)。運(yùn)維 2.0 強(qiáng)調(diào)服務(wù)交付能力，而不是技術(shù)能力，需求可依賴、懂業(yè)務(wù)、服務(wù)化的專業(yè)運(yùn)維。

為了了解運(yùn)維 2.0 時代的監(jiān)控方式，我們不妨從以前的監(jiān)控手段說起。首先來了解一下 Zabbix ，通過 Zabbix 能夠監(jiān)視各種網(wǎng)絡(luò)參數(shù)，保證服務(wù)器系統(tǒng)的安全運(yùn)營；并提供靈活的通知機(jī)制以讓系統(tǒng)管理員快速定位和解決存在的各種問題。但時代在推進(jìn)，如今 Zabbix 的功能真的就能滿足廣大開發(fā)者們么？

如果你是阿里云的用戶，或者使用過 Zabbix，你將明顯感受到一個痛點(diǎn)：沒有辦法對數(shù)據(jù)做聚合，只能挨個查看主機(jī)的性能指標(biāo)，更不用說有管理的功能了。

如上圖，Zabbix 只提供單臺 Host 的 Disk 使用量。如果 3 臺主機(jī)，同屬于一個組 Mi-Kafka，就沒法知道這個組總體 Disk 使用量了。

因此，就算線上系統(tǒng)發(fā)生了故障，要在短期內(nèi)知道，到底是哪個模塊的哪個部分出了什么樣的問題，所需要的經(jīng)驗(yàn)和時長都是巨大的。

而 OpenTSDB 和 StatsD 的出現(xiàn)改變了現(xiàn)狀。

OpenTSDB 是什么呢，一個開源監(jiān)控系統(tǒng)，可以從大規(guī)模的集群（包括集群中的網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用程序）中獲取相應(yīng)的 Metrics 同時進(jìn)行存儲、索引以及服務(wù)，從而使得這些數(shù)據(jù)更容易讓人理解。

如今越來越多的企業(yè)開始使用混合云模式，來建設(shè)數(shù)據(jù)中心。私有云和公有云，以及集群系統(tǒng)，讓監(jiān)控工作變得異常復(fù)雜。所以，以下幾個方面在運(yùn)維監(jiān)控中顯得尤為重要：

性能指標(biāo)的采集的輕量化；

性能指標(biāo)能夠集中在一個平臺進(jìn)行管理和可視化；

能夠?qū)π阅苤笜?biāo)進(jìn)行靈活的組合和計(jì)算。

打個簡單的比方，一家廣告監(jiān)控平臺購買 AWS 的 50 臺 EC2 來進(jìn)行數(shù)據(jù)的采集，而數(shù)據(jù)分析則是本地的 10 臺服務(wù)器來支持。

如果還在使用傳統(tǒng)運(yùn)維工具 Zabbix，這時候就會遇到一個問題，AWS 控制臺可以看到這 50 臺的監(jiān)控指標(biāo)。也就意味著，運(yùn)維工程師需要使用 Zabbix 和 AWS 控制臺來同時管理監(jiān)控?cái)?shù)據(jù)。

同時關(guān)注多集群中多個節(jié)點(diǎn)的運(yùn)行情況，以及需要查看不同中間件的指標(biāo)來發(fā)現(xiàn)問題，或者想要通過 Zabbix 集成短信報(bào)警渠道，這些讓運(yùn)維工作變得不堪重負(fù)。

而在非常早期的時候，淘寶團(tuán)隊(duì)就引入了 OpenTSDB 來輔助他們的運(yùn)維監(jiān)控。

隨后的幾年，云計(jì)算和 SaaS 的興起，國外也出現(xiàn)了多種采用 StatsD 和 OpenTSDB 的開源工具搭建的 SaaS 服務(wù)：Boundary、CopperEgg、Datadog 等等。

他們都不約而同地采用了同一種產(chǎn)品邏輯，也是 Cloud Insight 的產(chǎn)品邏輯————時間序列數(shù)據(jù)庫的邏輯。

任何的性能指標(biāo)，都作為時間序列數(shù)據(jù)被采集和處理；

任何的 Host 等歸屬于性能指標(biāo)的屬性，都作為指標(biāo)的標(biāo)簽信息。

而在產(chǎn)品邏輯上，則表現(xiàn)為：

運(yùn)維 2.0 時代有一款有趣的監(jiān)控產(chǎn)品——Cloud Insight，它支持多種操作系統(tǒng)、云主機(jī)、數(shù)據(jù)庫和中間件的監(jiān)控，通過標(biāo)簽，對基礎(chǔ)設(shè)施進(jìn)行有效地管理，讓您輕松應(yīng)對復(fù)雜的基礎(chǔ)設(shè)施架構(gòu)。來幫助所有的 IT 公司，減少在系統(tǒng)監(jiān)控上的人力和時間成本投入，讓運(yùn)維工作變得更加高效、簡單。

視角決定高度，在此基礎(chǔ)之上，Cloud Insight 還能夠?qū)?shù)據(jù)指標(biāo)進(jìn)行聚合、分組、過濾、管理、計(jì)算；并提供團(tuán)隊(duì)協(xié)作功能，共同管理數(shù)據(jù)和報(bào)警事件。所以，Cloud Insight 也是一個數(shù)據(jù)管理平臺，幫助企業(yè)內(nèi)部加強(qiáng)溝通和協(xié)作，填補(bǔ)部門間、人員間、技能間的溝通鴻溝。

Cloud Insight 通過 3 個步驟深入操作系統(tǒng)、數(shù)據(jù)庫、中間件，以及未來通過 Developer API 對接進(jìn)來的所有 Metric 進(jìn)行處理：

Cloud Insight Agent 采集并處理 Metric；

在平臺服務(wù)儀表盤和自定義儀表盤中，提供 Metric 聚合、分組、統(tǒng)計(jì)運(yùn)算、基本數(shù)學(xué)運(yùn)算等操作；

針對操作的結(jié)果，提供曲線圖、柱狀圖等多樣化的展現(xiàn)形式。

自定義儀表盤

數(shù)據(jù)聚合

遙想 2015 年 8 月 17 日，Cloud Insight 還在梳理功能原型，暢想 Cloud Insight 存在的意義，而一轉(zhuǎn)眼，我們已經(jīng)實(shí)現(xiàn)了很有意思的功能：

自定義儀表盤

Cloud Insight 已經(jīng)可以自定義儀表盤了，除了在數(shù)據(jù)展現(xiàn)上清晰直觀，它還擁有一個炫酷的本事：隨意拖拽。

使用標(biāo)簽來實(shí)現(xiàn)數(shù)據(jù)聚合&分組

在 Beta v 0.2.1 中，我們實(shí)現(xiàn)了數(shù)據(jù)的聚合和分組。沿襲了 OpenTSDB 的查詢方式：用一種類 SQL 的方式來查詢指標(biāo)。

具體操作可以訪問 Cloud Insight 文檔中心 ? Metric 查詢。

Cloud Insight 還支持類似 SQL 的 group_by 查詢語法。這個在查看多個磁盤分區(qū)的容量和Docker 中不同 Container 的性能消耗時都是非常有用的。

例子舉例，如果我們想要看每個 host 的 CPU 空閑率：

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

此時，第一個 {FromTag} 缺省代表從所有 Metrics 中查詢數(shù)據(jù)。如圖所示，得到以下圖表：

在實(shí)際的測試環(huán)境中，由于我們有 6 臺測試主機(jī)，所以會得到如下的曲線。并且，當(dāng)鼠標(biāo)懸停至曲線時，下方的懸停窗口會分別顯示 6 臺主機(jī)的 system.cpu.idle。

除開單純的聚合和分組，Cloud Insight 還支持聚合和分組的復(fù)合查詢。如：

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

此時，雖然有 3 個 host，但是分組是以 owner 來進(jìn)行的。所以，A 與 B 會聚合為一條曲線，而 C 和 A&B 的關(guān)系則是分組的關(guān)系。

當(dāng)然，Cloud Insight 的功能在未來，還遠(yuǎn)遠(yuǎn)不止這些，高效運(yùn)維的時代才剛剛開啟。