基於時序資料庫做監控,這裡有超流行的開源方案
在微服務架構下,我們對服務進行了拆分,所以使用者的每次請求不再是由某一個服務獨立完成了,而是變成了多個服務一起配合完成。這種情況下,一旦請求出現異常,我們必須得知道是在哪個服務環節出了故障,就需要對每一個服務,以及各個指標都進行全面的監控。
一、什麼是「 監控系統 」?
在微服務架構中,監控系統按照原理和作用大致可以分為三類(並非嚴格分類,僅從日常使用角度來看):
日誌類(Log);
呼叫鏈類(Tracing);
度量類(Metrics)。
下面來分別對這三種常見的監控模式進行說明。
日誌類比較常見,我們的框架程式碼、系統環境,以及業務邏輯中一般都會產出一些日誌,這些日誌我們通常把它記錄後統一收集起來,方便在需要的時候進行查詢。
日誌類記錄的資訊一般是一些事件、非結構化的一些文字內容。日誌的輸出和處理的解決方案比較多,大家熟知的有ELK Stack方案(Elasticseach + Logstash + Kibana),如圖:
使用Beats(可選)在每臺伺服器上安裝後,作為日誌客戶端收集器,然後透過Logstash進行統一的日誌收集、解析、過濾等處理,再將資料傳送給Elasticsearch中進行儲存分析,最後使用Kibana來進行資料的展示。
當然還可以升級方案為:
這些方案都比較成熟,搭建起來也比較簡單,除了用作監控系統以外,還可以作為日誌查詢系統使用,非常適用於做分析、以及問題除錯使用。
呼叫鏈類監控主要是指記錄一個請求的全部流程。一個請求從開始進入,在微服務中呼叫不同的服務節點後,再返回給客戶端,在這個過程中透過呼叫鏈引數來追尋全鏈路行為。透過這個方式可以很方便的知道請求在哪個環節出了故障,系統的瓶頸在哪兒。
這一類的監控一般採用CAT工具 來完成,一般在大中型專案較多用到,因為搭建起來有一定的成本。後面會有單獨文章來講解這個呼叫鏈監控系統。
這也是簡單的容錯方式。就是指在服務之間呼叫時,設定一個主動超時時間,超過了這個時間閾值後,如果“被依賴的服務”還沒有返回資料的話,“呼叫者”就主動放棄,防止因“被依賴的服務”的故障所影響。
度量類主要採用時序資料庫的解決方案。它是以事件發生時間以及當前數值的角度來記錄的監控資訊,是可以聚合運算的,用於檢視一些指標資料和指標趨勢。所以這類監控主要不是用來查問題的,主要是用來看趨勢的。
Metrics一般有5種基本的度量型別:
Gauges(度量);
Counters(計數器);
Histograms(直方圖);
Meters(TPS計算器);
Timers(計時器)。
基於時間序列資料庫的監控系統是非常適合做監控告警使用的,所以現在也比較流行這個方案,如果我們要搭建一套新的監控系統,我也建議參考這類方案進行。
因此本文接下來也會重點以時間序列資料庫的監控系統為主角來描述。
二、「 監控系統 」關注的物件和指標都是什麼?
一般我們做「監控系統」都是需要做分層式監控的,也就是說將我們要監控的物件進行分層,一般主要分為:
系統層:系統層主要是指CPU、磁碟、記憶體、網路等伺服器層面的監控,這些一般也是運維同學比較關注的物件;
應用層:應用層指的是服務角度的監控,比如介面、框架、某個服務的健康狀態等,一般是服務開發或框架開發人員關注的物件;
使用者層:這一層主要是與使用者、與業務相關的一些監控,屬於功能層面的,大多數是專案經理或產品經理會比較關注的物件。
知道了監控的分層後,我們再來看一下監控的指標一般有哪些:
延遲時間:主要是響應一個請求所消耗的延遲,比如某介面的HTTP請求平均響應時間為100ms;
請求量:是指系統的容量吞吐能力,例如每秒處理多少次請求(QPS)作為指標;
錯誤率:主要是用來監控錯誤發生的比例,比如將某介面一段時間內呼叫時失敗的比例作為指標。
三、基於時序資料庫的「 監控系統 」有哪些?
下面介紹幾款目前業內比較流行的基於時間序列資料庫的開源監控方案。
Prometheus是一款2012年開源的監控框架,其本質是時間序列資料庫,由Google前員工所開發。
Prometheus採用拉的模式(Pull)從應用中拉取資料,並還支援Alert模組可以實現監控預警。它的效能非常強勁,單機可以消費百萬級時間序列。
架構如下:
從看圖的左下角可以看到,Prometheus可以透過在應用裡進行埋點後Pull到Prometheus Server裡,如果應用不支援埋點,也可以採用exporter方式進行資料採集。
從圖的左上角可以看到,對於一些定時任務模組,因為是週期性執行的,所以採用拉的方式無法獲取資料,那麼Prometheus也提供了一種推資料的方式,但是並不是推送到Prometheus Server中,而是中間搭建一個Pushgateway,定時任務模組將metrics資訊推送到這個Pushgateway中,然後Prometheus Server再依然採用拉的方式從Pushgateway中獲取資料。
需要拉取的資料既可以採用靜態方式配置在Prometheus Server中,也可以採用服務發現的方式(即圖的中上方Service discovery所示)。
PromQL:是Prometheus自帶的查詢語法,透過編寫PromQL語句可以查詢Prometheus裡面的資料。
Alertmanager:是用於資料的預警模組,支援透過多種方式去傳送預警。
WebUI:是用來展示資料和圖形的,但是一般大多數是與Grafana結合,採用Grafana來展示。
OpenTSDB是在2010年開源的一款分散式時序資料庫,當然其主要用於監控方案中。
OpenTSDB採用的是HBase的分散式儲存,它獲取資料的模式與Prometheus不同,採用的是推模式(Push)。
在展示層,OpenTSDB自帶有WebUI檢視,也可以與Grafana很好的整合,提供豐富的展示介面。
但OpenTSDB並沒有自帶預警模組,需要自己去開發或者與第三方元件結合使用。
可以透過下圖來了解一下OpenTSDB的架構:
InfluxDB是在2013年開源的一款時序資料庫,在這裡我們主要還是用於做監控系統方案。它收集資料也是採用推模式(Push)。在展示層,InfluxDB也是自帶WebUI,也可以與Grafana整合。
以上,就是我對微服務架構中「 監控系統」的一些思考。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69940568/viewspace-2657462/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 基於Prometheus的資料庫監控Prometheus資料庫
- 開源資料庫流行度首次超過非開源資料庫Confluent資料庫
- 如何使用 taosKeeper 做好監控工作,時序資料庫 TDengine 3.0 監控工具詳解資料庫
- 時序資料庫的叢集方案?資料庫
- 新一代開源時序資料庫TDengine有哪些優勢?資料庫
- 「經驗彙總」基於TDengine的時序資料解決方案
- 百度大規模時序資料儲存(一)| 監控場景的時序資料
- 2 Day DBA-管理方案物件-監控和優化資料庫-積極的資料庫監控物件優化資料庫
- 做了兩款資料庫監控工具,打算在近期開源資料庫
- 5個基於JAVA的開源NoSQL資料庫JavaSQL資料庫
- 資料庫監控資料庫
- 超牛逼的一款開源即時效能監控系統!
- 監控長時間執行的查詢(監控資料庫效能的SQL ) -- 轉資料庫SQL
- 監控資料庫執行超過6s的操作資料庫
- 時序資料庫分析-TimescaleDB時序資料庫介紹資料庫
- 實時資料庫與時序資料庫資料庫
- 多臺ORACLE資料庫表空間監控方案Oracle資料庫
- 資料庫效能監控資料庫
- 前沿分享|上海市新能源汽車資料平臺 王成名: 車聯網全景監控資料時空超融合資料庫方案資料庫
- 時序資料庫TDengine的叢集使用經驗分享,附上開源版本資料庫
- 監控資料庫效能的SQL資料庫SQL
- zabbix開源監控解決方案-本地化
- MySQL監控-Datadog資料庫監控調研MySql資料庫
- 資料庫繁忙程度監控資料庫
- 資料庫監控軟體資料庫
- SQL Server資料庫監控SQLServer資料庫
- 資料庫監控指令碼資料庫指令碼
- 監控Oracle資料庫方法Oracle資料庫
- 監控資料庫指令碼資料庫指令碼
- zabbix監控oracle資料庫Oracle資料庫
- 資料庫開發(19)基於物件的資料庫資料庫物件
- 5個用於移動開發的最流行資料庫移動開發資料庫
- 這裡人氣不高啊,j2me上有開源的資料庫嗎?資料庫
- Netflix開源三款用於安全監控的開源工具開源工具
- Netflix開源Mantis:基於微服務的運維監控平臺微服務運維
- 網際網路級監控系統必備-時序資料庫之Influxdb技術資料庫UX
- Oracle資料庫的監控內容Oracle資料庫
- 基於OkHttp的Http監控HTTP