如何進(jìn)行Prometheus的數(shù)據(jù)庫(kù)監(jiān)控，相信很多沒有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問題。

10年積累的成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)、外貿(mào)營(yíng)銷網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有邱縣免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

基于Prometheus的數(shù)據(jù)庫(kù)監(jiān)控

傳統(tǒng)監(jiān)控系統(tǒng)面臨的問題

傳統(tǒng)監(jiān)控系統(tǒng)，會(huì)面臨哪些問題？
以zabbix為例

初次使用需要配置大量管理功能，隨著服務(wù)器和業(yè)務(wù)的增長(zhǎng)會(huì)發(fā)現(xiàn)zabbix，這種傳統(tǒng)監(jiān)控面臨很多問題

1. DB性能瓶頸，由于zabbix會(huì)將采集到的性能指標(biāo)都存儲(chǔ)到數(shù)據(jù)庫(kù)中，當(dāng)服務(wù)器數(shù)量和業(yè)務(wù)增長(zhǎng)很快時(shí)數(shù)據(jù)庫(kù)性能首先成為瓶頸。

2. 多套部署，管理成本高，當(dāng)數(shù)據(jù)庫(kù)性能成為瓶頸時(shí)首先想到的辦法可能時(shí)分多套zabbix部署，但是又會(huì)帶來(lái)管理很維護(hù)成本很高的問題。

3. 易用性差，zabbix的配置和管理非常復(fù)雜，很難精通。

4. 郵件風(fēng)暴，郵件配置各種規(guī)則相當(dāng)復(fù)雜，一不小心可能就容易造成郵件風(fēng)暴的問題。

隨著容器技術(shù)的發(fā)展，傳統(tǒng)監(jiān)控系統(tǒng)面臨更多問題

1. 容器如何監(jiān)控?

2. 微服務(wù)如何監(jiān)控?

3. 集群性能如何進(jìn)行分析計(jì)算?

4. 如何管理agent端大量配置腳本?

我們可以看到傳統(tǒng)監(jiān)控系統(tǒng)無(wú)法滿足，當(dāng)前IT環(huán)境下的監(jiān)控需求

Prometheus的前身：Borgmon

2015年Google發(fā)表了一篇論文《Google使用Borg進(jìn)行大規(guī)模集群的管理》

這篇論文也描述了Google集群的規(guī)模和面臨的挑戰(zhàn)

1. 單集群上萬(wàn)服務(wù)器

2. 幾千個(gè)不同的應(yīng)用

3. 幾十萬(wàn)個(gè)以上的jobs，而且動(dòng)態(tài)增加或者減少

4. 每個(gè)數(shù)據(jù)中心數(shù)百個(gè)集群

基于這樣一個(gè)規(guī)模，Google的監(jiān)控系統(tǒng)也面臨巨大挑戰(zhàn)，而Borg中的Borgmon監(jiān)控系統(tǒng)就是為了應(yīng)對(duì)這些挑戰(zhàn)而生。

Borgmon介紹

那么我們來(lái)看一下Google如何做大規(guī)模集群的監(jiān)控系統(tǒng)

應(yīng)用埋點(diǎn)

首先，Borg集群中運(yùn)行的所有應(yīng)用都需要暴露出特定的URL，http://<app>:80/varz 通過(guò)這個(gè)URL我們就可以獲取到應(yīng)用所暴露的全部監(jiān)控指標(biāo)。

服務(wù)發(fā)現(xiàn)

然而這樣的應(yīng)用有數(shù)千萬(wàn)個(gè)，而且可能會(huì)動(dòng)態(tài)增加或者減少，Borgmon中如何發(fā)現(xiàn)這些應(yīng)用呢？Borg中的應(yīng)用啟動(dòng)時(shí)會(huì)自動(dòng)注冊(cè)到Borg內(nèi)部的域名服務(wù)器BNS中，Borgmon通過(guò)讀取BNS中應(yīng)用列表信息，收集到應(yīng)用列表，從而發(fā)現(xiàn)有哪些應(yīng)用服務(wù)需要監(jiān)控。當(dāng)獲取到應(yīng)用列表后，就會(huì)將應(yīng)用的全部監(jiān)控變量值拉取到Borgmon系統(tǒng)中。

指標(biāo)采集與堆疊

當(dāng)監(jiān)控指標(biāo)收集到Borgmon中，就可以進(jìn)行展現(xiàn)或者提供給告警使用，另外由于一個(gè)集群實(shí)在是太過(guò)龐大了，一個(gè)Borgmon可能無(wú)法滿足整個(gè)集群的監(jiān)控采集和展現(xiàn)需求，所以一般會(huì)在一些復(fù)雜的環(huán)境下，一個(gè)數(shù)據(jù)中心可能部署多個(gè)Borgmon，分為數(shù)據(jù)收集層和匯總層，數(shù)據(jù)收集層會(huì)有多個(gè)Borgmon專門用來(lái)到應(yīng)用中收集數(shù)據(jù)，匯總層Borgmon則從數(shù)據(jù)收集層Borgmon中獲取數(shù)據(jù)。

指標(biāo)數(shù)據(jù)存儲(chǔ)

Borgmon收集到了性能指標(biāo)數(shù)據(jù)后，會(huì)把所有的數(shù)據(jù)存儲(chǔ)在內(nèi)存數(shù)據(jù)庫(kù)里，定時(shí)checkpoint到磁盤上，并且會(huì)周期性的打包到外部的系統(tǒng)TSDB。通常情況下，數(shù)據(jù)中心和全局Borgmon中一般至少會(huì)存放12小時(shí)左右的數(shù)據(jù)量，以便渲染圖表使用。每個(gè)數(shù)據(jù)點(diǎn)大概占用24字節(jié)的內(nèi)存，所以存放100萬(wàn)個(gè)time-series，每個(gè)time-series每分鐘一個(gè)數(shù)據(jù)點(diǎn)，同時(shí)保存12小時(shí)數(shù)據(jù)，僅需17GB內(nèi)存。

指標(biāo)

指標(biāo)的查詢

Borgmon中通過(guò)標(biāo)簽的方式查詢指標(biāo)，基于標(biāo)簽過(guò)濾我們可以查詢到某個(gè)應(yīng)用的具體指標(biāo)，也可以查詢更高維度的信息
基于標(biāo)簽過(guò)濾信息，比如我們基于一組過(guò)濾信息查詢到host0:80這個(gè)app的http_requests

我們也可以查詢到整個(gè)美國(guó)西部，job為webserver的http_requests

那么這個(gè)時(shí)候拿到的就是所有符合條件的實(shí)例的列表

規(guī)則計(jì)算

在數(shù)據(jù)收集和存儲(chǔ)的基礎(chǔ)之上，我們可以通過(guò)規(guī)則計(jì)算得到進(jìn)一步的數(shù)據(jù)。
比如，我們想在web server報(bào)錯(cuò)超過(guò)一定比例的時(shí)候報(bào)警，或者說(shuō)在非200返回碼，占總請(qǐng)求的比例超過(guò)某個(gè)值的時(shí)候報(bào)警。

Prometheus

介紹

Borgmon是Google內(nèi)部的系統(tǒng)，那么在Google之外如何使用它呢？這里就提到我們所描述的Prometheus這套監(jiān)控系統(tǒng)。Google內(nèi)部SRE工程師的著作《Google SRE》這本書中，直接就提到了Prometheus相當(dāng)于就是開源版本的Borgmon。目前Prometheus在開源社區(qū)也是相當(dāng)火爆，由Google發(fā)起Linux基金會(huì)旗下的原生云基金會(huì)（CNCF）就將Prometheus納入其下第二大開源項(xiàng)目（第一項(xiàng)目為Kubernetes，為Borg的開源版本）。

架構(gòu)

Prometheus整體架構(gòu)和Borgmon類似，組件如下，有些組件是可選的：

• Prometheus主服務(wù)器，用來(lái)收集和存儲(chǔ)時(shí)間序列數(shù)據(jù)

• 應(yīng)用程序client代碼庫(kù)

• 短時(shí)jobs的push gateway

• 特殊用途的exporter（包括HAProxy、StatsD、Ganglia等）

• 用于報(bào)警的alertmanager

• 命令行工具查詢

• 另外Grafana是作為Prometheus Dashboard展現(xiàn)的絕佳工具

數(shù)據(jù)庫(kù)監(jiān)控

基于Prometheus的數(shù)據(jù)庫(kù)指標(biāo)采集，我們以MySQL為例，由于MySQL沒有暴露采集性能指標(biāo)的接口，我們可以單獨(dú)啟動(dòng)一個(gè)mysql_exporter，通過(guò)mysql_exporter到MySQL數(shù)據(jù)庫(kù)上抓去性能指標(biāo)，并暴露出性能采集接口提供給Prometheus，另外我們可以啟動(dòng)node_exporter用于抓取主機(jī)的性能指標(biāo)。

部署服務(wù)端

對(duì)于服務(wù)端配置非常簡(jiǎn)單，由于Prometheus全部基于Go語(yǔ)言開發(fā)，而Go語(yǔ)言程序在安裝方面非常方便，安裝服務(wù)端程序只需要下載，解壓并運(yùn)行即可?？梢钥吹椒?wù)端常用程序也比較少，只需要包含prometheus這個(gè)主服務(wù)程序和alertmanager這個(gè)告警系統(tǒng)程序。

服務(wù)端配置也非常簡(jiǎn)單，常用配置包含拉取時(shí)間和具體采集方式，就我們監(jiān)控mysql數(shù)據(jù)庫(kù)來(lái)講，只需要填入mysql_exporter地址即可。

部署exporter端

對(duì)于mysql采集只需要配置連接信息，并啟動(dòng)mysql_exporter即可

完成配置之后即可通過(guò)mysql_exporter采集mysql性能指標(biāo)

然后我們?cè)趐rometheus服務(wù)端也可以查詢到采集的mysql性能指標(biāo)


基于這些采集指標(biāo)和Prometheus提供的規(guī)則計(jì)算語(yǔ)句，我們可以實(shí)現(xiàn)一些高緯度的查詢需求，比如，increase(mysql_global_status_bytes_received{instance="$host"}[1h])
我們可以查詢MySQL每小時(shí)接受到的字節(jié)數(shù)，然后我們將這個(gè)查詢放到Grafana中，就可以展現(xiàn)非?？犰诺男阅軋D表。

而目前結(jié)合Prometheus和Grafana的MySQL監(jiān)控方案已經(jīng)有開源實(shí)現(xiàn)，我們很輕松可以搭建一套基于Prometheus的監(jiān)控系統(tǒng)

對(duì)于告警方面我們也可以基于Prometheus豐富的查詢語(yǔ)句實(shí)現(xiàn)復(fù)雜告警邏輯
比如我們要對(duì)MySQL備庫(kù)進(jìn)行監(jiān)控，如果復(fù)制IO線程未運(yùn)行或者復(fù)制SQL線程未運(yùn)行并且持續(xù)2分鐘就發(fā)送告警我們可以使用如下這條告警規(guī)則。

		# 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.", }

在比如，我們要監(jiān)控MySQL備庫(kù)延遲大于30秒并且預(yù)測(cè)在未來(lái)2分鐘之后大于0秒持續(xù)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", }

當(dāng)然在數(shù)據(jù)庫(kù)方面不只是有MySQL的監(jiān)控實(shí)現(xiàn)，目前業(yè)界也有很多其他開源實(shí)現(xiàn)，所以在數(shù)據(jù)庫(kù)監(jiān)控方面也能實(shí)現(xiàn)開箱即用的效果

看完上述內(nèi)容，你們掌握如何進(jìn)行Prometheus的數(shù)據(jù)庫(kù)監(jiān)控的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

本文標(biāo)題：如何進(jìn)行Prometheus的數(shù)據(jù)庫(kù)監(jiān)控
瀏覽地址：http://aaarwkj.com/article38/pccepp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、做網(wǎng)站、、網(wǎng)站設(shè)計(jì)公司、網(wǎng)站內(nèi)鏈、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)