iT邦幫忙

2021 iThome 鐵人賽

DAY 7
2
DevOps

這個 site 就是遜啦 - SRE 30 天登大人之旅系列 第 7

Day 7:Prometheus

講到監控,Prometheus 應該算是最常被提及的其中一個工具,它是一套開源的監控與警報系統,最早由 SoundCloud 開發,並在 2016 年進入 CNCF 孵化器,後來於 2018 年畢業。

架構

那麼,Prometheus 究竟是做什麼用的呢?讓我們來看看這張來自官方文件的架構圖:

本體

Prometheus 的本體主要包含三個部分:

  • Retrieval 代表的是它蒐集資料的元件,我們在架設 Prometheus 的時候需要設定他要從那些地方,如何去蒐集指標。
  • TSDB 是 time series database 的縮寫,裡面存放的就是 Prometheus 收集來的各項數據,並且包含了時間戳的資訊,以方便我們根據時間查詢。
  • HTTP server 讓我們可以透過 HTTP 請求,使用 PromQL (類似 SQL,查詢 Prometheus 的資料用的)去查詢它收集到的指標。並且它本身也有提供一個簡易的 UI 介面可以視覺化目前收集的資料,可是在這部分,比較常見的做法應該還是使用 Grafana 來建立儀錶板,預計後面會提到。

資料來源

Prometheus 採用 pull-based 的設計,也就是說並非由我們主動提供數據給 Prometheus server,而是我們在服務上面提供取得指標的方法(通常是透過對 /metrics 發 GET 請求),然後再由 Prometheus 採集指標。在官方文件可以看到已經有許多現成的 exporter,像是昨天提到的需要收集硬碟的使用率,就可以透過官方的 node exporter 做到。

然而在某些情況下,我們可能沒辦法提供一個可以拉取的介面給 Prometheus,這時候就需要主動推送指標給 Pushgateway,讓他暫存這些指標,然後再由 server 去採集這些指標收進 TSDB 裡面。具體的應用場景可以參考官方文件的分析

Alertmanager

警報也是監控系統裡面很重要的一環,Prometheus 裡面就有提供一個專門做警報的元件,稱為 Alertmanager,它可以收集從 Prometheus server 送過來的警報,再依據我們設立的規則分配至像是 email 或是 slack 等地方。

指標

在 Prometheus 裡面,所有的資料都會被儲存為 time series,也就是說每一筆資料都會配上一個時間戳。而指標除了儲存單個數字以外,還可以在上面加上標籤 (label) 以幫助我們替指標分類,舉昨天談到的黃金訊號之一的延遲來說好了,今天我們紀錄了 HTTP 請求的處理時間,我們來可以替它加上像是 status code、URL 等等的標籤,就可以幫助我們分離成功跟失敗的請求,更好地反應出服務現在的狀態。

小結

今天打的內容比我想像中的還要少不少...本來還希望可以把 Prometheus 跟一些其他常用的工具做一些比較的,像是跟 InfluxDB (TICK stack),或是 ThanosCortex 之類的解決方案;也有打算來談談有關 OpenTelemetry 與監控生態圈的關係,或者說規範這件事對於軟體開發的影響。

無奈於自身實務經驗實在是不足,我就先將一些我看到的參考資料列在下方,希望有朝一日有機會可以補足這份遺憾吧。

參考資料


上一篇
Day 6:監控系統的設計
下一篇
Day 8:架設 Prometheus (0)
系列文
這個 site 就是遜啦 - SRE 30 天登大人之旅30

尚未有邦友留言

立即登入留言