19-监控 - kube-prometheus 部署

Mon, 06 Apr 2026 18:12:54 +0800

Prometheus 架构介绍

Prometheus是一个开源的系统监控和报警框架，其本身也是一个时间序列数据库（Time Series Database，TSDB），它的设计灵感来源于Google的Borgmon，就像Kubernetes是基于Borg系统开源的。

Prometheus 被称为下一代的监控平台，具有很多和“老牌”监控不一样的特性，比如

一个多维的数据模型，具有由指标名称和键-值对标识的时间序列数据。
使用PromQL查询和聚合数据，可以非常灵活地对数据进行检索。
不依赖额外的数据存储，Prometheus本身就是一个时序数据库，提供本地存储和分布式存储，并且每个Prometheus都是自治的。
应用程序暴露Metrics接口，Prometheus通过基于HTTP的Pull模型采集数据。
同时可以使用PushGateway进行Push数据。
Prometheus同时支持动态服务和静态配置发现目标机器。
支持多种图形和仪表盘，和Grafana堪称“绝配”。

Prometheus生态系统由多个组件组成，其架构如下：

Prometheus Server：Prometheus生态最重要的组件，主要用于抓取和存储时间序列数据，同时提供数据的查询和告警策略的配置管理。
Alertmanager：Prometheus生态用于告警的组件，Prometheus Server会将告警发送给Alertmanager，Alertmanager根据路由配置将告警信息发送给指定的人或组。Alertmanager支持邮件、Webhook、微信、钉钉、短信等媒介进行告警通知。
Push Gateway：Prometheus本身是通过Pull的方式拉取数据的，但是有些监控数据可能是短期的，如果没有采集数据可能会出现丢失。Push Gateway可以用来解决此类问题，它可以用来接收数据，也就是客户端可以通过Push的方式将数据推送到PushGateway，之后Prometheus可以通过Pull拉取该数据。
Exporter：主要用来采集监控数据，比如主机的监控数据可以通过node_exporter采集，MySQL的监控数据可以通过mysql_exporter采集，之后Exporter暴露一个接口，比如/metrics，Prometheus可以通过该接口采集到数据。
PromQL：PromQL其实不算Prometheus的组件，它是用来查询数据的一种语法，比如可以通过SQL语句查询数据库的数据，通过LogQL语句查询Loki的数据，通过PromQL语句查询Prometheus的数据。
Service Discovery：用来发现监控目标的自动发现，常用的有基于Kubernetes、Consul、Eureka、文件的自动发现等。
Grafana：用于展示数据，便于数据的查询和观测。

Prometheus 安装

Prometheus 有多种安装方式，比如二进制安装、容器安装和 Kubernetes 集群中安装，将 Prometheus 安装到Kubernetes 集群中也是官方推荐的部署方式。

将Prometheus安装到Kubernetes集群也有很多方式，比如 Helm、Operator 等，Prometheus 也是支持上述安装方式的。但是Prometheus是一个生态系统，有很多组件都需要安装，并且也有很多监控需要单独配置，于是Prometheus 官方开源了一个 kube-prometheus 项目，该项目不仅仅是用来安装 Prometheus 的，也包含很多其他的组件，如下所示：

Prometheus Operator
高可用的 Prometheus
高可用的 Alertmanager
主机监控 Node Exporter
Prometheus Adapter
容器监控 kube-state-metrics
图形化展示 Grafana

具体可以通过``https://github.com/prometheus-operator/kube-prometheus/``找到该项目进行查看。有了kube-prometheus项目，安装也变得非常简单，只需要两条命令即可。

首先需要通过该项目地址找到和自己Kubernetes版本对应的Kube Prometheus Stack的版本，我们使用的 kubernetes 1.32.2 ，那么对应的 Kube Prometheus Stack 版本是 release-0.15 。

从 github 下载对应分支的代码

1
2
3
4
5
6
7


# 下载源码 
# git clone -b release-0.15 https://github.com/prometheus-operator/kube-prometheus.git 
# 创建命名空间和CR
kubectl create -f manifests-orig/setup

# 部署相关组件 
kubectl apply -f manifests-orig/

查看 Prometheus 容器的状态

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


[root@master-01 ~]# kubectl get pods -n monitoring 
NAME READY STATUS RESTARTS AGE
alertmanager-main-0 2/2 Running 0 41h
alertmanager-main-1 2/2 Running 0 41h
alertmanager-main-2 2/2 Running 0 41h
blackbox-exporter-d989f64d9-9x7dn 3/3 Running 0 41h
grafana-8665b584b-bb2jr 1/1 Running 0 41h
kube-state-metrics-76ddfbb447-j7clv 3/3 Running 0 41h
node-exporter-bcp2h 2/2 Running 0 41h
node-exporter-gn26s 2/2 Running 0 41h
node-exporter-xw6p7 2/2 Running 0 41h
prometheus-adapter-599c88b6c4-6b8vv 1/1 Running 0 41h
prometheus-adapter-599c88b6c4-s62n2 1/1 Running 0 41h
prometheus-k8s-0 2/2 Running 0 41h
prometheus-k8s-1 2/2 Running 0 41h
prometheus-operator-6b64df5498-6xrxt 2/2 Running 0 41h

为了后期更新方便，这里按照类型把相关对象的资源清单文件放在不同的目录下，命令如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


mkdir alertmanager grafana kubeStateMetrics nodeExporter prometheusAdapter prometheusOperator prometheus blackboxExporter kubernetesControlPlane

mv alertmanager-* alertmanager
mv grafana-* grafana
mv kubeStateMetrics-* kubeStateMetrics
mv nodeExporter-* nodeExporter
mv prometheusAdapter-* prometheusAdapter
mv prometheusOperator-* prometheusOperator
mv prometheus-* prometheus
mv blackboxExporter-* blackboxExporter
mv kubernetesControlPlane-* kubernetesControlPlane


[root@master-01 manifests]# ll
total 40
drwxr-xr-x 2 root root 313 Dec 19 16:28 alertmanager
drwxr-xr-x 2 root root 4096 Dec 12 16:13 blackboxExporter
drwxr-xr-x 2 root root 4096 Dec 19 16:32 grafana
-rw-r--r-- 1 root root 4361 Aug 8 00:12 kubePrometheus-prometheusRule.yaml
drwxr-xr-x 2 root root 4096 Dec 12 16:13 kubernetesControlPlane
drwxr-xr-x 2 root root 4096 Dec 12 16:12 kubeStateMetrics
drwxr-xr-x 2 root root 314 Dec 12 16:12 nodeExporter
drwxr-xr-x 2 root root 4096 Dec 19 16:35 prometheus
drwxr-xr-x 2 root root 4096 Dec 12 16:12 prometheusAdapter
drwxr-xr-x 2 root root 4096 Dec 12 16:12 prometheusOperator
drwxr-xr-x 2 root root 4096 Aug 8 00:12 setup

安装成功后就可以访问 Grafana 和 Prometheus Web UI

1
2
3
4


[root@master-01 manifests]# kubectl -n monitoring get svc 
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana NodePort 10.100.55.197 <none> 3000:30030/TCP 24h 24h
prometheus-k8s NodePort 10.100.108.119 <none> 9090:30090/TCP,8080:31180/TCP 24h

Grafana 和 Prometheus Web UI 默认使用 ClusterIP，我们需要将SVC的类型修改为 NodePort。

Grafana 默认用户名、密码均为 admin

Kube-promethues 项目默认已经添加了常用的监控目标。

云原生应用监控

监控数据来源

从Prometheus的架构中了解到，Prometheus通常采用Pull的形式来拉取数据，也就意味着被监控应用只要有一个能获取到监控数据的接口，就可以采集到监控数据。

基于云原生理念开发的程序自己会暴露Metrics接口，就像Kubernetes本身的组件、Etcd等，都有一个/metrics接口，Prometheus 只需要请求这个接口即可获取到相关数据。

什么是 ServiceMonitor

如果使用二进制的方式安装 Prometheus，用户需要通过 Prometheus 的一个配置文件来配置需要监控哪些数据，或者配置一些告警策略。这个配置文件的维护非常麻烦，特别是监控项非常多的情况下，很容易出现配置错误，而在Kubernetes上部署Prometheus，可以不用去维护这个配置文件，而是通过一个叫ServiceMonitor 的资源来自动发现监控目标并动态生成配置。

监控 example-app 应用

部署应用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


apiVersion: apps/v1
kind: Deployment
metadata:
 name: example-app
spec:
 replicas: 3
 selector:
 matchLabels:
 app: example-app
 template:
 metadata:
 labels:
 app: example-app
 spec:
 containers:
 - name: example-app
 image: registry.cn-beijing.aliyuncs.com/xxhf/instrumented_app 
 ports:
 - name: web
 containerPort: 8080

为应用创建 SVC

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


kind: Service
apiVersion: v1
metadata:
 name: example-app
 labels:
 app: example-app
spec:
 selector:
 app: example-app
 ports:
 - name: web
 port: 8080

创建 serviceMonitor

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 name: example-app
 labels:
 team: frontend
 app.kubernetes.io/part-of: kube-prometheus
spec:
 jobLabel: app.kubernetes.io/name
 selector:
 matchLabels:
 app: example-app
 namespaceSelector:
 matchNames:
 - default 
 endpoints:
 - port: web

验证

监控 etcd

创建 etcd svc

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


apiVersion: v1
kind: Service
metadata:
 labels:
 app: kube-etcd
 name: kube-etcd
 namespace: kube-system
spec:
 ports:
 - name: http-metrics
 port: 2381
 protocol: TCP
 targetPort: 2381
 selector:
 component: etcd
 type: ClusterIP

创建 serviceMonitor

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 name: kube-etcd 
 namespace: kube-system
 labels:
 app.kubernetes.io/part-of: kube-prometheus
spec:
 jobLabel: component
 selector:
 matchLabels:
 app: kube-etcd 
 namespaceSelector:
 matchNames:
 - kube-system 
 endpoints:
 - port: http-metrics

验证抓取目标是否生效

1
2
3


推荐修改/etc/kubernetes/manifests/kube-controller-manager.yaml
/etc/kubernetes/manifests/kube-scheduler.yaml
/etc/kubernetes/manifests/etcd.yaml

为 etcd 配置 dashboard

非云原生应用监控

配置 mysql-exporter

非云原生应用的监控需要安装对应的 exporter，我们看一下如何实现 MySQL 的监控。

安装 mysql-exporter

1
2
3
4


wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.16.0/mysqld_exporter-0.16.0.linux-amd64.tar.gz
tar xvf mysqld_exporter-0.16.0.linux-amd64.tar.gz -C /usr/local/
ln -s /usr/local/mysqld_exporter-0.16.0.linux-amd64 /usr/local/mysqld_exporter
cd /usr/local/mysqld_exporter

创建授权

MySQL

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


dnf -y install mariadb-server mariadb
systemctl enable --now mariadb


CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'UPKeH%EsT4syjA' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';



nohup ./mysqld_exporter &

curl 192.168.5.110:9104/metrics

MariaDB

连接 mysql 需要用户名、密码，所以下载之后，首先要创建配置文件，把用户名、密码以及mysql服务器地址，这些基本信息填进去。

在 mysqld_exporter 的目录下，创建一个 .my.cnf 的文件，内容参考下面的内容：

1
2
3
4
5


[client]
host=127.0.0.1
port=3306
user=exporter
password=3HdexTlk3nOw0k!3Nji

启动 mysql_exporter

1

./mysqld_exporter

mysql_exporter 默认监听 9104 端口，请求 mysql_exporter 对外暴露的 metrics 接口。

1
2
3
4
5
6
7


[root@db-srv mysqld_exporter]# curl 127.0.0.1:9104/metrics 
# HELP go_gc_duration_seconds A summary of the wall-time pause (stop-the-world) duration in garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 4.5418e-05
go_gc_duration_seconds{quantile="0.25"} 4.7015e-05
go_gc_duration_seconds{quantile="0.5"} 4.8137e-05
... ...

配置抓取目标

我们需要在 Prometheus 配置文件中添加一个 Job，用来配置抓取 mysql-exporter metric endpoint，有两种配置方式，一种是使用 prometheus-operator 提供 CRD ScrapeConfig ，另一种方法是让prometheus 加载外部配置文件。

tar/monitor/19-monitor/kube-prometheus/manifests/custom-config

第一种方法：

修改 prometheus

1
2
3
4


spec:
 scrapeConfigSelector:
 matchLabels:
 prometheus: system-monitoring-prometheus

添加抓取目标

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


apiVersion: monitoring.coreos.com/v1alpha1
kind: ScrapeConfig
metadata:
 name: static-config
 namespace: monitoring
 labels:
 prometheus: system-monitoring-prometheus 
spec:
 staticConfigs:
 - labels:
 job: mysql
 targets:
 - 192.168.11.42:9104

验证

第二种方法：

配置 prometheus 抓取 mysqld_exporter 暴露的 metrics 信息。

我们前面配置监控目标时，用的都是ServiceMonitor，但是ServiceMonitor可能会有一些限制。比如，如果没有安装Prometheus Operator，可能就无法使用ServiceMonitor，另外并不是所有的监控都能使用ServiceMonitor进行配置，或者使用ServiceMonitor配置显得过于繁琐。此处我们使用 prometheus 默认的配置文件，添加一个抓取mysql 的 job。

首先创建一个空文件，然后通过该文件创建一个 Secret，这个 Secret 可作为 Prometheus 的静态配置：

1
2


$ touch additional-scrape-configs.yaml
$ kubectl -n monitoring create secret generic additional-scrape-configs --from-file=additional-scrape-configs.yaml

创建完 Secret后，需要编辑 Prometheus 的配置，加载我们自己创建的外部配置文件。

1

 kubectl edit prometheus -n monitoring k8s

添加以下配置文件，不需要重启 Prometheus 即可生效。之后在 additional-scrape-configs.yaml 文件内添加我们需要的静态配置即可。

1
2
3
4


spec:
 additionalScrapeConfigs:
 name: additional-scrape-configs  # secret-name 
 key: additional-scrape-configs.yaml  # key 

1
2
3
4
5


additional-scrape-configs.yaml
- job_name: mysql
 static_configs:
 - targets:
 - 192.168.11.42:9104

可以看到此处的内容和传统配置的内容一致，只需要添加对应的job即可。之后通过该文件更新该 Secret：

1

# kubectl -n monitoring create secret generic additional-scrape-configs --from-file=additional-scrape-configs.yaml --dry-run=client -o yaml | kubectl -n monitoring apply -f -

在 prometheus 的配置文件中可以验证 job 已经添加成功。

在 Targets 中也可以看到 mysql

最后在 Grafana 中创建 Dashboard，导入 MySQL Dashboard 14057 。

Blackbox 黑盒监控

对 Etcd 或MySQL 的监控是监控应用本身，也就是程序内部的一些指标，这类监控关注的是原因，一般为出现问题的根本原因，此类监控称为白盒监控。还有一类监控关注的是现象，比如某个网站突然慢了，或者打不开了。此类告警是站在用户的角度看到的东西，比较关注现象，表示正在发生的问题，这类监控称为黑盒监控。

白盒监控可以通过Exporter采集数据，黑盒监控也可以通过Exporter采集数据，新版本的PrometheusStack已经默认安装了Blackbox Exporter，可以用其采集某个域名、接口或者TCP连接的状态、是否可用等。

Prometheus 静态配置

前面几个小节配置监控目标时，用的都是ServiceMonitor，但是ServiceMonitor可能会有一些限制。比如，如果没有安装Prometheus Operator，可能就无法使用ServiceMonitor，另外并不是所有的监控都能使用ServiceMonitor进行配置，或者使用ServiceMonitor配置显得过于繁琐。

在 additional-scrape-configs.yaml 文件内继续添加以下静态配置，用于黑盒监控的配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


- job_name: 'blackbox-web'
 metrics_path: /probe
 params:
 module: [http_2xx]  # Look for a HTTP 200 response.
 static_configs:
 - targets:
 - http://prometheus.io  # Target to probe with http.
 - https://prometheus.io  # Target to probe with https.
 - http://www.xinxianghf.cn 
 relabel_configs:
 - source_labels: [__address__]
 target_label: __param_target
 - source_labels: [__param_target]
 target_label: instance
 - target_label: __address__
 replacement: blackbox-exporter:19115  # The blackbox exporter's real hostname:port.

可以看到此处的内容和传统配置的内容一致，只需要添加对应的job即可。之后通过该文件更新该Secret：

1

kubectl -n monitoring create secret generic additional-scrape-configs --from-file=additional-scrape-configs.yaml --dry-run=client -o yaml | kubectl -n monitoring replace -f -

验证配置文件是否生效

检查 Targets

配置告警

从配置文件可以看出，Alertmanager 的配置主要分为5大块：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61


global:
 # The smarthost and SMTP sender used for mail notifications.
 smtp_smarthost: 'localhost:25'
 smtp_from: 'alertmanager@example.org'
 smtp_auth_username: 'alertmanager'
 smtp_auth_password: 'password'

# The directory from which notification templates are read.
templates:
 - '/etc/alertmanager/template/*.tmpl'

# The root route on which each incoming alert enters.
route:

 group_by: ['job', 'namespace', 'alertname']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 3h

 # A default receiver
 receiver: default-team-mails

 # All the above attributes are inherited by all child routes and can
 # overwritten on each.

 # The child route trees.
 routes:
 - receiver: team-X-pager
 match_re:
 job: node_exporter 
 continue: true
 - receiver: team-X-pager
 match_re:
 job: mysqld_exporter
 continue: true
 - receiver: team-DB-pager
 match_re:
 job: .*
 continue: true

inhibit_rules:
 - source_matchers: [severity="critical"]
 target_matchers: [severity="warning"]
 equal: [alertname, cluster, service]

receivers:
 - name: 'team-X-mails'
 email_configs:
 - to: 'team-X+alerts@example.org'

 - name: 'team-X-pager'
 email_configs:
 - to: 'team-X+alerts-critical@example.org'

 - name: 'team-Y-pager'
 pagerduty_configs:
 - service_key: <team-Y-key>

 - name: 'team-DB-pager'
 pagerduty_configs:
 - service_key: <team-DB-key>

Global：全局配置，主要进行一些通用的配置，比如邮件通知的账号、密码、SMTP服务器、微信告警等。Global块配置下的配置选项在本配置文件内的所有配置项下可见，但是文件内其他位置的子配置可以覆盖Global配置。
Templates：用于放置自定义模板的位置。
Route：告警路由配置，用于告警信息的分组路由，可以将不同分组的告警发送给不同的收件人。比如将数据库告警发送给DBA，服务器告警发送给OPS。
Inhibit_rules：告警抑制，主要用于减少告警的次数，防止“告警轰炸”。比如某个宿主机宕机，可能会引起容器重建、漂移、服务不可用等一系列问题，如果每个异常均有告警，会一次性发送很多告警，造成告警轰炸，并且也会干扰定位问题的思路，所以可以使用告警抑制，屏蔽由宿主机宕机引来的其他问题，只发送宿主机宕机的消息即可。
Receivers：告警收件人配置，每个receiver都有一个名字，经过route分组并且路由后需要指定一个receiver，就在此处配置。

路由规则

Alertmanager 的配置比较复杂且经常需要变更，我们详细看一下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


route:
 group_by: ['job', 'namespace', 'alertname']
 group_wait: 30s
 group_interval: 5m
 repeat_interval: 3h

 # A default receiver
 receiver: default-team-mails

 # The child route trees.
 routes:
 - receiver: team-X-pager
 match_re:
 job: node_exporter 
 continue: true
 - receiver: team-X-pager
 match_re:
 job: mysqld_exporter
 continue: true
 - receiver: team-DB-pager
 match_re:
 job: .*
 continue: true

从配置文件可以看出，路由配置块的顶级配置由route开始，它是整个路由的入口，称作根路由。每一条告警进来后，都先进入route，之后根据告警自身的标签和route.group_by配置的字段进行分组。比如可以根据job、alertname或者其他自定义的标签名称进行分组，分组后进入子路由（通过route.routes配置子路由），进一步进行更加细粒度的划分，比如job名称包含mysql的发送给DBA组。

Route 常用的配置：

receiver：告警的通知目标，需要和receivers配置中的name进行匹配。需要注意的是，route.routes下也可以有receiver配置，优先级高于route.receiver配置的默认接收人，当告警没有匹配到子路由时，会使用route.receiver进行通知，比如上述配置中的 default-team-mails。
group_by：分组配置，值类型为列表。比如配置成[‘job’, ‘severity’]，代表告警信息包含job和severity标签的会进行分组，且标签的key和value都相同才会被分到一组。
continue：决定匹配到第一个路由后，是否继续后续匹配。默认为false，即匹配到第一个子节点后停止继续匹配。
match：一对一匹配规则，比如match配置的为job: mysql，那么具有job=mysql的告警会进入该路由。
match_re：和match类似，只不过match_re是正则匹配。
matchers：这是Alertmanager 0.22版本新添加的一个配置项，用于替换match和match_re。
group_wait：告警通知等待，值类型为字符串。若一组新的告警产生，则会等group_wait后再发送通知，该功能主要用于当告警在很短时间内接连产生时，在group_wait内合并为单一的告警后再发送，防止告警过多，默认值为30s。
group_interval：同一组告警通知后，如果有新的告警添加到该组中，再次发送告警通知的时间，默认值为5m。
repeat_interval：如果一条告警通知已成功发送，且在间隔repeat_interval后，该告警仍然未被设置为resolved，则会再次发送该告警通知，默认值为4h。

以上即为Alertmanager常用的路由配置，可以看到 Alertmanager 的路由和匹配规则非常灵活，通过不同的路由嵌套和匹配规则可以达到不同的通知效果。

配置钉钉告警

Alertmanager 的配置文件是通过 Secret 进行存储的，其原始文件为 alertmanager-secret.yaml，内容大致如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


apiVersion: v1
kind: Secret
metadata:
 labels:
 app.kubernetes.io/component: alert-router
 app.kubernetes.io/instance: main
 app.kubernetes.io/name: alertmanager
 app.kubernetes.io/part-of: kube-prometheus
 app.kubernetes.io/version: 0.28.1
 name: alertmanager-main
 namespace: monitoring
stringData:
 alertmanager.yaml: |-
 "global":
 "resolve_timeout": "5m"

 "receivers":
 - "name": "dingtalk"
 webhook_configs:
 - url: http://192.168.11.58:8060/dingtalk/webhook/send
 send_resolved: true

 "route":
 "group_by":
 - "namespace"
 - "job"
 - "alertname"
 "group_interval": "5m"
 "group_wait": "30s"
 "receiver": "dingtalk"
 "repeat_interval": "12h"
 "routes":
 - receiver: 'dingtalk'
 matchers:
 - alertname =~ "InfoInhibitor|Watchdog"
type: Opaque

修改后重新应用， alertmanager 会自动加载新的配置文件。

1
2
3
4
5

kubectl apply -f alertmanager-secret.yaml

修改之后需要去webhook配置文件中配置config.yaml配置文件的报警模版和关键词

等一会就可以在钉钉上收到告警消息了。

Prometheus 高可用

多 prometheus 实例
Thanos
VictoriaMetrics

Grafana on 小杨的博客