Prometheus on 小杨的博客

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

19-监控

Mon, 06 Apr 2026 18:10:14 +0800

Metrics Server

如果你对 Linux 系统有所了解的话，应该知道有一个命令 top 能够实时显示当前系统的 CPU 和内存利用率，它是性能分析和调优的基本工具，非常有用。Kubernetes 也提供了类似的命令，就是 kubectl top，不过默认情况下这个命令不会生效，必须要安装一个插件 Metrics Server 才可以。

Metrics Server 是一个专门用来收集 Kubernetes 核心资源指标（metrics）的工具，它定时从所有节点的 kubelet 里采集信息，但是对集群的整体性能影响极小，每个节点只大约会占用 1m 的 CPU 和 2MB 的内存，所以性价比非常高。

下面的这张图来自 Kubernetes 官网，你可以对 Metrics Server 的工作方式有个大概了解：它调用 kubelet 的 API 拿到节点和 Pod 的指标，再把这些信息交给 apiserver，这样 kubectl、HPA 就可以利用 apiserver 来读取指标了：

Metrics Server Github 地址

兼容列表：

1

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.8.1/high-availability-1.21+.yaml

修改YAML 添加 --kubelet-insecure-tls

部署

1

kubectl apply -f metrics-server-1.21+.yaml

验证

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


[root@master-01 19-monitor]# kubectl top node
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
node 204m 10% 1310Mi 69%
worker-01 88m 4% 1085Mi 57%
[root@master-01 19-monitor]#
[root@master-01 19-monitor]#
[root@master-01 19-monitor]#
[root@master-01 19-monitor]# kubectl top pods
NAME CPU(cores) MEMORY(bytes)
busybox 0m 0Mi
httpserver-d8557894d-4fg29 0m 1Mi
n1 0m 2Mi
n2 0m 2Mi
nginx 0m 2Mi

HorizontalPodAutoscaler（HPA）

有了 Metrics Server，我们就可以轻松地查看集群的资源使用状况了，不过它另外一个更重要的功能是辅助实现应用的“水平自动伸缩”。

Kubernetes 为此就定义了一个新的 API 对象，叫做“HorizontalPodAutoscaler”，简称是 “hpa”。顾名思义，它是专门用来自动伸缩 Pod 数量的对象，适用于 Deployment 和 StatefulSet，但不能用于 DaemonSet 对象。

HorizontalPodAutoscaler 的能力完全基于 Metrics Server，它从 Metrics Server 获取当前应用的运行指标，主要是 CPU 使用率，再依据预定的策略增加或者减少 Pod 的数量。下面我们就来看看该怎么使用 HorizontalPodAutoscaler，首先要定义 Deployment 和 Service，创建一个 Nginx 应用，作为自动伸缩的目标对象：

 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


apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-hpa
 labels:
 app: nginx
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx-hpa
 template:
 metadata:
 labels:
 app: nginx-hpa
 spec:
 containers:
 - name: nginx
 image: nginx:1.22.1
 ports:
 - containerPort: 80
 resources:
 requests:
 cpu: 50m
 memory: 10Mi
 limits:
 cpu: 100m
 memory: 20Mi

---
apiVersion: v1
kind: Service
metadata:
 name: nginx-hpa-svc
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 selector:
 app: nginx-hpa

接下来我们要用命令 kubectl autoscale 创建一个 HorizontalPodAutoscaler 的样板 YAML 文件，它有三个参数：

min，Pod 数量的最小值，也就是缩容的下限。
max，Pod 数量的最大值，也就是扩容的上限。
cpu-percent，CPU 使用率指标，当大于这个值时扩容，小于这个值时缩容。

好，现在我们就来为刚才的 Nginx 应用创建 HorizontalPodAutoscaler，指定 Pod 数量最少 2 个，最多 10 个，CPU 使用率指标设置的小一点，5%，方便我们观察扩容现象：

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


apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: nginx-hpa
spec:
 maxReplicas: 10
 minReplicas: 2
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: nginx-hpa
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 5

HorizontalPodAutoscaler 会根据 YAML 里的描述，找到要管理的 Deployment，把 Pod 数量调整成 2 个，再通过 Metrics Server 不断地监测 Pod 的 CPU 使用率。

下面我们来给 Nginx 加上压力流量，运行一个测试 Pod，使用的镜像是“httpd:alpine”，它里面有 HTTP 性能测试工具 ab（Apache Bench）：

1
2
3


kubectl run test -it --image=httpd:alpine -- sh 
ab -c 10 -t 60 -n 100000 'http://nginx-hpa-svc/'
kubectl get hpa nginx-hpa -w 

由于 Metrics Server 大约每 15 秒采集一次数据，所以 HorizontalPodAutoscaler 的自动化扩容和缩容也是按照这个时间点来逐步处理的。

当它发现目标的 CPU 使用率超过了预定的 5% 后，就会以 2 的倍数开始扩容，一直到数量上限，然后持续监控一段时间，如果 CPU 使用率回落，就会再缩容到最小值。

kube-prometheus

组件

Kube-prometheus 包含的组件:

The Prometheus Operator
Highly available Prometheus
Highly available Alertmanager
Prometheus node-exporter
Prometheus Adapter for Kubernetes Metrics APIs
kube-state-metrics
Grafana

Operator

Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。创建 Operator 的关键是 CRD（自定义资源）的设计。

Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API 进行开发，也就是说他们可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。

CR

CR 代表自定义资源（Custom Resource）是一种扩展 Kubernetes API 的方式，允许用户定义自己的资源类型和规范。它们允许用户在Kubernetes中创建和管理自定义资源对象，这些对象可以与Kubernetes核心资源（如Pod、Service、Deployment等）一样进行操作。

CRD

CRD（Custom Resource Definition）是一种 Kubernetes 资源，用于定义 CR 的结构和行为。通过创建CRD对象，用户可以定义新的 CR 类型，包括它们的API结构、字段、验证规则和操作行为。

通过使用CR和CRD，用户可以扩展Kubernetes的功能，以适应特定的应用需求。它们提供了一种自定义资源的机制，使用户能够以声明的方式定义和操作自己的资源类型，而无需修改Kubernetes核心代码。

 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


apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
 # 名字必需与下面的 spec 字段匹配，并且格式为 '<名称的复数形式>.<组名>'
 name: crontabs.stable.example.com
spec:
 # 组名称，用于 REST API: /apis/<组>/<版本>
 group: stable.example.com
 # 列举此 CustomResourceDefinition 所支持的版本
 versions:
 - name: v1
 # 每个版本都可以通过 served 标志来独立启用或禁止
 served: true
 # 其中一个且只有一个版本必需被标记为存储版本
 storage: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 cronSpec:
 type: string
 image:
 type: string
 replicas:
 type: integer
 # 可以是 Namespaced 或 Cluster
 scope: Namespaced
 names:
 # 名称的复数形式，用于 URL：/apis/<组>/<版本>/<名称的复数形式>
 plural: crontabs
 # 名称的单数形式，作为命令行使用时和显示时的别名
 singular: crontab
 # kind 通常是单数形式的驼峰命名（CamelCased）形式。你的资源清单会使用这一形式。
 kind: CronTab
 # shortNames 允许你在命令行使用较短的字符串来匹配资源
 shortNames:
 - ct

声明一个 CronTab 对象

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
 name: my-new-cron-object
spec:
 cronSpec: "* * * * */5"
 image: my-awesome-cron-image
[root@node-01 CRD]# kubectl get ct
NAME AGE
my-new-cron-object 6h32m

Prometheus Operator

Prometheus Operator是一种为 Kubernetes 提供本地部署和管理 Prometheus 及相关监控组件的工具。该项目的目的是简化和自动化为 Kubernetes 集群配置基于 Prometheus 的监控堆栈。

Prometheus Operator 包括但不限于以下功能：

Kubernetes自定义资源：使用Kubernetes自定义资源来部署和管理Prometheus、Alertmanager和相关组件。通过定义自定义资源对象（CRD），可以在Kubernetes中声明和配置 Prometheus 实例、Alertmanager 实例等。
简化的部署配置：通过本地的Kubernetes资源，可以配置Prometheus的基本设置，如版本、持久化、数据保留策略和副本数。这样可以更方便地进行部署配置，无需涉及复杂的配置文件。
Prometheus 目标配置：基于熟悉的Kubernetes标签查询，自动生成监控目标的配置。无需学习Prometheus特定的配置语言，即可快速定义要监控的目标。这样可以简化监控目标的配置过程。

安装 Operator

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


wget https://github.com/prometheus-operator/prometheus-operator/releases/download/v0.69.1/bundle.yaml
[root@master-01 ~]# kubectl create -f bundle.yaml 
customresourcedefinition.apiextensions.k8s.io/alertmanagerconfigs.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/alertmanagers.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/podmonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/probes.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheusagents.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheuses.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/prometheusrules.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/scrapeconfigs.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/servicemonitors.monitoring.coreos.com created
customresourcedefinition.apiextensions.k8s.io/thanosrulers.monitoring.coreos.com created
clusterrolebinding.rbac.authorization.k8s.io/prometheus-operator created
clusterrole.rbac.authorization.k8s.io/prometheus-operator created
deployment.apps/prometheus-operator created
serviceaccount/prometheus-operator created
service/prometheus-operator created

Prometheus Operator 在Kubernetes中引入了自定义资源，用于声明 Prometheus 和 Alertmanager 集群的期望状态以及Prometheus的配置。

Prometheus：Prometheus自定义资源用于定义Prometheus实例的配置和规范。可以指定版本、持久化配置、存储策略、副本数等参数，以及与其他资源的关联关系。
ServiceMonitor：ServiceMonitor 是一个自定义资源，用于定义要由Prometheus监控的服务和指标。可以指定服务的标签选择器，以便Prometheus可以动态地发现和监控符合条件的服务。
Alertmanager：Alertmanager 自定义资源用于定义Alertmanager实例的配置和规范。可以指定接收告警的通知渠道、告警路由的规则等参数。

Prometheus 资源以声明方式描述了 Prometheus 部署的期望状态，而 ServiceMonitor 和 PodMonitor 资源描述了Prometheus 要监控的目标。

部署测试应用

我们部署一个简单的测试应用，起了 3 个副本，通过8080端口对外映射metrics指标信息。

 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

创建对应的 service 对象。

 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


apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
 name: example-app
 labels:
 team: frontend
spec:
 selector:
 matchLabels:
 app: example-app
 endpoints:
 - port: web

部署 Prometheus

创建RBAC 策略

 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


apiVersion: v1
kind: ServiceAccount
metadata:
 name: prometheus
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: prometheus
rules:
- apiGroups: [""]
 resources:
 - nodes
 - nodes/metrics
 - services
 - endpoints
 - pods
 verbs: ["get", "list", "watch"]
- apiGroups: [""]
 resources:
 - configmaps
 verbs: ["get"]
- apiGroups:
 - networking.k8s.io
 resources:
 - ingresses
 verbs: ["get", "list", "watch"]
- nonResourceURLs: ["/metrics"]
 verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: prometheus
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: prometheus
subjects:
- kind: ServiceAccount
 name: prometheus
 namespace: default

Prometheus自定义资源定义了底层的具体StatefulSet的特性（副本数、资源请求/限制等），同时通过spec.serviceMonitorSelector字段指定应包含哪些ServiceMonitor。

之前我们创建了一个带有team: frontend标签的 ServiceMonitor 对象，现在我们在Prometheus对象中定义，Prometheus应选择所有带有team: frontend标签的ServiceMonitor。这使得前端团队可以创建新的ServiceMonitors和Services，而无需重新配置Prometheus对象。

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


apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
 name: prometheus
spec:
 replicas: 1
 serviceAccountName: prometheus
 serviceMonitorSelector:
 matchLabels:
 team: frontend
 resources:
 requests:
 memory: 400Mi
 enableAdminAPI: false

将对象部署到集群中

1
2


kubectl apply -f prometheus.yaml
kubectl -n default get prometheus prometheus -w

暴露 Prometheus SVC

要访问Prometheus界面，需要将Prometheus服务暴露给外部。为了简单起见，我们可以使用一个NodePort类型的Service来实现。

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


apiVersion: v1
kind: Service
metadata:
 name: prometheus
spec:
 type: NodePort
 ports:
 - name: web
 nodePort: 30900
 port: 9090
 protocol: TCP
 targetPort: web
 selector:
 prometheus: prometheus

附录

metric server vs kube-state-metric vs cAdvisor

Metric Server（指标服务器）：
1. Metric Server是Kubernetes的核心组件之一，用于收集和聚合集群级别的资源利用率指标，如CPU使用率、内存使用量等。
2. Metric Server使用Kubernetes API提供的Metrics API来获取和暴露指标数据，可以通过kubectl命令或API查询这些指标。
3. Metric Server通常用于水平扩展Pod的自动伸缩、资源配额管理和监控集群整体的资源利用率。
kube-state-metrics（Kubernetes 状态指标）KSM：
1. kube-state-metrics 是一个独立的监控工具，用于收集和暴露Kubernetes集群中的各种资源对象的状态指标。
2. kube-state-metrics 通过解析 Kubernetes 的 API 服务器中的资源对象状态，生成与资源对象相关的指标数据，如节点数量、Pod 数量、ReplicaSet 数量等。
3. kube-state-metrics 提供了丰富的资源指标，可以用于监控和告警，以及与 Prometheus 等监控系统集成。
cAdvisor（容器监控代理）：
1. cAdvisor 是一个容器监控代理，用于收集和暴露单个节点上容器级别的资源指标。它是Kubernetes默认集成的监控工具之一。
2. cAdvisor 运行在每个节点上，通过直接与Docker或其他容器运行时交互，收集容器的CPU、内存、磁盘和网络等资源使用情况。
3. cAdvisor 提供了实时的容器级别指标，可以用于监控容器的性能和资源利用情况。

修复 unhealthy target

etcd.yaml

1
2
3


 - --listen-metrics-urls=http://127.0.0.1:2381
 # 修改为 
 - --listen-metrics-urls=http://0.0.0.0:2381

kube-controller-manager.yaml

1
2
3


 - --bind-address=127.0.0.1
# 修改为 
 - --bind-address=0.0.0.0 

kube-scheduler.yaml

1
2
3


 - --bind-address=127.0.0.1
# 修改为 
 - --bind-address=0.0.0.0 

Kube-proxy

kubectl -n kube-system edit cm kube-proxy

1
2
3


 metricsBindAddress: ""
# 修改为 
 metricsBindAddress: "0.0.0.0"

重启 kube-proxy

全栈监控可观测

全栈监控（Full Stack Monitoring）是一种综合性的监控方案，用于收集、分析和可视化应用程序的各个层面和组件的性能和健康状态。它提供了对整个应用程序栈的端到端可见性，包括前端、后端、基础设施和用户体验等方面。

全栈监控旨在帮助开发团队、运维团队和业务团队全面了解应用程序的运行状况，以便及时发现和解决问题，并持续改进应用程序的性能和可用性。通过收集和分析各个组件的监控数据，全栈监控可以提供以下方面的信息：

应用程序性能：全栈监控可以实时监测应用程序的性能指标，例如响应时间、吞吐量、错误率等。这些指标可以帮助识别性能瓶颈和优化机会，从而提升应用程序的效率和用户体验。
用户体验：全栈监控可以跟踪用户在应用程序中的行为和交互，并提供关于用户体验的指标，如页面加载时间、交互延迟等。这些指标可以帮助了解用户对应用程序的满意度，并识别可能影响用户体验的问题。
服务依赖关系：应用程序通常依赖于多个服务和组件。全栈监控可以跟踪这些依赖关系，并提供服务之间的关联性和性能指标。这有助于识别服务之间的依赖问题、故障传播和性能影响。
基础设施监控：全栈监控可以监控应用程序运行所需的基础设施层，包括服务器、数据库、网络等。它可以提供有关基础设施的指标和警报，以确保其正常运行和可用性。
日志和错误跟踪：全栈监控可以收集应用程序的日志和错误信息，并提供对这些信息的分析和可视化。这有助于快速定位和解决应用程序中的错误和异常。

Prometheus on 小杨的博客

19-监控 - kube-prometheus 部署

Prometheus 架构介绍

Prometheus 安装

云原生应用监控

监控数据来源

什么是 ServiceMonitor

监控 example-app 应用

监控 etcd

非云原生应用监控

配置 mysql-exporter

配置 抓取目标

Blackbox 黑盒监控

Prometheus 静态配置

配置告警

路由规则

配置钉钉告警

Prometheus 高可用

19-监控

Metrics Server

Metrics Server Github 地址

部署

验证

HorizontalPodAutoscaler（HPA）

kube-prometheus

组件

Operator

Operator

CR

CRD

Prometheus Operator

安装 Operator

部署测试应用

创建 ServiceMonitor 对象

部署 Prometheus

暴露 Prometheus SVC

附录

metric server vs kube-state-metric vs cAdvisor

修复 unhealthy target

全栈监控 可观测

配置抓取目标

全栈监控可观测