文章目錄

• 監控圈子行業黑話
• • 監控
  • 監控系統
  • 監控指標
  • • 全局唯一字符串作為指標標識
    • 標簽集的組合作為指標標識
    • 優雅高效的 Influx 指標格式
    • 指標類型
    • • Gauge
      • Counter
      • Histogram
      • Summary
  • 時序庫
  • • • 時序數據
  • 告警
  • • 告警收斂
    • 告警閉環

監控圈子行業黑話

監控

一般我們說監控 MySQL、監控 Redis 的時候，都是指能夠采集到 MySQL、Redis 的監控數據，并能可視化展示。這時候監控表示數據采集和可視化，不包括告警引擎和事件處理。

監控系統

當我們講監控系統的時候，因為說的是整個系統，所以也會包含告警和事件發送等相關功能。

監控指標

監控指標是指數值類型的監控數據，比如某個機器的內存利用率，某個 MySQL 實例的當前連接數，某個 Redis 的最大內存上限等等。不同的監控系統，對于監控指標有不同的描述方式，典型的方式有三種，下面我們分別介紹一下。

全局唯一字符串作為指標標識

監控指標通常是一個全局唯一的字符串，比如某機器的內存利用率 host.10.2.3.4.mem_used_percent，這個字符串中包含了機器的信息，也包含了指標名，可以唯一標識一條監控指標。假設監控數據采集的頻率是 30 秒，2 分鐘內采集了 4 個數據點，一個數據點包含一個時間戳和一個值，我們看一下如何用 JSON 表示這個監控指標及其監控數據。

{"name": "host.10.2.3.4.mem_used_percent","points": [{"clock": 1662449136,"value": 45.4},{"clock": 1662449166,"value": 43.2},{"clock": 1662449196,"value": 44.9},{"clock": 1662449226,"value": 44.8}] }

相對老一些的監控系統，比如 Graphite，就是使用這種方式來標識監控指標的。一些老的監控數據采集器，比如 Collectd，也是這樣標識監控指標的。

雖然這種方式一目了然，非常清晰，但是缺少對維度信息的描述，不便于做聚合計算。比如下面幾條用于描述 HTTP 請求狀態碼的指標。

myhost.service1.http_request.200.get myhost.service1.http_request.200.post myhost.service1.http_request.500.get myhost.service1.http_request.500.post myhost.service2.http_request.200.get myhost.service2.http_request.500.post

myhost 這個機器上部署了兩個服務，分別是 service1 和 service2。有些請求狀態碼是 200，有些是 500，有些 HTTP method 是 get，有些是 post。我們想分別統計這些指標的數量，就要把這些分類維度信息都拼到指標標識中。但是這樣做會產生兩個弊端：一是看起來比較混亂，二是不方便聚合統計。

標簽集的組合作為指標標識

OpenTSDB 的數據示例

mysql.bytes_received 1287333217 327810227706 schema=foo host=db1 mysql.bytes_sent 1287333217 6604859181710 schema=foo host=db1 mysql.bytes_received 1287333232 327812421706 schema=foo host=db1 mysql.bytes_sent 1287333232 6604901075387 schema=foo host=db1 mysql.bytes_received 1287333321 340899533915 schema=foo host=db2 mysql.bytes_sent 1287333321 5506469130707 schema=foo host=db2

上面這 6 條監控指標，都通過空格把指標分隔成了多個字段。第一段是指標名，第二段是時間戳（單位是秒），第三段是指標值，剩下的部分是多個標簽（tags/labels），每個標簽都是 key=value 的格式，多個標簽之間使用空格分隔。

了 OpenTSDB，新時代的時序庫大都引入了標簽的概念，比如 Prometheus，它們甚至認為指標名也是一種特殊的標簽（其標簽 key 是 name ），所以 Prometheus 僅僅使用標簽集作為指標標識，從 Prometheus 的數據結構定義中就可以看出來。

message Sample {double value = 1;int64 timestamp = 2; }message Label {string name = 1;string value = 2; }message TimeSeries {repeated Label labels = 1 [(gogoproto.nullable) = false];repeated Sample samples = 2 [(gogoproto.nullable) = false]; }

TimeSeries 這個結構中并沒有一個單獨的 metric 字段，指標名的信息實際是放到了 labels 數組中了。

優雅高效的 Influx 指標格式

nfluxData 公司有一款開源時序庫非常有名，叫InfluxDB，InfluxDB 在接收監控數據寫入時，設計了一個非常精巧的指標格式，一行可以傳輸多個指標。

mesurement,labelkey1=labelval1,labelkey2=labelval2 field1=1.2,field2=2.3 timestamp

總體來看，分為 4 個部分，measurement,tag_set field_set timestamp，其中 tag_set 是可選的，tag_set 與前面的 measurement 之間用逗號分隔，其他各個部分之間都是用空格來分隔的。我們可以通過下面的例子來理解。

weather,location=us-midwest temperature=82 1465839830100400200| -------------------- -------------- || | | || | | | +-----------+--------+-+---------+-+---------+ |measurement|,tag_set| |field_set| |timestamp| +-----------+--------+-+---------+-+---------+

我們把上面 OpenTSDB 的指標示例改寫成 Influx 格式，結果是這樣的。

mysql,schema=foo,host=db1 bytes_received=327810227706,bytes_sent=6604859181710 1287333217000000000 mysql,schema=foo,host=db1 bytes_received=327812421706,bytes_sent=6604901075387 1287333232000000000 mysql,schema=foo,host=db2 bytes_received=340899533915,bytes_sent=5506469130707 1287333321000000000

注意，時間戳的單位是納秒。這種寫法設計很精巧，標簽重復度低，field 越多的情況下它的優勢越明顯，網絡傳輸的時候可以節省更多帶寬。當然了，OpenTSDB 的格式或者 Prometheus 的格式如果做了數據壓縮，節省帶寬的效果也是不錯的，因為字符的壓縮效果一般比較明顯。現如今機房內部通信動輒萬兆網卡，這個流量的大小區別倒也不用太關注。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-fbKPk6I6-1673924951575)(…\images\image-20230116112109573.png)]

指標類型

有些監控系統是不區分指標類型的，有些會做區分。90 年代左右社區就出現了一款作品 RRDtool，它是一個環形數據庫，也是一個繪圖引擎，很多監控工具都是使用 RRDtool 來存儲或繪制監控趨勢圖的，比如 Cacti、MRTG、Zabbix 等等。RRDtool 還提出了數據類型的概念，支持 GAUGE、COUNTER、DERIVE、DCOUNTER、DDERIVE、ABSOLUTE 等多種數據類型。

Prometheus 生態也支持數據類型，分為 Gauge、Counter、Histogram、Summary4 種，下面我們簡單了解一下 Prometheus 的這 4 種類型。

Gauge

測量值類型，可大可小，可正可負。這種類型的數據，我們通常關注的是當前值，比如房間里的人數、隊列積壓的消息數、今年公司的收入和凈利潤。

Counter

表示單調遞增的值，比如操作系統自啟動以來網卡接收到的所有流量包的數量。每接收到一個包，操作系統就會加 1，所以這個值是持續遞增的。但是操作系統可能會重啟，導致這個值出現重置，比如第一次是從 0 一直漲到了 239423423，然后機器重啟，新采集的數據是一些比 239423423 小很多的值，這種情況怎么辦？此時 Prometheus 看到值沒有遞增，就能感知到重置的情況，會把新采集的值加上 239423423 再做計算。

Histogram

直方圖類型，用于描述數據分布，最典型的應用場景就是監控延遲數據，計算 90 分位、99 分位的值。所謂的分位值，就是把一批數據從小到大排序，然后取 X% 位置的數據，90 分位就是指樣本數據第 90% 位置的值。

Summary

Summary 這種類型是在客戶端計算分位值，然后把計算之后的結果推給服務端存儲，展示的時候直接查詢即可，不需要做很重的計算，性能大幅提升。

時序庫

時序庫（Time series database）是一種專門處理時序數據的數據庫 。我們常見的數據庫中，MySQL 是關系型數據庫，Redis 是 KV 數據庫，MongoDB 是文檔數據庫，而 InfluxDB、VictoriaMetrics、M3DB 等都是時序庫，Prometheus 其實也內置實現了一個時序存儲模塊。

時序數據

時序數據最大的特點是每一條數據都帶有時間戳，通常是單調順序，不會亂序，流式發給服務端，通常不會修改，比如指標數據和日志數據，都是典型的時序數據。

告警

告警收斂

基礎設施層面的故障，比如基礎網絡問題，可能會瞬間產生很多告警事件，形成告警風暴，導致接收告警的媒介擁塞，比如手機不停接收到短信和電話呼入，沒辦法使用。這個時候，我們就要想辦法讓告警事件變少，用的方法就是告警收斂。

最典型的手段是告警聚合發送，聚合可以采用不同的維度，比如時間維度、策略維度、監控對象維度等等。如果 100 臺機器同時報失聯，就可以合并成一條告警通知，減少打擾。

另外一個典型的收斂手段是把多個事件聚合成告警，把多個告警聚合成故障。比如某個機器的 CPU 利用率告警，監控系統可能每分鐘都會產生一條事件，這多個事件的告警規則、監控對象、監控指標都相同，所以可以收斂為一條告警。假設有 100 臺機器都告警了，其中 50 臺屬于業務 A，另外 50 臺屬于業務 B，我們可以按照業務來做聚合，聚合之后產生兩個故障，這樣就可以起到很好的收斂效果。

告警閉環

閉環這個詞是個互聯網黑話，表示某個事情有始有終，告警怎么判斷是否閉環了呢？問題最終被解決，告警恢復，就算是閉環了。產品怎么設計才能保證告警閉環呢？通常來講，沒人響應的告警能夠升級通知，告警 oncall 人員可以認領告警，基本就有比較好的保障了。

《運維監控系統實戰筆記》 學習筆記 day2

總結

以上是生活随笔為你收集整理的监控圈子行业黑话的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。