資訊專欄INFORMATION COLUMN
摘要：而今，我們就已經(jīng)實現(xiàn)了這樣的功能使用標(biāo)簽來實現(xiàn)數(shù)據(jù)的聚合和分組。數(shù)據(jù)聚合和分組在中，我們實現(xiàn)了數(shù)據(jù)的聚合和分組。指所需聚合的的查詢條件。所以，與會聚合為一條曲線，而和的關(guān)系是分組的關(guān)系。
遙想 2015 年 8 月 17 日，Cloud Insight 還在梳理功能原型，暢想 Cloud Insight 存在的意義：為什么阿里云用戶需要使用 Cloud Insight 來加強管理。
而今，我們就已經(jīng)實現(xiàn)了這樣的功能：
使用標(biāo)簽來實現(xiàn)數(shù)據(jù)的聚合和分組。
相信使用過 OpenTSDB 或者 InfluxDB 的人都知道標(biāo)簽的存在：Tag。這也是為什么越來越多 Zabbix 或者 Nagios 用戶遷移至 OpentsDB 來自建運維監(jiān)控系統(tǒng)的原因。
如果所示，Zabbix 只提供單臺 Host 的 Disk 使用量。如果 3 臺主機，都同屬于一個組 Mi-Kafka，想要知道這個組的總體 Disk 使用量，是無法得知的。
從而，就算線上系統(tǒng)發(fā)生了故障，要在短期內(nèi)知道，到底是哪個模塊的哪個部分出了哪樣的問題，所需要的經(jīng)驗和時長都是很大的。
而 OpenTSDB 和 StatsD 的出現(xiàn)改變了現(xiàn)狀。
運維 2.0 時代在非常早期的時候，淘寶團(tuán)隊就引入了 OpenTSDB 來輔助他們的運維監(jiān)控。詳情見：OpenTSDB監(jiān)控系統(tǒng)的研究和介紹。
隨后的幾年，云計算和 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)為：
Cloud Insight 通過 3 個步驟達(dá)到操作系統(tǒng)、數(shù)據(jù)庫、中間件，以及未來通過 Developer API 對接進(jìn)來的所有 Metric 進(jìn)行處理：
Cloud Insight Agent 采集并處理 Metric；
在平臺服務(wù)儀表盤和自定義儀表盤中，提供 Metric 聚合、分組、統(tǒng)計運算、基本數(shù)學(xué)運算等操作；
針對操作的結(jié)果，提供曲線圖、柱狀圖等多樣化的展現(xiàn)形式。
數(shù)據(jù)聚合和分組在 Beta v 0.2.1 中，我們實現(xiàn)了數(shù)據(jù)的聚合和分組。沿襲了 OpenTSDB 的查詢方式：用一種類 SQL 的方式來查詢指標(biāo)。
具體操作可以訪問 Cloud Insight 文檔中心 ? Metric 查詢。
接下來我們會介紹 Cloud Insight 已經(jīng)實現(xiàn)的 Metric 的查詢，以及其中的數(shù)據(jù)聚合和分組。
語法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：聚合算子。指 Metric 查詢范圍 FromTag 所查詢到的多條 series 通過 avg、max、min、sum 哪種方式聚合。
FromTag：查詢范圍。指 Metric 所需聚合的 series 的查詢條件。
如：
max: system.cpu.idle {host:ChengMoMacAir, host:UbuntuChengMO}
所得的結(jié)果是：
| 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}
這就是標(biāo)簽管理在 Cloud Insight 的重要性啦。
Cloud Insight 還支持類似 SQL 的 group_by 查詢語法。這個在查看：
多個磁盤分區(qū)的容量
Docker 中不同 Container 的性能消耗
都是非常有用的。還是以上訴例子舉例，如果我們想要看每個 host 的 CPU 空閑率：
avg: system.cpu.idle {} by {host}
此時，第一個 {FromTag} 缺省代表從所有 Metrics 中查詢數(shù)據(jù)。如圖所示，得到以下圖表：
在實際的測試環(huán)境中，由于我們有 6 臺測試主機，所以會得到如下的曲線。并且，當(dāng)鼠標(biāo)懸停至曲線時，下方的懸停窗口會分別顯示 6 臺主機的 system.cpu.idle。
靈活查詢除開單純的聚合和分組，Cloud Insight 還支持聚合和分組的復(fù)合查詢。如：
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 來進(jìn)行分組。所以，A 與 B 會聚合為一條曲線，而 C 和 A&B 的關(guān)系是分組的關(guān)系。
| 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 的聚合結(jié)果。那么，如果是以下查詢呢：
max: system.cpu.idle {host:ChengMoMacAir, owner:wangzhili}
此時，查詢到結(jié)果為 NULL。因為，Metric 查詢遵循以下原則：
同一 Tag Key，Metric 查詢求并集；
不同 Tag Key，Metric 查詢求交集。
也就是說，上述查詢分別代表：
我想查詢 host 為 ChengMoMacAir 和 host:UbuntuChengMO 的聚合結(jié)果
我想查詢 host 為 ChengMoMacAir 且 owner 為 wangzhili 的聚合結(jié)果
自然，根據(jù)表格，我們發(fā)現(xiàn)這樣的 Host 是不存在的，故而結(jié)果為 NULL。
我們之所以這么設(shè)計，是因為此類思考更符合人的思維習(xí)慣：
當(dāng)人們選擇多個 host 時，自然而然想到的是這些 host 的求和結(jié)果，即：同一 Tag Key 求并集；
當(dāng)人們選擇某個 host，又再次選擇另一個 Tag 時，想到的是在這個 host 下滿足這些 tag 的結(jié)果，即：不同 Tag Key 求交集。
Cloud Insight 還添加了參數(shù)來提取出 {FromTag}，可以讓用戶不用每次都修改 {FromTag} 來查看 Metric；而只需在參數(shù)下拉框中選擇 {FromTag} 來動態(tài)查詢 Metric。
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/7950.html
摘要：由發(fā)明，適合于監(jiān)控基于容器的基礎(chǔ)架構(gòu)。有關(guān)其數(shù)據(jù)聚合的功能可以閱讀數(shù)據(jù)聚合分組新一代系統(tǒng)監(jiān)控的核心功能。所抓取的性能指標(biāo)算是較為全面，部署和展現(xiàn)方式都是相當(dāng)簡單易懂的。 如今，越來越多的公司開始使用 Docker 了，2 / 3 的公司在嘗試了 Docker 后最終使用了它。為了能夠更精確的分配每個容器能使用的資源，我們想要實時獲取容器運行時使用資源的情況，怎樣對 Docker 上的應(yīng)...
摘要：監(jiān)控告警是運營系統(tǒng)最核心的功能之一，騰訊內(nèi)部有一套很成熟的監(jiān)控告警平臺，而且開發(fā)運維同學(xué)已經(jīng)習(xí)慣這套平臺，如果我們針對容器再開發(fā)一個監(jiān)控告警平臺，會花費很多精力，而且沒有太大的意義。也是一款付費監(jiān)控解決方案，計劃收費方案是美分小時。 如今，越來越多的公司開始使用 Docker 了，現(xiàn)在來給大家看幾組數(shù)據(jù)： 2 / 3 的公司在嘗試了 Docker 后最終使用了它 也就是說 Docker...
摘要：靈活查詢，聚合分組并存除開單純的聚合和分組，還支持聚合和分組的復(fù)合查詢。所以，與會聚合為一條曲線，而和的關(guān)系則是分組的關(guān)系。當(dāng)然，的功能在未來，還遠(yuǎn)遠(yuǎn)不止這些，高效運維的時代才剛剛開啟。 運維 2.0 時代 運維 2.0 是指，從技術(shù)運維升級為服務(wù)運維，向公司提供可依賴的專業(yè)服務(wù)。運維 2.0 強調(diào)服務(wù)交付能力，而不是技術(shù)能力，需求可依賴、懂業(yè)務(wù)、服務(wù)化的專業(yè)運維。 為了了解運維 2....
摘要：每秒實時處理超過萬項監(jiān)控指標(biāo)，讓異常無所遁形。此外，對于復(fù)雜數(shù)據(jù)庫故障事后排查故障根源現(xiàn)場還原歷史事件追蹤也迫使我們建設(shè)一個覆蓋線上所有環(huán)境數(shù)據(jù)庫實例事件的監(jiān)控系統(tǒng)，做到覆蓋阿里全球子公司所有機房。所有性能指標(biāo)做到秒級連續(xù)不間斷監(jiān)控。 摘要： 2017雙11再次創(chuàng)下了32.5萬筆/秒交易創(chuàng)建的紀(jì)錄，在這個數(shù)字后面，更是每秒多達(dá)幾千萬次的數(shù)據(jù)庫寫入，如何大規(guī)模進(jìn)行自動化操作、保證數(shù)據(jù)庫的...
閱讀 3543·2021-11-22 15:22
閱讀 3333·2019-08-30 15:54
閱讀 2729·2019-08-30 15:53
閱讀 816·2019-08-29 11:22
閱讀 3537·2019-08-29 11:14
閱讀 2077·2019-08-26 13:46
閱讀 2217·2019-08-26 13:24
閱讀 2280·2019-08-26 12:22
