總結(jié)部署流程
部署Alertmanager
配置Prometheus與Alertmanager通信
配置告警
prometheus指定rules目錄 ，創(chuàng)建告警yaml
configmap存儲告警規(guī)則
configmap掛載到容器rules目錄
增加alertmanager告警配置，有倆種方式下面注意下
這里是定義誰發(fā)送這個告警信息的，誰接收這個郵件
Alertmanager 三大核心
1. 分組告警
分組告警是指：prometheus的告警規(guī)則是對所有監(jiān)控實(shí)例都生效的，當(dāng)同一種類型的告警觸發(fā)后會匯聚一起，并且發(fā)送一個告警消息，降低告警噪音。
AlertManager告警分組參數(shù)
route:
//根據(jù)標(biāo)簽進(jìn)行分組，alertname就是告警規(guī)則的名稱，多個標(biāo)簽可以以逗號隔開
group_by: ['alertname']
//發(fā)送告警等待時間，也就是一個時間范圍內(nèi)，如果同一組中有其他報警則一并發(fā)送
group_wait: 10s
//當(dāng)觸發(fā)了一組告警后，下一組報警觸發(fā)的間隔
group_interval: 10s
//告警產(chǎn)生沒有修復(fù)重復(fù)報警的時間間隔
repeat_interval: 10m
2. 告警抑制
通過抑制可以避免產(chǎn)生大量的告警風(fēng)暴，當(dāng)一個節(jié)點(diǎn)宕機(jī)設(shè)置標(biāo)簽為serverity=critical，而節(jié)點(diǎn)上的應(yīng)用告警設(shè)置為serverity=warning，當(dāng)節(jié)點(diǎn)宕機(jī)后可以使用抑制的方法，僅發(fā)送一條節(jié)點(diǎn)宕機(jī)的信息，而不是發(fā)送多條信息。
aertManager告警抑制參數(shù)
inhibit_rules:
- source_match:
// 源標(biāo)簽警報觸發(fā)時抑制含有目標(biāo)標(biāo)簽的警報，在當(dāng)前警報匹配serverity=critical
serverity: 'critical'
target_match:
// 抑制`serverity=warning`類型告警
serverity: 'warning'
// 告警中包含的分組名稱。標(biāo)簽內(nèi)容相同才會抑制,也就是說警報中三個標(biāo)簽值相同才會被抑制。equal: ['alertname', 'dev', 'instance']
Prometheus 告警級別
告警級別分為warning、critical和emergency。嚴(yán)重等級依次遞增。
3. 告警靜默
靜默是指定周期時間內(nèi)不再觸發(fā)某一個報警。alertManager將檢查傳入警報是否與活動靜默的所有相等或正則表達(dá)式匹配。匹配靜默規(guī)則，則不會為該警報發(fā)送任何通知。
Alertmanager Web UI 設(shè)置靜默告警規(guī)則
報警過濾
有的時候可能報警通知太過頻繁，或者在收到報警通知后就去開始處理問題了，這個期間可能報警還在頻繁發(fā)送，這個時候我們可以去對報警進(jìn)行靜默設(shè)置。
靜默通知
方案一：
在 Alertmanager 的后臺頁面中提供了靜默操作的入口。
可以點(diǎn)擊右上面的 New Silence 按鈕新建一個靜默通知
我們可以選擇此次靜默的開始時間、結(jié)束時間，最重要的是下面的 Matchers 部分，用來匹配哪些報警適用于當(dāng)前的靜默，比如這里我們設(shè)置 instance=k8s-node1 的標(biāo)簽，則表示具有這個標(biāo)簽的報警在 2 小時內(nèi)都不會觸發(fā)報警，點(diǎn)擊下面的 Create 按鈕即可創(chuàng)建：
方案二：
抑制報警規(guī)則
除了上面的靜默機(jī)制之外，Alertmanager 還提供了抑制機(jī)制來控制告警通知的行為。抑制是指當(dāng)某次告警發(fā)出后，可以停止重復(fù)發(fā)送由此告警引發(fā)的其他告警的機(jī)制，比如現(xiàn)在有一臺服務(wù)器宕機(jī)了，上面跑了很多服務(wù)都設(shè)置了告警，那么肯定會收到大量無用的告警信息，這個時候抑制就非常有用了，可以有效的防止告警風(fēng)暴。
要使用抑制規(guī)則，需要在 Alertmanager 配置文件中的 inhibit_rules 屬性下面進(jìn)行定義，每一條抑制規(guī)則的具體配置如下：
target_match:
[ <labelname>: <labelvalue>, ... ]
target_match_re:
[ <labelname>: <regex>, ... ]
target_matchers:
[ - <matcher> ... ]
source_match:
[ <labelname>: <labelvalue>, ... ]
source_match_re:
[ <labelname>: <regex>, ... ]
source_matchers:
[ - <matcher> ... ]
[ equal: '[' <labelname>, ... ']' ]
# 當(dāng)有新的告警規(guī)則如果滿足 `source_match` 或者 `source_match_re` 的匹配規(guī)則，并且已發(fā)送的告警與新產(chǎn)生的告警中
`equal` 定義的標(biāo)簽完全相同，則啟動抑制機(jī)制，新的告警不會發(fā)送。
# 當(dāng)已經(jīng)發(fā)送的告警通知匹配到 `target_match` 和 `target_match_re` 規(guī)則
案例一
比如現(xiàn)在我們?nèi)缦滤镜膬蓚€報警規(guī)則 NodeMemoryUsage 與 NodeLoad
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: node
namespace: default
spec:
groups:
- name: node-mem
rules:
- alert: NodeMemoryUsage
annotations:
description: '{{$labels.instance}}: 內(nèi)存使用率高于 30% (當(dāng)前值為: {{ printf "%.2f" $value }}%)'
summary: '{{$labels.instance}}: 檢測到高內(nèi)存使用率'
expr: |
(node_memory_MemTotal_bytes - (node_memory_MemFree_bytes + node_memory_Buffers_bytes + node_memory_Cached_bytes)) /
node_memory_MemTotal_bytes * 100 > 30
for: 1m
labels:
team: node
severity: critical
- name: node-load
rules:
- alert: NodeLoad
annotations:
summary: '{{ $labels.instance }}: 低節(jié)點(diǎn)負(fù)載檢測'
description: '{{ $labels.instance }}: 節(jié)點(diǎn)負(fù)載低于 1 (當(dāng)前值為: {{ $value }})'
expr: node_load5 < 1
for: 2m
labels:
team: node
severity: normal
當(dāng)前我們系統(tǒng)里面普通（severity: normal）的告警有三條，k8s-node1、k8s-node2 和 k8s-master 三個節(jié)點(diǎn)，另外一個報警也有倆條，k8s-node1和 k8s-master 三個節(jié)點(diǎn)：
現(xiàn)在我們來配置一個抑制規(guī)則，如果 NodeMemoryUsage 報警觸發(fā)，則抑制 NodeLoad 指標(biāo)規(guī)則引起的報警，我們這里就會抑制 k8s-master 和 k8s-node1 節(jié)點(diǎn)的告警，只會剩下 k8s-node2 節(jié)點(diǎn)的普通告警。
通過修改Alertmanager 配置文件中添加如下所示的抑制規(guī)則
apiVersion: monitoring.coreos.com/v1alpha1
kind: AlertmanagerConfig
metadata:
name: email-config
namespace: monitoring
labels:
alertmanagerConfig: wangxiansen
spec:
route:
groupBy: ['alertname']
groupWait: 30s
groupInterval: 5m
repeatInterval: 12h
receiver: 'Critical'
continue: false
routes:
- receiver: 'Critical'
match:
severity: critical
receivers:
- name: Critical
emailConfigs:
- to: '@boysec.cn'
html: '{{ template "email.html" . }}'
sendResolved: true
inhibitRules:
- equal: ['instance']
sourceMatch:
- name: alertname
value: NodeMemoryUsage
- name: severity
value: critical
targetMatch:
- name: severity
value: normal
更新報警規(guī)則
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yaml
kubectl apply -f alertmanager-main-secret.yaml
更新配置后，最好重建下 Alertmanager，這樣可以再次觸發(fā)下報警，可以看到只能收到 k8s-node2 節(jié)點(diǎn)的 NodeLoad 報警了，另外兩個節(jié)點(diǎn)的報警被抑制了：
參考文檔
1-alertmanager 實(shí)現(xiàn)不同的告警級別發(fā)送給不同的接收人
文章參考 https://cloud.tencent.com/developer/article/2216582?areaId=106001
2-自定義路由告警，分來自不同路由的告警，艾特不同的人員進(jìn)行區(qū)分
文章參考 https://cloud.tencent.com/developer/article/2327646?areaId=106001
3-根據(jù)不同告警級別設(shè)置發(fā)送接受器
文章參考 https://blog.51cto.com/u_12965094/2689914
自定義路由告警，分來自不同路由的告警，艾特不同的人員進(jìn)行區(qū)分
修改 alertmanager 配置有倆種方法
Alertmanager CRD
Prometheus Operator 為 alertmanager 抽象了兩個 CRD資源:
可以理解為倆中方式更新alertmanager，
-
alertmanagerCRD: 基于 statefulset, 實(shí)現(xiàn) alertmanager 的部署以及擴(kuò)容縮容
這種方式是新建 `alertmanager.yaml` 配置文件，生成 secret更新替代默認(rèn)的。
注意，這個相當(dāng)于總配置文件，需要在`alertmanager.yaml`填寫的東西比較多，模板，分組什么的。。。。。
- **如果您的需求比較簡單，或者不需要分割配置權(quán)限**，直接使用 `alertmanager.yaml` 并通過 Secret 應(yīng)用，如您所做的，就足夠了。這種方式簡單直接，適用于許多場景。
-
alertmanagerconfigCRD: 實(shí)現(xiàn)模塊化修改 alertmanager 的配置
如果您使用的是較新版本的 Prometheus Operator**，它支持 `AlertmanagerConfig` 資源，這是一種更為聲明式的方法來定義 Alertmanager 的配置。通過使用AlertmanagerConfig資源，您可以更方便地在多個團(tuán)隊(duì)之間分割告警配置，每個團(tuán)隊(duì)可以管理自己的告警路由、接收器等，而不需要直接編輯 `alertmanager.yaml` 文件。這對于多租戶環(huán)境非常有用。簡單一點(diǎn)就是更新內(nèi)容上去，不會改變默認(rèn)的
global:
resolve_timeout: 5m # 該參數(shù)定義了當(dāng)Alertmanager持續(xù)多長時間未接收到告警后標(biāo)記告警狀態(tài)為resolved
http_config: {} # HTTP 配置，此處為空對象，表示沒有特定的配置
smtp_hello: localhost # SMTP 郵件發(fā)送時使用的 HELO 消息
smtp_require_tls: true # SMTP 郵件發(fā)送是否需要使用 TLS
pagerduty_url: https://events.pagerduty.com/v2/enqueue # PagerDuty API URL
opsgenie_api_url: https://api.opsgenie.com/ # Opsgenie API URL
wechat_api_url: https://qyapi.weixin.qq.com/cgi-bin/ # 微信企業(yè)號 API URL
victorops_api_url: https://alert.victorops.com/integrations/generic/20131114/alert/ # VictorOps API URL
route:
receiver: Default # 默認(rèn)的接收器名稱
group_by: # 分組字段，用于將警報按照指定字段進(jìn)行分組
- namespace # 按照命名空間分組
routes: # 路由規(guī)則列表
- receiver: Watchdog # 接收器名稱為 Watchdog 的路由規(guī)則
match: # 匹配條件
alertname: Watchdog # 匹配警報名稱為 Watchdog 的警報
- receiver: Critical # 接收器名稱為 Critical 的路由規(guī)則
match: # 匹配條件
severity: critical # 匹配嚴(yán)重程度為 critical 的警報
group_wait: 30s # 在組內(nèi)等待所配置的時間，如果同組內(nèi)，30秒內(nèi)出現(xiàn)相同報警，在一個組內(nèi)發(fā)送報警。
group_interval: 5m # 如果組內(nèi)內(nèi)容不變化，合并為一條警報信息，5m后發(fā)送。
repeat_interval: 12h # 發(fā)送報警間隔，如果指定時間內(nèi)沒有修復(fù)，則重新發(fā)送報警。
inhibit_rules: # 抑制規(guī)則列表，用于控制警報傳播的行為
- source_match: # 源警報匹配條件
severity: critical # 源警報的嚴(yán)重程度為 critical
target_match_re: # 目標(biāo)警報匹配條件（使用正則表達(dá)式進(jìn)行匹配）
severity: warning|info # 目標(biāo)警報的嚴(yán)重程度為 warning 或 info
equal: # 需要匹配相等的字段
- namespace # 命名空間字段需要相等
- alertname # 警報名稱字段需要相等
- source_match: # 源警報匹配條件
severity: warning # 源警報的嚴(yán)重程度為 warning
target_match_re: # 目標(biāo)警報匹配條件（使用正則表達(dá)式進(jìn)行匹配）
severity: info # 目標(biāo)警報的嚴(yán)重程度為 info
equal: # 需要匹配相等的字段
- namespace # 命名空間字段需要相等
- alertname # 警報名稱字段需要相等
receivers: # 接收器列表
- name: Default # 默認(rèn)接收器
- name: Watchdog # Watchdog 接收器
- name: Critical # Critical 接收器
templates: [] # 模板列表，此處為空列表，表示沒有定義任何模板
案例介紹
基于自定義路由告警，我們依舊使用prometheusAlert作為告警渠道，為了方便區(qū)分來自不同路由的告警，我們這里使用不同分組進(jìn)行告警
環(huán)境概述
root@k8s-master01:~/test/prometheus/prometheus-whach# kubectl get pod -n monitoring
root@k8s-master01:~/test/prometheus/prometheus-whach# kubectl get node
快速開始
1-查看現(xiàn)有的規(guī)則配置文件
kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d
1-secret方式
新建 alertmanager.yaml 配置文件
相當(dāng)于總配置文件，需要填寫的東西比較多
只需要三個文件
global:
resolve_timeout: 1m # 解決超時時間，指定Alertmanager標(biāo)記告警狀態(tài)為已解決（resolved）之前等待的時間
templates:
- '/etc/alertmanager/configmaps/alertmanager-templates/*.tmpl'
route:
receiver: 'ops-err' # 默認(rèn)的接收器名稱
group_wait: 30s # 在組內(nèi)等待所配置的時間，如果同組內(nèi)，30秒內(nèi)出現(xiàn)相同報警，在一個組內(nèi)發(fā)送報警。
group_interval: 1m # 如果組內(nèi)內(nèi)容不變化，合并為一條警報信息，5m后發(fā)送。
repeat_interval: 10m # 發(fā)送報警間隔，如果指定時間內(nèi)沒有修復(fù)，則重新發(fā)送報警。
group_by: [alertname, instance] # 報警分組
routes: # 子路由的匹配設(shè)置
- matchers:
- severity = warning
receiver: 'ops-err'
continue: true
# 使用新的 matchers 語法匹配嚴(yán)重級別為 warning 的告警，并發(fā)送到 ops-err 接收器
- matchers:
- severity =~ error|critical
receiver: 'devops'
continue: true
# 使用新的 matchers 語法和正則表達(dá)式匹配嚴(yán)重級別為 error 或 critical 的告警，并發(fā)送到 devops 接收器
receivers:
- name: 'devops'
wechat_configs:
- corp_id: '' # 企業(yè)ID
to_user: '@all' # 發(fā)送所有人
agent_id: '1000002' # agentID
api_secret: '' # secret
# 使用企業(yè)微信發(fā)送消息
- name: 'ops-critical'
wechat_configs:
- corp_id: '' # 企業(yè)ID
to_user: '@all' # 發(fā)送所有人
agent_id: '1000005' # agentID
api_secret: '' # secret
# 使用企業(yè)微信發(fā)送消息
- name: 'ops-err'
wechat_configs:
- corp_id: '' # 企業(yè)ID
to_user: '@all' # 發(fā)送所有人
agent_id: '1000003' # agentID
api_secret: '' # secret
# 使用企業(yè)微信發(fā)送消息
1.2-修改 secret alertmanager-main
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run=client -o yaml > alertmanager-main-secret.yaml
kubectl apply -f alertmanager-main-secret.yaml
1.2.1查看日志看看有沒有報錯
kubectl logs -f prometheus-operator-68f6c79f9d-24fcm -n monitoring
查看生成的 secret alertmanager-main
kubectl get secret alertmanager-main -n monitoring -o jsonpath='{.data.alertmanager\.yaml}' |base64 -d
之后 prometheus-operator 會自動更新 alertmanager 的配置
# kubectl logs -n monitoring -l app.kubernetes.io/name=prometheus-operator | tail -1
level=info ts=2023-04-30T11:43:01.104579363Z caller=operator.go:741 component=alertmanageroperator key=monitoring/main msg="sync alertmanager"
1.3- 查看Alertmanager——ui頁面
規(guī)則變成你定義的拉
查報警的分組也變成你得定義的路由規(guī)則
1.4查看報警
1.2 配置告警模板
1.2.1創(chuàng)建 wechat.tmpl模板
vim WeChat.tmpl
{{ define "wechat.default.message" }}
{{- if gt (len .Alerts.Firing) 0 -}}
{{- range $index, $alert := .Alerts -}}
{{- if eq $index 0 }}
=========xxx環(huán)境監(jiān)控報警 =========
告警狀態(tài)：{{ .Status }}
告警級別：{{ .Labels.severity }}
告警類型：{{ $alert.Labels.alertname }}
故障主機(jī): {{ $alert.Labels.instance }} {{ $alert.Labels.pod }}
告警主題: {{ $alert.Annotations.summary }}
告警詳情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}};
觸發(fā)閥值：{{ .Annotations.value }}
故障時間: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
========= = end = =========
{{- end }}
{{- end }}
{{- end }}
{{- if gt (len .Alerts.Resolved) 0 -}}
{{- range $index, $alert := .Alerts -}}
{{- if eq $index 0 }}
=========xxx環(huán)境異?；謴?fù) =========
告警類型：{{ .Labels.alertname }}
告警狀態(tài)：{{ .Status }}
告警主題: {{ $alert.Annotations.summary }}
告警詳情: {{ $alert.Annotations.message }}{{ $alert.Annotations.description}};
故障時間: {{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
恢復(fù)時間: {{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}
{{- if gt (len $alert.Labels.instance) 0 }}
實(shí)例信息: {{ $alert.Labels.instance }}
{{- end }}
========= = end = =========
{{- end }}
{{- end }}
{{- end }}
{{- end }}
1.2.2創(chuàng)建 configmap
kubectl create configmap alertmanager-templates --from-file=wechat.tmpl --dry-run=client -o yaml -n monitoring > alertmanager-configmap-templates.yaml
kubectl apply -f alertmanager-configmap-templates.yaml
查看掛載
root@k8s-master01:~/test/prometheus/prometheus-whach/route# kubectl get pod -n monitoring alertmanager-main-0 -o jsonpath="{.spec.volumes[?(@.name=='configmap-alertmanager-templates')]}" | python3 -m json.tool
{
"configMap": {
"defaultMode": 420,
"name": "alertmanager-templates"
},
"name": "configmap-alertmanager-templates"
}
查看容器內(nèi)的路徑
# kubectl exec -it alertmanager-main-0 -n monitoring -- cat /etc/alertmanager/configmaps/alertmanager-templates/wechat.tmpl
1.3查看企業(yè)微信報警
分級別告警
設(shè)置告警監(jiān)控所有命名空間pod
1.1修改 alertmanager.yaml
增加命名空間跟pod
global:
resolve_timeout: 1m
templates:
- '/etc/alertmanager/configmaps/alertmanager-templates/*.tmpl'
route:
receiver: 'ops-err'
group_wait: 10s
group_interval: 30s
repeat_interval: 30s
group_by: [alertname, instance, pod, namespace]
routes:
- matchers:
- severity = warning
receiver: 'ops-err'
continue: true
- matchers:
- severity =~ error|critical
receiver: 'devops'
continue: true
receivers:
- name: 'devops'
wechat_configs:
- corp_id: ''
to_user: '@all'
agent_id: '1000002'
api_secret: ''
- name: 'ops-critical'
wechat_configs:
- corp_id: ''
to_user: '@all'
agent_id: '1000005'
api_secret: ''
- name: 'ops-err'
wechat_configs:
- corp_id: ''
to_user: '@all'
agent_id: '1000003'
api_secret: ''
詳解
在你的配置中，`group_by: [alertname, instance, pod, namespace]` 的含義是：
- `alertname`: 告警的名稱。這通常是在 Prometheus 告警規(guī)則中定義的告警類型，例如 `PodNotRunning`。
- `instance`: 發(fā)生告警的實(shí)例。在 Kubernetes 監(jiān)控中，這通常是 Pod 的 IP 地址或者節(jié)點(diǎn)的 IP 地址。
- `pod`: 發(fā)生告警的 Pod 的名稱。
- `namespace`: 發(fā)生告警的 Pod 所在的命名空間。
只有當(dāng)這四個標(biāo)簽都相同時，告警才會被歸為同一組。這意味著，即使是同一種告警（`alertname`）和同一節(jié)點(diǎn)（`instance`），只要是不同的 Pod 或者命名空間，也會被視為不同的告警組，會單獨(dú)觸發(fā)一個告警。
例如，如果有兩個告警：
- 告警 A: `{alertname="PodNotRunning", instance="10.0.0.1", pod="pod-1", namespace="ns-1"}`
- 告警 B: `{alertname="PodNotRunning", instance="10.0.0.1", pod="pod-2", namespace="ns-1"}`
盡管它們的 `alertname` 和 `instance` 都相同，但是 `pod` 不同，所以它們會被視為兩個不同的告警組，會分別觸發(fā)兩個告警。
1.2更新 secret
kubectl create secret generic alertmanager-main -n monitoring --from-file=alertmanager.yaml --dry-run -oyaml > alertmanager-main-secret.yaml kubectl apply -f alertmanager-main-secret.yaml
1.3配置告警規(guī)則
vim prometheus-pod-rules.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: node
namespace: default
labels:
group: frem-k8s # 添加全局分組標(biāo)簽
spec:
groups:
- name: pod-status
rules:
- alert: PodNotRunning
annotations:
summary: 'Pod狀態(tài)異常'
description: 'Pod {{$labels.pod}} 在命名空間 {{$labels.namespace}} 中不在 Running 狀態(tài)'
expr: |
kube_pod_status_phase{phase!="Running"} > 0
for: 1m
labels:
team: k8s-cluster
severity: error
創(chuàng)建規(guī)則 kubectl apply -f prometheus-pod-rules.yaml
1.4查看報警
這樣，每個不在 Running 狀態(tài)的 Pod 都會觸發(fā)一個單獨(dú)的告警。
優(yōu)化
如果有很多pod處于!="Running狀態(tài)，會產(chǎn)生很多條告警
優(yōu)化一：
例如，你可以將 group_by 參數(shù)設(shè)置為 [alertname, instance, namespace]，這樣，只要是同一種告警（alertname）、同一節(jié)點(diǎn)（instance）和同一命名空間（namespace），即使是不同的 Pod，也會被視為同一組告警。
route:
receiver: 'ops-err'
group_wait: 10s
group_interval: 30s
repeat_interval: 30s
group_by: [alertname, instance, namespace]
優(yōu)化二
例如，你可以定義一個抑制規(guī)則，當(dāng)同一命名空間中有多個 Pod 發(fā)生告警時，只發(fā)送一條告警通知：
route:
receiver: 'ops-err'
group_wait: 10s
group_interval: 30s
repeat_interval: 30s
group_by: [alertname, instance, pod, namespace]
routes:
- matchers:
- severity = warning
receiver: 'ops-err'
continue: true
- matchers:
- severity =~ error|critical
receiver: 'devops'
continue: true
inhibit_rules:
- source_match:
severity: 'critical'
target_match:
severity: 'warning'
equal: ['alertname', 'namespace']
優(yōu)化三
定義告警規(guī)則的抓取時間，或者檢測pod的時間
route:
receiver: 'ops-err'
group_wait: 10s
group_interval: 30s
repeat_interval: 10m ## 時間改長
group_by: [alertname, instance, pod, namespace]
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: node
namespace: default
labels:
group: frem-k8s # 添加全局分組標(biāo)簽
spec:
groups:
- name: pod-status
rules:
- alert: PodNotRunning
annotations:
summary: 'Pod狀態(tài)異常'
description: 'Pod {{$labels.pod}} 在命名空間 {{$labels.namespace}} 中不在 Running 狀態(tài)'
expr: |
kube_pod_status_phase{phase!="Running"} > 0
for: 1m #時間改長
labels:
team: k8s-cluster
severity: error
2.1-AlertmanagerConfig方式
這個方式我沒有做出來，如果有大佬 做出來可以私信我
詳解一
在 Prometheus Operator 的 AlertmanagerConfig 資源中，目前還不支持直接定義企業(yè)微信告警。在 AlertmanagerConfig 中，接收器（receivers）只支持以下類型的配置：webhookConfigs，emailConfigs，pagerdutyConfigs，opsgenieConfigs，slackConfigs，victorOpsConfigs，wechatConfigs 并未在 AlertmanagerConfig 資源的接收器配置中被直接支持。
但是，您可以通過 webhook 的方式來實(shí)現(xiàn)。您需要自己搭建一個 webhook 服務(wù)，這個服務(wù)接收到 Alertmanager 的告警后，再將告警信息發(fā)送到企業(yè)微信。在 AlertmanagerConfig 中，您可以定義一個 webhookConfigs，其 url 指向您的 webhook 服務(wù)。
下面是一個簡單的示例：
在這個配置中，http://your-webhook-service-address/ops-err 和 http://your-webhook-service-address/devops 應(yīng)該是您自己的 webhook 服務(wù)地址，這個服務(wù)需要能夠接收告警信息并將告警發(fā)送到企業(yè)微信。
對于如何搭建這樣的 webhook 服務(wù)，您可以參考一些開源項(xiàng)目，如 prometheus-webhook-dingtalk（雖然這是一個針對釘釘?shù)捻?xiàng)目，但是其實(shí)現(xiàn)方式對于企業(yè)微信也是適用的）。
詳解二：
由于企業(yè)微信更新問題，現(xiàn)在已經(jīng)無法直接使用創(chuàng)建應(yīng)用后在alertmanager的配置文件中定義企業(yè)id及secret就可以發(fā)送告警信息了，除非填寫備案后域名；為了我們這種個人開發(fā)者非常的不便，所以本文檔是為了解決想使用企業(yè)微信告警但又無法備案的朋友
方案選擇：
第一種方案：PrometheusAlert + Prometheus + Alertmanager 實(shí)現(xiàn)各種類型告警
第二種方案：創(chuàng)建 Webhook 服務(wù)，用于轉(zhuǎn)發(fā) Alertmanager 的告警消息到企業(yè)微信機(jī)器人
方案需求
我后面希望是通過子路由匹配告警級別，去分發(fā)到不同的告警接收器，上面那個方案更適合我
為什么第一種方案：PrometheusAlert + Prometheus + Alertmanager 實(shí)現(xiàn)各種類型告警這個不適合
第二種方案：創(chuàng)建 Webhook 服務(wù)
這里我都給你們推薦參考文檔第一種，第二種你們可以進(jìn)行測試
參考文檔
第一種
[Prometheus接入AlterManager配置郵件告警(基于K8S環(huán)境部署)_prometheus配置郵箱告警-CSDN博客](https://blog.csdn.net/weixin_45310323/article/details/133965945)
[Alertmanager實(shí)現(xiàn)企業(yè)微信機(jī)器人webhook告警 - k-free - 博客園 (cnblogs.com)](https://www.cnblogs.com/k-free-bolg/p/17965930)
第二種
[kube-prometheus實(shí)現(xiàn)企業(yè)微信機(jī)器人告警_alertmanager企微告警-CSDN博客](https://blog.csdn.net/rendongxingzhe/article/details/127498349)
首先恢復(fù)你默認(rèn)的配置
kube-prometheus-0.13.0/manifests# kubectl apply -f alertmanager-secret.yaml
2.1創(chuàng)建webhook服務(wù)
用于轉(zhuǎn)發(fā)alertmanager的告警消息到企業(yè)微信機(jī)器人
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: prometheus-webhook-qywx
name: prometheus-webhook-qywx
namespace: monitoring
spec:
selector:
matchLabels:
run: prometheus-webhook-qywx
template:
metadata:
labels:
run: prometheus-webhook-qywx
spec:
containers:
- args: # 企業(yè)微信的webhook-key如何獲取可以google一下;很簡單,這里不說明了;
- --adapter=/app/prometheusalert/wx.js=/adapter/wx= #注意變更這個地址，即企業(yè)微信機(jī)器人的webhook地址
image: registry.cn-hangzhou.aliyuncs.com/guyongquan/webhook-adapter
name: prometheus-webhook-dingtalk
ports:
- containerPort: 80
protocol: TCP
---
apiVersion: v1
kind: Service
metadata:
labels:
run: prometheus-webhook-qywx
name: prometheus-webhook-qywx
namespace: monitoring
spec:
ports:
- port: 8060
protocol: TCP
targetPort: 80
selector:
run: prometheus-webhook-qywx
type: ClusterIP
文章來源：http://www.zghlxwxcb.cn/news/detail-851662.html
備注：
adapter=/app/prometheusalert/wx.js=/adapter/wx=https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=c3578c16-1a8e-ssssdddd8888888 #注意變更這個地址，即企業(yè)微信機(jī)器人的webhook地址文章來源地址http://www.zghlxwxcb.cn/news/detail-851662.html
到了這里，關(guān)于k8s1.28.8版本配置Alertmanager報警方式（郵件，企業(yè)微信）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
