基於Prometheus的資料庫監控

傳統監控系統面臨的問題

傳統監控系統，會面臨哪些問題？
以zabbix為例

初次使用需要配置大量管理功能，隨著伺服器和業務的增長會發現zabbix，這種傳統監控面臨很多問題

1. DB效能瓶頸，由於zabbix會將採集到的效能指標都儲存到資料庫中，當伺服器數量和業務增長很快時資料庫效能首先成為瓶頸。

2. 多套部署，管理成本高，當資料庫效能成為瓶頸時首先想到的辦法可能時分多套zabbix部署，但是又會帶來管理很維護成本很高的問題。

3. 易用性差，zabbix的配置和管理非常複雜，很難精通。
4. 郵件風暴，郵件配置各種規則相當複雜，一不小心可能就容易造成郵件風暴的問題。

隨著容器技術的發展，傳統監控系統面臨更多問題

1. 容器如何監控?
2. 微服務如何監控?
3. 叢集效能如何進行分析計算?
4. 如何管理agent端大量配置指令碼?

我們可以看到傳統監控系統無法滿足，當前IT環境下的監控需求

Prometheus的前身：Borgmon

2015年Google發表了一篇論文《Google使用Borg進行大規模叢集的管理》

這篇論文也描述了Google叢集的規模和麵臨的挑戰

1. 單叢集上萬伺服器
2. 幾千個不同的應用
3. 幾十萬個以上的jobs，而且動態增加或者減少
4. 每個資料中心數百個叢集

基於這樣一個規模，Google的監控系統也面臨巨大挑戰，而Borg中的Borgmon監控系統就是為了應對這些挑戰而生。

Borgmon介紹

那麼我們來看一下Google如何做大規模叢集的監控系統

應用埋點

首先，Borg叢集中執行的所有應用都需要暴露出特定的URL，http://<app>:80/varz 通過這個URL我們就可以獲取到應用所暴露的全部監控指標。

服務發現

然而這樣的應用有數千萬個，而且可能會動態增加或者減少，Borgmon中如何發現這些應用呢？Borg中的應用啟動時會自動註冊到Borg內部的域名伺服器BNS中，Borgmon通過讀取BNS中應用列表資訊，收集到應用列表，從而發現有哪些應用服務需要監控。當獲取到應用列表後，就會將應用的全部監控變數值拉取到Borgmon系統中。

指標採集與堆疊

當監控指標收集到Borgmon中，就可以進行展現或者提供給告警使用，另外由於一個叢集實在是太過龐大了，一個Borgmon可能無法滿足整個叢集的監控採集和展現需求，所以一般會在一些複雜的環境下，一個資料中心可能部署多個Borgmon，分為資料收集層和彙總層，資料收集層會有多個Borgmon專門用來到應用中收集資料，彙總層Borgmon則從資料收集層Borgmon中獲取資料。

指標資料儲存

Borgmon收集到了效能指標資料後，會把所有的資料儲存在記憶體資料庫裡，定時checkpoint到磁碟上，並且會週期性的打包到外部的系統TSDB。通常情況下，資料中心和全域性Borgmon中一般至少會存放12小時左右的資料量，以便渲染圖表使用。每個資料點大概佔用24位元組的記憶體，所以存放100萬個time-series，每個time-series每分鐘一個資料點，同時儲存12小時資料，僅需17GB記憶體。

指標

指標的查詢

Borgmon中通過標籤的方式查詢指標，基於標籤過濾我們可以查詢到某個應用的具體指標，也可以查詢更高維度的資訊
基於標籤過濾資訊，比如我們基於一組過濾資訊查詢到host0:80這個app的http_requests

我們也可以查詢到整個美國西部，job為webserver的http_requests

那麼這個時候拿到的就是所有符合條件的例項的列表

規則計算

在資料收集和儲存的基礎之上，我們可以通過規則計算得到進一步的資料。
比如，我們想在web server報錯超過一定比例的時候報警，或者說在非200返回碼，佔總請求的比例超過某個值的時候報警。

Prometheus

介紹

Borgmon是Google內部的系統，那麼在Google之外如何使用它呢？這裡就提到我們所描述的Prometheus這套監控系統。Google內部SRE工程師的著作《Google SRE》這本書中，直接就提到了Prometheus相當於就是開源版本的Borgmon。目前Prometheus在開源社群也是相當火爆，由Google發起Linux基金會旗下的原生雲基金會（CNCF）就將Prometheus納入其下第二大開源專案（第一專案為Kubernetes，為Borg的開源版本）。

架構

Prometheus整體架構和Borgmon類似，元件如下，有些元件是可選的：

• Prometheus主伺服器，用來收集和儲存時間序列資料
• 應用程式client程式碼庫
• 短時jobs的push gateway
• 特殊用途的exporter（包括HAProxy、StatsD、Ganglia等）
• 用於報警的alertmanager
• 命令列工具查詢
• 另外Grafana是作為Prometheus Dashboard展現的絕佳工具

資料庫監控

基於Prometheus的資料庫指標採集，我們以MySQL為例，由於MySQL沒有暴露採集效能指標的介面，我們可以單獨啟動一個mysql_exporter，通過mysql_exporter到MySQL資料庫上抓去效能指標，並暴露出效能採集介面提供給Prometheus，另外我們可以啟動node_exporter用於抓取主機的效能指標。

部署服務端

對於服務端配置非常簡單，由於Prometheus全部基於Go語言開發，而Go語言程式在安裝方面非常方便，安裝服務端程式只需要下載，解壓並執行即可。可以看到服務端常用程式也比較少，只需要包含prometheus這個主服務程式和alertmanager這個告警系統程式。

服務端配置也非常簡單，常用配置包含拉取時間和具體採集方式，就我們監控mysql資料庫來講，只需要填入mysql_exporter地址即可。

部署exporter端

對於mysql採集只需要配置連線資訊，並啟動mysql_exporter即可

完成配置之後即可通過mysql_exporter採集mysql效能指標

然後我們在prometheus服務端也可以查詢到採集的mysql效能指標


基於這些採集指標和Prometheus提供的規則計算語句，我們可以實現一些高緯度的查詢需求，比如，increase(mysql_global_status_bytes_received{instance="$host"}[1h])
我們可以查詢MySQL每小時接受到的位元組數，然後我們將這個查詢放到Grafana中，就可以展現非常酷炫的效能圖表。

而目前結合Prometheus和Grafana的MySQL監控方案已經有開源實現，我們很輕鬆可以搭建一套基於Prometheus的監控系統

對於告警方面我們也可以基於Prometheus豐富的查詢語句實現複雜告警邏輯
比如我們要對MySQL備庫進行監控，如果複製IO執行緒未執行或者複製SQL執行緒未執行並且持續2分鐘就傳送告警我們可以使用如下這條告警規則。

	
	

		# Alert: The replication IO or SQL threads are stopped.
	

	

		ALERT MySQLReplicationNotRunning
	

	

		 IF mysql_slave_status_slave_io_running == 0 OR mysql_slave_status_slave_sql_running == 0
	

	

		 FOR 2m
	

	

		 LABELS {
	

	

		 severity = "critical"
	

	

		 }
	

	

		 ANNOTATIONS {
	

	

		 summary = "Slave replication is not running",
	

	

		 description = "Slave replication (IO or SQL) has been down for more than 2 minutes.",
	

	

		 }
	

在比如，我們要監控MySQL備庫延遲大於30秒並且預測在未來2分鐘之後大於0秒持續1分鐘，則告警

	
	

		# Alert: The replicaiton lag is non-zero and it predicted to not recover within
	

	

		#        2 minutes.  This allows for a small amount of replication lag.
	

	

		ALERT MySQLReplicationLag
	

	

		 IF
	

	

		 (mysql_slave_lag_seconds > 30)
	

	

		 AND on (instance)
	

	

		 (predict_linear(mysql_slave_lag_seconds[5m], 60*2) > 0)
	

	

		 FOR 1m
	

	

		 LABELS {
	

	

		 severity = "critical"
	

	

		 }
	

	

		 ANNOTATIONS {
	

	

		 summary = "MySQL slave replication is lagging",
	

	

		 description = "The mysql slave replication has fallen behind and is not recovering",
	

	

		 }
	

當然在資料庫方面不只是有MySQL的監控實現，目前業界也有很多其他開源實現，所以在資料庫監控方面也能實現開箱即用的效果

• mysql_exporter https://github.com/prometheus/mysqld_exporter

• redis_exporter https://github.com/oliver006/redis_exporter

• postgres_exporter https://github.com/wrouesnel/postgres_exporter

• mongodb_exporter https://github.com/percona/mongodb_exporter

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28218939/viewspace-2137745/，如需轉載，請註明出處，否則將追究法律責任。