Prometheus 告警為什么選用Alertmanager？
本文轉(zhuǎn)載自微信公眾號(hào)「猿天地」，作者尹吉?dú)g。轉(zhuǎn)載本文請(qǐng)聯(lián)系猿天地公眾號(hào)。
為什么要用 alertManager
alertmanager 主要用于接收 Prometheus 發(fā)送的告警信息，它支持多種告警通知渠道，而且很容易做到告警信息進(jìn)行去重，降噪，分組等，超級(jí)好用。
其實(shí) Grafana 也自帶了告警功能，本來(lái)想直接用 Grafana 的告警功能，這樣就不用多部署一個(gè)組件了，試用了一下 Grafana 的告警，不是很好用，然后就放棄了。
看上圖，最難受的就是 Template variables are not supported in alert queries 這段話了，不能用于變量類型的模板。下面來(lái)解釋下這個(gè)問(wèn)題：
指標(biāo)查詢語(yǔ)句如下：
- sum(rate(http_server_requests_seconds_count{application="$application", instance="$instance"}[1m]))
其實(shí)是根據(jù) application 和 instance 來(lái)查詢的，也就是在查詢的時(shí)候可以選擇哪個(gè)應(yīng)用，哪個(gè)實(shí)例進(jìn)行數(shù)據(jù)的查看。
但是你如果要用 Grafana 的告警，就不能這么寫，那要怎么寫呢?把變量去掉。
假如我的 A 服務(wù)有 5 個(gè)實(shí)例，那么你就得配置 5 個(gè)查詢語(yǔ)句，如下:
- sum(rate(http_server_requests_seconds_count{application="a-service", instance="10.11.11.12"}[1m]))
- sum(rate(http_server_requests_seconds_count{application="a-service", instance="10.11.11.13"}[1m]))
- sum(rate(http_server_requests_seconds_count{application="a-service", instance="10.11.11.14"}[1m]))
- sum(rate(http_server_requests_seconds_count{application="a-service", instance="10.11.11.15"}[1m]))
- sum(rate(http_server_requests_seconds_count{application="a-service", instance="10.11.11.16"}[1m]))
到了這一步我就直接放棄了，太難用了，不知道有沒(méi)有其他的方式能夠解決這個(gè)問(wèn)題，反正我是投向了 alertmanager。
部署 alertManager
部署 alertmanager 之前我們首先部署一個(gè)釘釘消息的轉(zhuǎn)發(fā)服務(wù)，也就是當(dāng)有告警的時(shí)候，alertmanager 會(huì)調(diào)用這個(gè)轉(zhuǎn)發(fā)服務(wù)將告警內(nèi)容發(fā)送至釘釘。
- docker run -d -p 8060:8060 --name webhook timonwong/prometheus-webhook-dingtalk --ding.profile="webhook1=
- https://oapi.dingtalk.com/robot/send?access_token=你的token"
釘釘機(jī)器人需要自定義關(guān)鍵詞來(lái)匹配告警信息，否則接收不到消息。
直接用 Docker 來(lái)部署 alertmanager，命令如下：
- docker run -d --name alertmanager -p 9093:9093 -v /opt/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml prom/alertmanager:latest
alertmanager.yml
- global:
- resolve_timeout: 5m
- route:
- receiver: webhook
- group_wait: 30s
- group_interval: 5m
- repeat_interval: 5m
- group_by: [alertname]
- routes:
- - receiver: webhook
- group_wait: 10s
- receivers:
- - name: webhook
- webhook_configs:
- - url: http://10.100.0.168:8060/dingtalk/webhook1/send
- send_resolved: true
webhook 的通知地址我們配置成上面我們部署的釘釘轉(zhuǎn)發(fā)服務(wù)的 IP+Port 就可以了。
修改 prometheus 的配置文件，增加 alertmanager 的配置。
prometheus.yml
- # Alertmanager configuration
- alerting:
- alertmanagers:
- - static_configs:
- - targets: ["10.100.0.168:9093"]
- rule_files:
- - "/etc/prometheus/rules.yml"
配置告警規(guī)則
rules.yml
- groups:
- - name: qps
- rules:
- - alert: QPS告警
- expr: (sum by(instance,application)(rate(http_server_requests_seconds_count[1m]))) > 100
- for: 1m
- labels:
- severity: warning
- annotations:
- description: "應(yīng)用:{{ $labels.application }} 實(shí)例:{{ $labels.instance }} QPS超過(guò)100 (當(dāng)前值: {{ $value }})"
- summary: ""
- - alert: 應(yīng)用下線告警
- expr: up == 0
- for: 0m
- labels:
- severity: warning
- annotations:
- description: "應(yīng)用:{{ $labels.job }} 實(shí)例:{{ $labels.instance }} 已下線"
- summary: ""
上面配置了 QPS 告警和應(yīng)用下線的告警，關(guān)于告警規(guī)則不做詳細(xì)講解，大家可以自己去學(xué)習(xí)下，當(dāng)然也有一些可以參考的規(guī)則配置，具體可以查看這個(gè)網(wǎng)站：https://awesome-prometheus-alerts.grep.to/rules
配置好了后可以在 prometheus 的 Web 控制臺(tái) Alerts 中進(jìn)行查看。
告警效果
遇到的問(wèn)題
在告警內(nèi)容顯示這塊遇到了一個(gè)問(wèn)題，研究了挺長(zhǎng)時(shí)間的。上面有貼釘釘告警后的消息接入，在描述信息中有寫哪個(gè)應(yīng)用，哪個(gè)實(shí)例出問(wèn)題了，就是這 2 個(gè)具體的信息，在我一開(kāi)始配置告警規(guī)則的時(shí)候沒(méi)有獲取到值。
沒(méi)有獲取到值的原因是我的告警規(guī)則是這樣寫的：
- sum (rate(http_server_requests_seconds_count[1m])) > 100
規(guī)則本身沒(méi)問(wèn)題，也能執(zhí)行，就是實(shí)例值獲取不到，后面研究了網(wǎng)上一些其他的規(guī)則，發(fā)現(xiàn)想要獲取具體的值，就得在規(guī)則里面包含這些內(nèi)容才行。
然后就改用下面的方式了，在 sum 后接上要顯示的指標(biāo)名稱，就可以在告警信息中顯示了。跟 Sql 中的 select 一樣，沒(méi)有寫清要哪個(gè)字段就不會(huì)查詢出來(lái)。
- (sum by(instance,application)(rate(http_server_requests_seconds_count[1m]))) > 100
關(guān)于作者：尹吉?dú)g，簡(jiǎn)單的技術(shù)愛(ài)好者，《Spring Cloud 微服務(wù)-全棧技術(shù)與案例解析》, 《Spring Cloud 微服務(wù) 入門 實(shí)戰(zhàn)與進(jìn)階》作者, 公眾號(hào)猿天地發(fā)起人。
