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

lijinke666 發布于2019-05-28 16:59 / 2271人閱讀

摘要：而今，我們就已經實現了這樣的功能使用標簽來實現數據的聚合和分組。數據聚合和分組在中，我們實現了數據的聚合和分組。指所需聚合的的查詢條件。所以，與會聚合為一條曲線，而和的關系是分組的關系。

遙想 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 進行處理：

Cloud Insight Agent 采集并處理 Metric；

在平臺服務儀表盤和自定義儀表盤中，提供 Metric 聚合、分組、統計運算、基本數學運算等操作；

針對操作的結果，提供曲線圖、柱狀圖等多樣化的展現形式。

數據聚合和分組

在 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。

云服務器 GPU云服務器數據庫系統的核心 java8 分組聚合數據庫系統的核心是堡壘機的核心功能4a

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/7950.html

Docker 監控- Prometheus VS Cloud Insight

摘要：由發明，適合于監控基于容器的基礎架構。有關其數據聚合的功能可以閱讀數據聚合分組新一代系統監控的核心功能。所抓取的性能指標算是較為全面，部署和展現方式都是相當簡單易懂的。如今，越來越多的公司開始使用 Docker 了，2 / 3 的公司在嘗試了 Docker 后最終使用了它。為了能夠更精確的分配每個容器能使用的資源，我們想要實時獲取容器運行時使用資源的情況，怎樣對 Docker 上的應...

liuyix 2019-06-28 15:04 評論0 收藏0
Docker 監控實戰

摘要：監控告警是運營系統最核心的功能之一，騰訊內部有一套很成熟的監控告警平臺，而且開發運維同學已經習慣這套平臺，如果我們針對容器再開發一個監控告警平臺，會花費很多精力，而且沒有太大的意義。也是一款付費監控解決方案，計劃收費方案是美分小時。如今，越來越多的公司開始使用 Docker 了，現在來給大家看幾組數據： 2 / 3 的公司在嘗試了 Docker 后最終使用了它也就是說 Docker...

william 2019-06-28 15:04 評論0 收藏0
運維 2.0 時代：數據聚合和分組

摘要：靈活查詢，聚合分組并存除開單純的聚合和分組，還支持聚合和分組的復合查詢。所以，與會聚合為一條曲線，而和的關系則是分組的關系。當然，的功能在未來，還遠遠不止這些，高效運維的時代才剛剛開啟。運維 2.0 時代運維 2.0 是指，從技術運維升級為服務運維，向公司提供可依賴的專業服務。運維 2.0 強調服務交付能力，而不是技術能力，需求可依賴、懂業務、服務化的專業運維。為了了解運維 2....

skinner 2019-05-28 16:58 評論0 收藏0
2017雙11技術揭秘—阿里數據庫進入全網秒級實時監控時代

摘要：每秒實時處理超過萬項監控指標，讓異常無所遁形。此外，對于復雜數據庫故障事后排查故障根源現場還原歷史事件追蹤也迫使我們建設一個覆蓋線上所有環境數據庫實例事件的監控系統，做到覆蓋阿里全球子公司所有機房。所有性能指標做到秒級連續不間斷監控。摘要： 2017雙11再次創下了32.5萬筆/秒交易創建的紀錄，在這個數字后面，更是每秒多達幾千萬次的數據庫寫入，如何大規模進行自動化操作、保證數據庫的...

jk_v1 2019-06-24 17:55 評論0 收藏0