“

閱讀本文大概需要 10?分鐘。

”

最近我在公司負(fù)責(zé)的業(yè)務(wù)已經(jīng)正式投入上線了，既然是線上環(huán)境，那么就需要保證其可用性。

我負(fù)責(zé)的業(yè)務(wù)其中就包括一個(gè) Web Service，我需要保證 Service 的每個(gè)接口都是可用的，如果某個(gè)時(shí)間流量大了或者服務(wù)器掛掉了，那需要第一時(shí)間通知到我。

這時(shí)候可能我有這些需求：

1.定時(shí)測(cè)試和監(jiān)控服務(wù)器每個(gè)接口是否是可用的，包括返回的數(shù)據(jù)、狀態(tài)碼是不是正確的。2.我可以隨時(shí)查看到每個(gè)接口的響應(yīng)時(shí)間、可用率等信息，最好是有可視化的圖表呈現(xiàn)，一目了然。3.如果接口的錯(cuò)誤率超過某一閾值一段時(shí)間，及時(shí)通知我，包括電話、短信或郵件。4.需要主動(dòng)去監(jiān)測(cè)接口的可用性，注意這里是主動(dòng)監(jiān)測(cè)而不是被動(dòng)監(jiān)測(cè)，不是等用戶用的時(shí)候報(bào)錯(cuò)才提醒我。比如在沒有用戶用的時(shí)候，我也能及時(shí)知道每個(gè)接口的可用性。

其實(shí)，國(guó)內(nèi)的一些服務(wù)商已經(jīng)提供了這些功能，即主動(dòng)型服務(wù)監(jiān)控，比如「監(jiān)控寶」，但我并不想用這些服務(wù)，一是需要額外花錢，二是數(shù)據(jù)上并不安全，三是我需要把我的服務(wù)集成到公司內(nèi)部的監(jiān)控體系下。

有了這些需求，我就結(jié)合公司內(nèi)部現(xiàn)有的一些基礎(chǔ)設(shè)施先確定一個(gè)技術(shù)選型，然后實(shí)施就好了。

目前公司內(nèi)部使用的一套監(jiān)控體系是基于 Kubernetes + Prometheus + Grafana + Alert Manager 的，那么基于我的需求來分析下我怎樣利用這一套體系來搭建我想要的監(jiān)控設(shè)施。

解決方案分析：

1.首先關(guān)于第四個(gè)需求比較特殊，現(xiàn)有的監(jiān)控體系其實(shí)已經(jīng)可以做到服務(wù)的被動(dòng)監(jiān)測(cè)，比如某個(gè) Service 的 API 被調(diào)用了，那么相應(yīng)的調(diào)用數(shù)據(jù)都會(huì)被匯總到 Prometheus 上面，Prometheus 里面會(huì)計(jì)算接口調(diào)用的可用率，如果一段時(shí)間內(nèi)如果錯(cuò)誤率超過一定閾值，那就報(bào)警，追錯(cuò)誤的時(shí)候去查下 log 就好了。但其實(shí)這個(gè)不能做到主動(dòng)監(jiān)測(cè)，比如在凌晨三四點(diǎn)，當(dāng)沒有用戶使用的時(shí)候，如果這時(shí)候服務(wù)器出現(xiàn)問題了，我也需要第一時(shí)間能知道，所以我需要有一個(gè)定時(shí)的主動(dòng)監(jiān)測(cè)程序來實(shí)時(shí)監(jiān)測(cè)我的所有接口是否是可用的。要做到主動(dòng)監(jiān)控，那我一定需要一個(gè)接口監(jiān)測(cè)程序定時(shí)運(yùn)行并校驗(yàn)每個(gè)接口的結(jié)果，這里我選用的就是開源的 JMeter，它大多數(shù)情況下是被用來做壓測(cè)的，但絕對(duì)能滿足接口調(diào)用和檢測(cè)的需求，只要我定時(shí)跑 JMeter 來檢測(cè)就好了。2.關(guān)于第一個(gè)需求，我需要監(jiān)測(cè)我的每個(gè)接口都是可用的，包括返回的數(shù)據(jù)也需要是想要的結(jié)果。這時(shí)候我們可能想到直接跑一些 test case 之類的，但這些其實(shí)大多數(shù)都是在部署或運(yùn)行時(shí)校驗(yàn)的，如果我要實(shí)時(shí)跑或者 test case 有 update 了，也不太方便。另外為了寫接口測(cè)試的時(shí)候，如果沒有現(xiàn)成的工具，我們可能得寫一堆代碼，每個(gè)接口都寫一個(gè)，包括 GET 請(qǐng)求的 URL 參數(shù)、POST 請(qǐng)求的 Body 信息等等，然后校驗(yàn)接口的返回結(jié)果是不是對(duì)的，也太麻煩了。所以我們需要找到一個(gè)可用的工具來幫助我們快速地完成這些功能。所以，我選擇的 JMeter 也提供了可視化界面，我只需要配置一些接口和參數(shù)即可，另外它還帶有定時(shí)器、斷言、動(dòng)態(tài)參數(shù)、多線程等功能，這樣我們也可以做到并發(fā)測(cè)試、隨機(jī)等待、動(dòng)態(tài)構(gòu)造請(qǐng)求參數(shù)、返回結(jié)果判斷等功能了。3.其次再說第二個(gè)和第三個(gè)需求，其實(shí)用現(xiàn)有的 Prometheus + Grafana 就能解決了，這里最關(guān)鍵的則是我的接口監(jiān)控結(jié)果能發(fā)給 Prometheus 才行。既然我選用了 JMeter，那么我怎樣把 JMeter 的數(shù)據(jù)發(fā)送給 Prometheus 呢？這里需要借助于 JMeter 的一個(gè)插件 jmeter-prometheus-plugin，https://github.com/johrstrom/jmeter-prometheus-plugin，利用它就能將 JMeter 變成一個(gè) Data Exporter，Prometheus 來抓取就好了。

所以，綜上所述，我利用的一套服務(wù)監(jiān)控體系就是 JMeter + Kubernetes + Prometheus + Grafana + Alert Manager，那么就開干吧。

這里先放一張圖，看下最終的監(jiān)控 Grafana 面板吧：

監(jiān)控面板

這里一些接口的名稱和 URL 我就打碼了，這里我可以在 Grafana 中每時(shí)每刻都看到每個(gè)接口的可用率、響應(yīng)（包括平均、最快、最慢）時(shí)間、狀態(tài)碼等信息，這些信息就是 JMeter 定時(shí)檢測(cè)得到的結(jié)果，監(jiān)控?cái)?shù)據(jù)轉(zhuǎn)到 Prometheus 里面然后經(jīng)過 Grafana 可視化出來，并能通過一些指標(biāo)來實(shí)現(xiàn)報(bào)警機(jī)制。

感興趣的話，可以繼續(xù)往下看哈。

為了達(dá)成這些功能，我需要解決如下問題：

?如何使用 JMeter 來測(cè)試每個(gè)接口的使用情況。?JMeter 如何和 Prometheus 對(duì)接起來，即如何集成 jmeter-prometheus-plugin 到 JMeter。?JMeter 怎樣去部署，部署到哪里。?可視化數(shù)據(jù)怎樣來呈現(xiàn)。?錯(cuò)誤狀態(tài)怎樣來快速查看。?出錯(cuò)通知如何實(shí)現(xiàn)，比如打電話、發(fā)郵件等等。

下面我們就來一個(gè)個(gè)總結(jié)說一下。

由于內(nèi)容比較多，整個(gè)流程我實(shí)踐下來然后測(cè)試通總共花了兩天左右的時(shí)間，在這里就不完全展開說了，只提關(guān)鍵點(diǎn)了。

JMeter 測(cè)試

第一步那就是用 JMeter 來完成接口的測(cè)試了，接口的調(diào)用形式肯定都有相應(yīng)的規(guī)范的，比如 GET 請(qǐng)求設(shè)置啥參數(shù)，POST 請(qǐng)求發(fā)送什么數(shù)據(jù)，我們利用 JMeter 都能方便地配置。

JMeter 是有 GUI 的，我們?cè)诰帉懙臅r(shí)候在 GUI 里面設(shè)置就好了，界面樣例如下所示：

JMeter界面（圖源：https://www.jianshu.com/p/0349441da3c4）

這里提示幾點(diǎn)可能用到的東西：

?動(dòng)態(tài)參數(shù)，JMeter 里面是支持動(dòng)態(tài)參數(shù)設(shè)置的，比如循環(huán)測(cè)試 id 從 1 到 100，或者動(dòng)態(tài) POST 的數(shù)據(jù)替換，都是可以做到的，這個(gè)可以滿足你花樣測(cè)試接口的需求。?定時(shí)器，JMeter 里面有很多 Timer，可以設(shè)置各種各樣的延時(shí)操作，比如每 3 分鐘測(cè)一次，隨機(jī)等待多少秒測(cè)一次都行。?斷言，測(cè)試了接口之后，我們不僅要知道是否是可用的，同時(shí)也要判斷其結(jié)果是不是正確的，如果返回狀態(tài)碼是正確的但是結(jié)果不對(duì)，那也白搭，所以可以使用斷言來檢查返回結(jié)果。

關(guān)于 JMeter 的功能這里就不再展開講了，反正幾乎你想實(shí)現(xiàn)的任何測(cè)試功能都可以實(shí)現(xiàn)，具體的用法可以參考 JMeter 的官方文檔：https://jmeter.apache.org/usermanual/get-started.html。

嗯，寫好了之后，可以用 JMeter 在本地進(jìn)行測(cè)試，測(cè)試好了時(shí)候，可以把 JMeter 的這個(gè) Test Plan 存成一個(gè) jmx 文件，留作后面?zhèn)溆谩?/p>

對(duì)接 Prometheus

接下來就是如何把數(shù)據(jù)對(duì)接到 Prometheus 里面了。

默認(rèn)情況下，JMeter 是能導(dǎo)出數(shù)據(jù)到諸如 InfluxDB 這樣的數(shù)據(jù)庫的，借助于它自帶的 Listener 即可實(shí)現(xiàn)。它并不帶導(dǎo)出到 Prometheus 的功能。

這里我們就需要借助于 jmeter-prometheus-plugin 這個(gè)插件了，其 GitHub 地址是 https://github.com/johrstrom/jmeter-prometheus-plugin，具體的用法可以參考其官方說明。

這里提示幾點(diǎn)：

?jmeter-prometheus-plugin 安裝的時(shí)候把 jar 文件放到 JMeter 目錄下就好了，jar 文件可以直接看這里下載：https://github.com/johrstrom/jmeter-prometheus-plugin#programatically。?安裝好這個(gè)插件之后，需要增加一個(gè) Listener，然后配置各種導(dǎo)出字段和參數(shù)，可以參考這個(gè) jmx 文件的配置：https://github.com/johrstrom/jmeter-prometheus-plugin/blob/master/docs/examples/simple_prometheus_example.jmx，可以把這個(gè) jmx 打開，然后把 Listener 拷貝到你的 Test Plan 即可。?jmeter-prometheus-plugin 這個(gè)插件會(huì)把 JMeter 變成一個(gè) Data Exporter，而不是通過 Prometheus Push Gateway 來主動(dòng)推送監(jiān)控信息，所以它會(huì)在本地啟動(dòng)一個(gè)端口，默認(rèn)是 9270。

Listener 的配置示例如圖所示：

JMeter Listener

這里字段名如 jsr223_rt_as_summary 可以自行修改，比如這里我就統(tǒng)一修改為了 jmeter_test_xxx 這樣的字段。

配置完成之后，運(yùn)行 JMeter 之后，我們就能在 http://localhost:9270 上看到 Exporter 的信息，如圖所示：

Exporter

這里面就包含了 JMeter 的一些接口測(cè)試結(jié)果，包括成功次數(shù)、失敗次數(shù)、狀態(tài)碼等等，另外還有 JVM、處理器等各種環(huán)境信息。

部署之后把對(duì)應(yīng)的 URL 交由 Prometheus 就可以把監(jiān)控?cái)?shù)據(jù)收集到 Prometheus 里面了。

部署 JMeter

完成上述兩步，我們就能成功測(cè)試 Service 的每個(gè)接口并能生成測(cè)試結(jié)果的 Exporter 了。

那么 JMeter 寫好了，怎么來部署呢？可以用 crontab，放某臺(tái)服務(wù)器上，不過這里最理想的方式當(dāng)然是部署到 Kubernetes 里面了。

這里就需要把 JMeter 打包成一個(gè)鏡像了，GitHub 找來找去沒找到幾個(gè)合適的，另外也沒有把 jmeter-prometheus-plugin 包括進(jìn)去，那只有自己來了。

我基于 https://github.com/justb4/docker-jmeter 進(jìn)行了二次改寫，最后打包了一個(gè)鏡像，已經(jīng)開源了，地址為：https://github.com/Germey/JMeterMonitor，鏡像名稱為 germey/jmeter，這里就不再展開講細(xì)節(jié)了，有點(diǎn)復(fù)雜。

運(yùn)行所需要的 docker-compose 文件如下：

version: '3' services:jmeter:restart: alwaysimage: 'germey/jmeter'volumes:- ./jmx:/appcommand:- sample.jmxports:- "80:80"

這里我把本地的 jmx 文件夾 mount 到了 Docker 的 app 文件夾，所以這里在運(yùn)行時(shí)需要在項(xiàng)目文件夾下新建 jmx 文件夾，用于存放 jmx 文件，把剛才寫好的 jmx 文件放過來就好了。

另外 command 就是 jmx 文件的名稱，這里需要修改成你的 jmx 文件。

另外部署到 Kubernetes 的話可以參考這里的 yml 文件：https://github.com/Germey/JMeterMonitor/tree/master/kubernetes。

Prometheus 收集數(shù)據(jù)

在成功部署 JMeter 之后呢，它肯定會(huì)提供一個(gè) Web Service 來暴露 JMeter 的測(cè)試數(shù)據(jù)。

如果部署好了 Prometheus 之后，可以把它放在 Prometheus 的 scrape_configs，比如 Service 的 URL 為 jmeter-monitor.com，可以修改 prometheus.yml：

global:scrape_interval: 15s # By default, scrape targets every 15 seconds.# Attach these labels to any time series or alerts when communicating with# external systems (federation, remote storage, Alertmanager).external_labels:monitor: 'codelab-monitor'# A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs:# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.- job_name: 'jmeter-monitor'# Override the global default and scrape targets from this job every 5 seconds.scrape_interval: 5sstatic_configs:- targets: ['jmeter-monitor.com']

其具體的配置字段可以參見：https://prometheus.io/docs/prometheus/latest/configuration/configuration/。

另外呢，這種方式其實(shí)并不怎么好，修改 Prometheus 挺麻煩的，推薦使用 Helm + Prometheus-Operator 來安裝 Prometheus，然后修改 values.yml 即可修改配置文件了，比如修改 https://github.com/helm/charts/blob/master/stable/prometheus-operator/values.yaml 里面的 additionalScrapeConfigs 即可。

Grafana 可視化

Prometheus 收集完數(shù)據(jù)之后，我們可以將其可視化出來了。

比如這里有些字段，jmeter_test_can_fail_success 代表成功請(qǐng)求的次數(shù)，jmeter_test_can_fail_total 代表總的測(cè)試次數(shù)。

那么就可以用一個(gè)表達(dá)式來計(jì)算 Error Rate 了：

1- jmeter_test_can_fail_success{instance="$instance"} / jmeter_test_can_fail_total{instance="$instance"}

效果如下：

配置面板

這里就能實(shí)時(shí)可視化展示出來錯(cuò)誤率了，更多的一些配置可以自行修改這些表達(dá)式進(jìn)行定制。

最后我配置成的一些監(jiān)控面板如下所示：

監(jiān)控面板

這樣我要是什么時(shí)候想看 Service 接口的情況，隨時(shí)上來看就好了。

報(bào)警

對(duì)于報(bào)警來說，可以使用兩種方式配置，一個(gè)是直接使用 Grafana 自帶的報(bào)警機(jī)制，另外是可以通過 Alert Manager，后者功能更加強(qiáng)大，推薦使用后者。

對(duì)于 Alert Manager 來說，其監(jiān)控的規(guī)則這里推薦使用 Prometheus-Operator 里面自帶的 PrometheusRule 來實(shí)現(xiàn)，比如可以定義這么一個(gè) PrometheusRule：

apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata:labels:app: monitorname: monitor-rules spec:groups:- name: monitorrules:- alert: ServiceErroringlabels:severity: warningannotations:message: Service 連續(xù)5分鐘錯(cuò)誤率過高。expr: |avg(1- jmeter_test_can_fail_success{job="service-monitor"} / jmeter_test_can_fail_total{job="service-monitor"}) > 0for: 5m

這樣配置好一個(gè) PrometheusRule 之后，Prometheus 會(huì)自動(dòng)應(yīng)用這個(gè) Rule 然后監(jiān)控。

報(bào)警方式的話可以通過配置 Alert Manger 的 Receiver 來實(shí)現(xiàn)，包括打電話、郵件、短信等等，配置規(guī)則可以見：https://prometheus.io/docs/alerting/configuration/。

目前我是利用了組內(nèi)已經(jīng)提供的報(bào)警機(jī)制，組內(nèi)已經(jīng)對(duì)接好了電話、短信、郵件報(bào)警，并可以把每個(gè)人的信息進(jìn)行管理和分組，然后應(yīng)用到某個(gè)報(bào)警規(guī)則里面，這樣一旦有問題，就可以實(shí)現(xiàn)報(bào)警啦。

另外對(duì)于一些規(guī)則的管理，我們可以使用一些開源的 Dashboard 來管理，如 Krama，https://github.com/prymitive/karma，利用它我們可以方便配置、禁用和篩選一些報(bào)警規(guī)則，界面如下：

Krama

不過公司內(nèi)部已經(jīng)實(shí)現(xiàn)了一套了，對(duì)接了公司的員工賬號(hào)，更加方便，所以我就沒有再用這個(gè)了。

定時(shí)重啟

這里另外遇到了一個(gè)問題，就是 JMeter 導(dǎo)出的監(jiān)控?cái)?shù)據(jù)是不斷累積的，而監(jiān)控的數(shù)據(jù)則是需要監(jiān)控最近幾分鐘的數(shù)據(jù)，這樣一旦發(fā)生了 Error，那么 Error Rate 由于歷史數(shù)據(jù)的原因，在服務(wù)恢復(fù)之后永遠(yuǎn)不會(huì)降為 0，這就導(dǎo)致一些問題。另外如果 JMeter 如果一直運(yùn)行，其占用的內(nèi)存會(huì)越來越大。

所以一個(gè)最好的方式就是定時(shí)將 JMeter 重啟，這樣可以定時(shí)清空歷史監(jiān)控?cái)?shù)據(jù)，保證在新的一段時(shí)間內(nèi)測(cè)試獲取到最近的監(jiān)控?cái)?shù)據(jù)，而不是混雜歷史數(shù)據(jù)。

這里重啟就可以利用 Kubernetes 的 Cronjob，比如我們可以每隔 10 分鐘讓 JMeter 重啟一次，類似配置如下：

apiVersion: batch/v1beta1 kind: CronJob metadata:name: jmeter-monitor spec:successfulJobsHistoryLimit: 0failedJobsHistoryLimit: 0concurrencyPolicy: Replaceschedule: "*/10 * * * *"jobTemplate:spec:template:metadata:labels:service: jmeter-monitorspec:containers:- args:- jmeter-monitor.jmximage: germey/jmeter:1name: jmeter-monitorvolumeMounts:- mountPath: /appname: jmeter-storageports:- containerPort: 80imagePullPolicy: IfNotPresentresources:requests:memory: "4Gi"cpu: "250m"limits:memory: "4Gi"cpu: "250m"restartPolicy: OnFailurevolumes:- name: jmeter-storagepersistentVolumeClaim:claimName: jmeter

這里有幾個(gè)地方值得注意：

?一個(gè)是 concurrencyPolicy，這里配置為 Replace，意思是重啟后新建的 Pod 會(huì)替換原來的 Pod，保證 JMeter 的 Pod 只有一個(gè)。?另外一個(gè)是 imagePullPolicy 配置為 IfNotPresent，這樣可以每次重啟的時(shí)候不用重新拉鏡像。

這樣的話，就能避免發(fā)生錯(cuò)誤的時(shí)候 Error Rate 無法降為 0 的狀態(tài)了。

好了，到此為止呢，我們就介紹完了使用 JMeter + Kubernetes + Prometheus + Grafana + Alert Manager 進(jìn)行監(jiān)控的整體思路了，希望對(duì)大家有幫助。

另外由于內(nèi)容比較多，這里很多地方?jīng)]有展開講解，比如 JMeter 的配置、Grafana 的配置、Prometheus-Operator 的配置、Alert Manager 的配置等等，不知道大家感不感興趣，如果感興趣的話，后面可以繼續(xù)深入寫一個(gè)小系列來講解哈。

總結(jié)

以上是生活随笔為你收集整理的如何实时主动监控你的网站接口是否挂掉并及时报警的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。