白話運維監控系統-1.3 監控名額描述方法

上一章我們大體看到了Linux、Redis相關的一些名額，大夥可能對監控名額是啥有了個大概了解。那在監控系統裡，怎麼表示一條名額呢？本章來解釋這個問題。

比如我們要監控Linux系統的CPU、記憶體相關名額，我們通常會部署一個daemon程序在OS上，然後周期性去采集相關名額，上報給監控服務端。采集到的資料推送給服務端，具體是推送了個啥資料結構？我們來看看各個系統的實作。

Open-Falcon名額示例

以Open-Falcon舉例，某個機器的CPU空閑率名額在某個時間點的值，用這種方式表示：

{
    "endpoint": "10.3.4.5",
    "metric": "cpu.idle",
    "tags": "region=bj,dept=cloud",
    "value": 45.5,
    "timestamp": 1619351826,
    "counterType": "GAUGE",
    "step": 60
}           

這裡邊比較重要的是metric，表示名額名稱，timestamp表示采集資料點的那一刻的時間戳，value表示值，為了辨別這個資料是來自哪個機器的，有個endpoint字段，另外還有一些多元度資訊放在tags裡，上例表示bj區域，cloud這個部門，便于未來做一些聚合計算，比如求取cloud部門的所有機器的平均cpu.idle（是以tags這種次元資訊是非常重要的，便于做聚合，像Zabbix這種老一代監控系統就缺少了這種設計，導緻不友善做聚合計算，是以很少有人會拿Zabbix做應用、業務層面的監控）。

counterType表示資料類型，Open-Falcon支援GAUGE和COUNTER兩種類型，這個類型概念其實不是必須的，有些時序庫壓根就不支援資料類型的概念，step表示監控名額的采集上報頻率，因為Open-Falcon底層存儲用的rrdtool，rrd檔案存儲對step字段是必須的。

OpenTSDB名額示例

OpenTSDB是一款時序資料庫，用來存儲監控資料，因為監控資料是一種典型的時序資料，是以很多公司使用OpenTSDB作為監控系統的底層存儲。

mysql.bytes_received 1287333217 327810227706 schema=foo host=db1           

mysql.bytes_received是名額名稱，1287333217是UNIX時間戳，327810227706是名額的值，schema=foo host=db1是tags，和Open-Falcon很像，更簡單了，少了endpoint、counterType、step字段。

Prometheus的資料結構和OpenTSDB基本完全一緻。對于名額資料來自哪個機器，并沒有一個類似endpoint那樣的字段表示，而是直接放到tags裡了，從監控的角度來看，這兩種表示方式其實沒有本質的差別，不過在傳統實體機、虛拟機時代，服務混部場景較多，我更傾向于提出這個單獨的字段的設計，後面夜莺的設計就是這樣的，至于原因，後面系列的文章會聊到。

Nightingale名額示例

熟悉我的人可能知道，現在已經基本不再維護Open-Falcon了，主要精力都放到夜莺上了，即Nightingale，大家可以把Nightingale看做Open-Falcon的下一代。最近在籌劃v5版本，v5會是我目前認知裡最好的一個版本，v5的監控資料結構會設計成什麼樣子呢？如下：

{
    "ident": "10.3.4.5",
    "alias": "c3-n9e-server01.bj",
    "metric": "cpu.idle",
    "tags": "region=bj,dept=cloud",
    "value": 45.5,
    "time": 1619351826,
    "type": "gauge",
    "extra": ""
}           

和Open-Falcon的設計很像，去掉了step字段，加了一個extra字段，這些都不重要，endpoint拆成了兩個字段，一個ident，一個alias，其實看起來變化也不大。

最大的變化，是Open-Falcon不允許endpoint留白，Nightingale裡會允許ident、alias留白，一個不允許留白，一個允許，變化看起來也不大，非也非也，Open-Falcon看圖、告警政策，大都是依賴endpoint設計的，而Nightingale v5不會強依賴這個字段，初衷是希望Nightingale v5即可以友善的解決傳統實體機、虛拟機的場景，也可以友善的解決非裝置相關的監控，比如應用、業務層面的監控。

CPU、記憶體這種名額，都是跟裝置相關的，但是很多名額其實跟裝置無關，比如某個服務的某個接口的整體通路延遲：

{
    "metric": "api.latency",
    "tags": "region=bj,service=n9e-server,api=/v1/users,method=get",
    "value": 20,
    "time": 1619351826,
    "type": "gauge"
}           

• 白話運維監控系統-1.1 運維監控系統概述
• 白話運維監控系統-1.2 監控名額舉例