云原生监控Prometheus基本概念

云原生监控Prometheus介绍

一、什么是Prometheus

Prometheus 是一个开源的系统监控和告警工具包。它最初是由 SoundCloud 开发的,目前已经成为云原生计算基金会(CNCF)的第二个毕业项目(仅次于 Kubernetes)。

主要特点包括:

  1. 多维度数据模型
    • 时间序列数据由指标名称和键值对标签组成
    • 支持灵活的查询语言 PromQL
  2. 数据收集
    • 通过 HTTP 协议采用 pull 模型拉取数据
    • 支持 push 网关来接收短期任务的数据推送
    • 支持服务发现和静态配置
  3. 数据存储
    • 使用本地时序数据库存储监控数据
    • 高效的数据压缩算法
    • 支持数据的长期存储
  4. 可视化
    • 内置简单的图形界面
    • 可以与 Grafana 等工具集成实现更强大的可视化
  5. 告警
    • 支持灵活的告警规则配置
    • 通过 Alertmanager 组件统一处理告警

二、Prometheus架构解析

1. Prometheus Server-核心组件

  • 核心功能：Prometheus Server 是整个监控系统的核心，用于从不同的目标（targets）拉取指标数据，存储在时间序列数据库（TSDB）中，并提供查询接口。
  • 主要组件
    • Retrieval：检索模块，负责从配置的监控目标（如 exporters）中定期拉取(pull)指标数据。
    • TSDB（Time Series Database）：时间序列数据库，用于存储拉取到的监控数据。
    • HTTP Server：提供 HTTP API 接口服务 和 Prometheus 查询语言（PromQL）接口，用户和其他服务可以通过它访问数据和执行查询。
  • 数据存储：Prometheus 通过本地磁盘（如 HDD/SSD）来存储数据。

2. Prometheus Targets-数据采集层

  • 定义：Prometheus 通过拉取（pull）的方式从不同的监控目标（Targets）收集数据。Targets 包括各种可以提供 Prometheus 格式指标数据的进程或服务。
  • Jobs 和 Exporters：这些目标可能是应用的实例（称为 Jobs），也可以是特定的 Exporters，如 Node Exporter（收集操作系统数据）或其他第三方导出器。
  • 数据拉取方式：Prometheus Server 定期从这些目标拉取数据，以便获得最新的监控指标。

3. Pushgateway-数据采集层

  • 作用：Pushgateway 用于接收短生命周期任务的指标数据。某些任务可能只运行一次或持续时间很短（例如批处理任务），如果直接被 Prometheus 拉取，可能无法及时捕获这些任务的状态。Pushgateway 允许这些任务在退出时推送数据，保证 Prometheus Server 能拉取到这些数据。
  • 数据流向：短生命周期任务在结束时向 Pushgateway 推送数据，Prometheus Server 再从 Pushgateway 拉取这些数据。

4. Service Discovery-服务发现

支持两种主要的服务发现方式:

  • kubernetes: 自动发现 K8s 集群中的监控目标

  • file_sd: 基于文件的服务发现机制

  • 作用：Prometheus 使用服务发现机制动态发现需要监控的目标。常见的服务发现方式包括 Kubernetes API、静态文件配置（file_sd）等。

  • Kubernetes Integration：对于 Kubernetes 环境，Prometheus 可以直接通过 Kubernetes API 动态发现 Pod、Service 等资源，实现自动化监控。

5. Alertmanager-告警模块

  • 作用：Prometheus 中的 Alertmanager 负责处理由 Prometheus Server 生成的告警。Prometheus 使用预先定义的告警规则来触发告警事件（例如某些指标超过阈值）。
  • 告警推送：Prometheus Server 会根据配置的告警规则将告警推送给 Alertmanager。Alertmanager 负责对告警进行分组、去重、抑制等操作，并根据配置发送到不同的通知渠道。
  • 通知渠道：Alertmanager 可以将告警通过 Email、PagerDuty 或其他集成工具发送给运维团队。

6. 数据可视化与查询接口(图右下部分)

PromQL: Prometheus 的查询语言

  • Prometheus Web UI：Prometheus 自带的 Web UI 提供了一些基本的可视化和查询功能，用户可以通过 PromQL 执行查询，并查看实时数据。
  • Grafana：更高级的可视化需求通常会借助 Grafana，它可以直接查询 Prometheus 数据，并提供丰富的图表选项和可定制的仪表板。
  • API Clients：Prometheus 提供 HTTP API，使得外部应用或脚本可以直接查询 Prometheus 中的数据，以实现自定义分析或集成需求。

7. 数据流向总结

Pull 模式:

  • Prometheus server 主动从 targets 拉取数据
  • 从 Pushgateway 拉取短期任务的数据
  • Pull 模式：Prometheus 的默认数据采集模式是从 Targets 拉取数据，Prometheus Server 定期访问每个目标的 HTTP 指标端点，获取并存储指标。

Push 模式:

  • 短期任务推送数据到 Pushgateway

  • Prometheus server 推送告警到 Alertmanager

  • Push 模式（Pushgateway）：对于短生命周期任务，通过 Pushgateway 推送数据。Pushgateway 存储这些数据，供 Prometheus Server 拉取。

告警流：

  • Prometheus Server 通过配置的告警规则触发告警事件，将其推送给 Alertmanager。Alertmanager 处理告警并发送给指定的通知系统（如 Email、PagerDuty）。

总结

Prometheus 架构的关键在于「拉取模式」的数据采集、「时间序列数据库」的数据存储、「告警管理」的处理方式和「数据可视化」的整合。这个设计使得 Prometheus 在云原生环境中具备了高效、自动化、动态监控的能力，并且与 Kubernetes 等系统无缝集成。

三、Prometheus常见的自定义资源

在 Kubernetes 环境中部署 Prometheus 时，常见的自定义资源（CRD，Custom Resource Definitions）通常是 Prometheus Operator 提供的。它们主要是为了让 Prometheus 在 K8s 上能自动化地配置和管理，而不是让你每次都手动写繁琐的配置文件。

  1. Prometheus：定义并部署一个或多个 Prometheus 实例，也就是监控系统本身。
  2. Alertmanager：定义并部署 Alertmanager 实例，他负责接受Prometheus 发送的告警，并根据规则将告警通过钉钉、邮件、企业微信等通知到相关人员。
  3. ServiceMonitor：告诉 Prometheus “去监控这个 Service 的指标”，只适用于 Kubernetes 内部服务。
  4. PodMonitor：与 ServiceMonitor 类似，当服务没有 Service（比如直接通过 Pod IP 访问），就用它来监控单个 Pod。
  5. Probe：通常用于定义监控静态目标，和BlackBox Exporter配合使用，监控官网是否能访问。
  6. ScrapeConfig：用于自定义监控目标，通常用于抓取Prometheus集群外部的目标数据。
  7. AlertmanagerConfig：用于定义Alertmanager 的配置，告诉 Alertmanager 如何处理告警（路由、分组、抑制规则等）。
  8. PrometheusRule：定义告警规则，也就是告诉 Prometheus “什么时候该报警”（比如阈值、持续时间）。

1.Prometheus资源配置详解

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
62
63
64
65
66
67
68
69
70
71
apiVersion: monitoring.coreos.com/v1  # Prometheus Operator的API版本
kind: Prometheus  # 资源类型，定义一个Prometheus实例
metadata: 
  name: prometheus  # Prometheus实例的名称
  namespace: monitoring  # 部署的命名空间
spec: 
  replicas: 3  # Prometheus实例副本数，用于高可用
  image: quay.io/prometheus/prometheus:v3.1.0  # 指定Prometheus镜像版本
  
  # 服务账户配置（必需）
  serviceAccountName: prometheus  # 指定运行Prometheus Pod使用的ServiceAccount
  
  # 告警管理器配置
  alerting: 
    alertmanagers: 
    - namespace: monitoring  # Alertmanager所在的命名空间
      name: alertmanager-main  # Alertmanager服务的名称
      apiVersion: v2  # Alertmanager API版本
      port: web  # 连接Alertmanager的端口名称（通常是9093）
  
  # 资源限制配置
  resources: 
    requests:  # 最小资源请求，用于Pod调度
      memory: 400Mi  # 最小内存需求
      cpu: 100m  # 最小CPU需求（0.1核）
    limits:  # 最大资源限制，防止资源过度使用
      memory: 800Mi  # 最大内存限制
      cpu: 200m  # 最大CPU限制（0.2核）
  
  # 节点选择器（已修正为新标签）
  nodeSelector: 
    kubernetes.io/os: linux  # 仅在Linux节点上调度Pod
  
  # 持久化存储配置
  storage: 
    volumeClaimTemplate:  # 动态创建PVC的模板
      spec: 
        storageClassName: fast-ssd  # 存储类名称，通常指向SSD存储
        resources: 
          requests: 
            storage: 20Gi  # 每个副本请求的存储空间大小
  
  # 监控目标选择器配置（新增必需字段）
  serviceMonitorSelector:  # 选择要监控的ServiceMonitor资源
    matchLabels:
      app: prometheus  # 选择带有此标签的ServiceMonitor
  
  podMonitorSelector:  # 选择要监控的PodMonitor资源
    matchLabels:
      app: prometheus  # 选择带有此标签的PodMonitor
  
  ruleSelector:  # 选择要加载的PrometheusRule资源
    matchLabels:
      app: prometheus  # 选择带有此标签的PrometheusRule
  
  # 安全上下文配置（推荐添加）
  securityContext:
    fsGroup: 2000  # 设置文件系统组ID，确保存储权限正确
    runAsNonRoot: true  # 以非root用户运行，提高安全性
    runAsUser: 1000  # 指定运行用户ID
  
  # 数据保留配置（推荐添加）
  retention: "30d"  # 数据保留时间，30天后自动删除旧数据
  retentionSize: "15GB"  # 数据保留大小限制，超出后删除最老数据
  
  # 外部访问配置（可选）
  portName: web  # 服务端口名称
  
  # 配置重载间隔（可选）
  evaluationInterval: 30s  # 规则评估间隔
  scrapeInterval: 30s  # 默认抓取间隔

2.Alertmanager资源配置详解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: monitoring.coreos.com/v1   # CRD 版本，由 Prometheus Operator 定义
kind: Alertmanager                     # 声明资源类型是 Alertmanager
metadata:
  name: alertmanager                   # Alertmanager 实例的名字
  namespace: monitoring                # 部署在哪个命名空间
  labels:                              # 附加标签，便于选择器和管理
    app: alertmanager                  # 自定义标签，用来标识资源类型
    app.kubernetes.io/name: alertmanager   # 语义化应用名（Kubernetes 推荐规范标签）
    app.kubernetes.io/component: alerting  # 组件角色，这里是告警模块
    app.kubernetes.io/part-of: monitoring  # 所属系统，这里是监控系统
    app.kubernetes.io/instance: k8s        # 实例名，表示该应用隶属于哪个实例
    app.kubernetes.io/version: 0.23.0      # 版本号，标注该实例运行的版本
spec:
  replicas: 3                         # 部署副本数，通常配置为 2~3，保证高可用
  image: quay.io/prometheus/alertmanager:v0.23.0  # 使用的镜像地址（不推荐，建议用 version 字段）
  # version: v0.23.0                  # 推荐写法，Operator 会自动拼接 quay.io/prometheus/alertmanager:v0.23.0
  nodeSelector:                        # 节点选择器，用来约束 Pod 部署在哪类节点
    kubernetes.io/os: linux            # 运行在 Linux 节点（k8s 推荐标签）

3.ServiceMonitor资源配置详解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: monitoring.coreos.com/v1   # CRD 版本，由 Prometheus Operator 定义
kind: ServiceMonitor                   # 定义 ServiceMonitor 资源，用来发现并采集服务的监控指标
metadata:
  name: grafana-monitor                # ServiceMonitor 的名字
  namespace: monitoring                 # 所属命名空间（不必须和应用一致，只要 Prometheus 能选中即可），建议和被监控的应用所在的命名空间一致，例如你要监控的应用在prod命名空间下，那么这里也应该是prod命名空间。
  labels:                               # 附加标签，用于 Prometheus 的 serviceMonitorSelector 选择
    app.kubernetes.io/name: servicemonitor       # 资源类型标识
    app.kubernetes.io/component: microservice-monitor # 表示该监控对象属于微服务监控组件
    app.kubernetes.io/part-of: monitoring        # 所属系统（监控体系）
    app.kubernetes.io/version: 1.0.0             # 版本号，方便管理
spec:
  selector:                           # 用来选择目标 Service
    matchLabels:                      # 选择带有这些 label 的 Service
      app.kubernetes.io/name: grafana # 目标 Service 的标签（需要和应用 Service 的 labels 对应）
  endpoints:                          # 定义如何采集指标
    - port: app-metrics               # Service 暴露的端口名（必须和 Service spec.ports[].name 对应）
      path: /actuator/prometheus      # 指标暴露路径（Spring Boot 应用常用 /actuator/prometheus）
      interval: 30s                   # 抓取间隔，Prometheus 每 30 秒采集一次
      scrapeTimeout: 10s              # 抓取超时时间，超过 10 秒就放弃

4.PodMonitor资源配置详解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: monitoring.coreos.com/v1       # CRD 版本，由 Prometheus Operator 定义
kind: PodMonitor                           # 定义 PodMonitor 资源，用于直接监控 Pod
metadata:
  name: myapp-pod-monitor                  # PodMonitor 的名字
  namespace: monitoring                    # PodMonitor 所在命名空间
  labels:                                  # 附加标签，供 Prometheus 的 podMonitorSelector 选择
    app.kubernetes.io/name: podmonitor
    app.kubernetes.io/component: app-metrics
    app.kubernetes.io/part-of: monitoring
    app.kubernetes.io/version: 1.0.0
spec:
  selector:                                # 选择哪些 Pod 需要被监控
    matchLabels:                           # 根据标签筛选目标 Pod
      app: myapp                           # 例如只监控标签为 app=myapp 的 Pod
  namespaceSelector:                       # 命名空间选择器，决定在哪些命名空间里找 Pod
    matchNames:                            # 只在以下命名空间中查找
      - prod                               # 只监控 prod 命名空间里的 Pod
  podMetricsEndpoints:                     # 定义如何从 Pod 里采集指标
    - port: metrics                        # Pod 容器暴露的端口名（必须和容器 spec.ports[].name 对应）
      path: /metrics                       # 指标暴露路径（Prometheus 默认路径是 /metrics）
      interval: 30s                        # 抓取间隔，每 30 秒采集一次
      scrapeTimeout: 10s                   # 超时时间，超过 10 秒则放弃
      scheme: http                         # 协议，可以是 http 或 https

5.Probe

在 Prometheus Operator 中，Probe 用来监控非 K8s Service 的目标，例如外部 HTTP 服务、TCP 端口探活等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: monitoring.coreos.com/v1  #指定 CRD 的版本，这里是 monitoring.coreos.com/v1。
kind: Probe                           #定义资源类型，这里是 Probe。 
metadata:               #定义资源的元数据
  name: external-probe-example          # Probe 资源名称，方便区分
  namespace: monitoring                 # Probe 所在的命名空间
  labels:                               # 标签，用于选择和标识
    app.kubernetes.io/name: probe
    app.kubernetes.io/component: monitoring
    app.kubernetes.io/part-of: prometheus
spec:
  jobName: probe-external-example       # 定义探测任务名称，用于区分不同探测任务
  interval: 30s                         # 探测间隔，每隔 30 秒执行一次探测
  scrapeTimeout: 10s                    # 超时时间，超过 10 秒未响应则视为失败
  prober:                               # 定义探测器（prober）本身信息，负责执行探测
    url: http://blackbox-exporter.monitoring.svc:9115  # blackbox-exporter 服务地址
    scheme: http                        # 使用的协议（http/https）
  module: http_2xx                      # 使用 blackbox-exporter 的模块（定义探测方式）
  targets:                              # 目标配置
    staticConfig:                       # 静态配置（支持 ServiceMonitor/PodMonitor 动态发现）
      static:                           # 静态目标列表
        - https://www.google.com        # 被探测的目标 1
        - https://www.github.com        # 被探测的目标 2

在 Prometheus Operator 中，一个 Probe 只能对应 一个探测任务（它只有一个 prober、一个 module）。
所以如果想同时探测 HTTP 服务 和 TCP 端口（比如 Redis、MySQL），需要为它们分别定义 多个 Probe 资源。

示例：增加 Redis 和 MySQL 的探测

需要写 3 个探测任务：

  • HTTP 探测（外部网站）
  • Redis 探测（TCP 6379 端口）
  • MySQL 探测（TCP 3306 端口）
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
62
63
64
65
66
67
68
# ================================
# 1. HTTP 探测（外部网站）
# ================================
apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
  name: probe-http-external
  namespace: monitoring
spec:
  jobName: probe-http-external
  interval: 30s
  scrapeTimeout: 10s
  prober:
    url: blackbox-exporter.monitoring.svc:9115   # 注意这里不要写 /probe，operator 会自动拼接
    scheme: http
  module: http_2xx
  targets:
    staticConfig:
      static:
        - https://www.google.com
        - https://www.github.com

---
# ================================
# 2. Redis 探测（TCP 6379）
# ================================
apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
  name: probe-redis
  namespace: monitoring
spec:
  jobName: probe-redis
  interval: 30s
  scrapeTimeout: 5s
  prober:
    url: blackbox-exporter.monitoring.svc:9115
    scheme: http
  module: tcp_connect                 # 使用 blackbox-exporter 的 tcp_connect 模块
  targets:
    staticConfig:
      static:
        - redis-service.default.svc.cluster.local:6379  # 集群内 Redis 地址
        - 192.168.1.10:6379                              # 外部 Redis 地址

---
# ================================
# 3. MySQL 探测（TCP 3306）
# ================================
apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
  name: probe-mysql
  namespace: monitoring
spec:
  jobName: probe-mysql
  interval: 30s
  scrapeTimeout: 5s
  prober:
    url: blackbox-exporter.monitoring.svc:9115
    scheme: http
  module: tcp_connect                 # 同样用 tcp_connect
  targets:
    staticConfig:
      static:
        - mysql-service.default.svc.cluster.local:3306  # 集群内 MySQL 地址
        - 192.168.1.20:3306                              # 外部 MySQL 地址

6.ScrapeConfig

ScrapeConfig 和 ServiceMonitor / PodMonitor 的区别在于：

  • ServiceMonitor / PodMonitor / Probe → 针对 Kubernetes 应用、Pod、外部探测，算是“高级抽象”。
  • ScrapeConfig → 原生 Prometheus 的 scrape_configs 的 CRD 版本，灵活度高，可以配置任何 Prometheus 支持的采集方式（包括文件发现、Consul、静态目标等）。
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
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
# Kubernetes API 版本，指定使用 Prometheus Operator 的 ScrapeConfig CRD
apiVersion: monitoring.coreos.com/v1alpha1   

# 资源类型：ScrapeConfig 是 Prometheus Operator 提供的自定义资源
# 用于定义 Prometheus 如何抓取指标数据
kind: ScrapeConfig                           

# 资源元数据配置
metadata:
  # ScrapeConfig 资源的唯一名称标识符
  name: redis-exporter-scrape                
  
  # 部署的命名空间，通常监控相关资源放在 monitoring 命名空间
  namespace: monitoring                     
  
  # 标签用于资源分类和选择器匹配
  labels:
    # 应用程序名称标签，遵循 Kubernetes 推荐标签规范
    app.kubernetes.io/name: scrapeconfig
    # 组件标签，标识这是监控组件
    app.kubernetes.io/component: monitoring
    # 所属系统标签，表明这是 Prometheus 监控系统的一部分
    app.kubernetes.io/part-of: prometheus

# ScrapeConfig 的具体配置规范
spec:
  # Prometheus 中的 job 名称，用于在指标中标识数据来源
  # 所有从此配置抓取的指标都会带上 job="redis-exporter" 标签
  jobName: redis-exporter                    
  
  # 抓取间隔：每 30 秒向目标发起一次指标抓取请求
  # 较短的间隔提供更高的监控精度，但增加网络和存储开销
  scrapeInterval: 30s                       
  
  # 抓取超时时间：单次抓取请求的最大等待时间
  # 超过此时间未响应则认为抓取失败，应小于 scrapeInterval
  scrapeTimeout: 10s                        
  
  # 是否保留目标服务原有的标签
  # true：保留目标暴露的所有原始标签，避免 Prometheus 自动添加的标签覆盖
  honorLabels: true                         
  
  # 请求协议：使用 HTTP 协议抓取指标
  # 可选值：http, https
  scheme: http                              
  
  # 指标端点路径：Redis Exporter 暴露指标的 URL 路径
  # Redis Exporter 通常使用 /scrape 而不是标准的 /metrics
  metricsPath: /scrape                   
  
  # 静态目标配置：手动指定要监控的目标列表
  staticConfigs:    
    # 目标配置组
    - targets:
        # Redis 服务地址：使用 Redis 协议连接到 default 命名空间的 redis 服务的 6379 端口
        # 这里是 Redis 实例的连接字符串，不是 HTTP 端点
        - redis://redis.default:6379        
      
      # 为此目标组添加的静态标签
      # 这些标签会附加到所有从该目标抓取的指标上
      labels:                              
        # 环境标签：标识为生产环境
        env: prod
        # 导出器类型标签：标识使用的是 redis exporter
        exporter: redis
  
  # 重新标签配置：在抓取前修改目标的标签
  # 这是实现间接抓取模式的关键配置
  relabelings:     
    # 规则1：将原始目标地址传递给 exporter
    # 将 __address__ (redis://redis.default:6379) 复制到 __param_target 参数中
    # Redis Exporter 通过 target 参数知道要连接哪个 Redis 实例
    - sourceLabels: [__address__]           
      targetLabel: __param_target            
    
    # 规则2：设置实例标签
    # 将 __param_target 的值设置为 instance 标签，用于在监控中识别具体的 Redis 实例
    - sourceLabels: [__param_target]
      targetLabel: instance
    
    # 规则3：重定向抓取目标
    # 将实际的抓取地址改为 Redis Exporter 服务地址
    # Prometheus 实际会向 redis-exporter.monitoring:9121 发送请求
    - targetLabel: __address__
      replacement: redis-exporter.monitoring:9121  

# 工作流程说明：
# 1. Prometheus 读取此配置，发现目标 redis://redis.default:6379
# 2. 经过 relabeling，实际请求变成：
#    GET http://redis-exporter.monitoring:9121/scrape?target=redis://redis.default:6379
# 3. Redis Exporter 收到请求后连接到指定的 Redis 实例，获取指标并返回
# 4. Prometheus 将获取的指标存储，并添加 job="redis-exporter" 等标签

# 这种间接抓取模式的优势：
# - 一个 Redis Exporter 实例可以监控多个 Redis 实例
# - 无需为每个 Redis 实例部署独立的 exporter
# - 便于集中管理和配置监控目标

7.AlertmanagerConfig

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: monitoring.coreos.com/v1alpha1   # CRD 的 API 版本
kind: AlertmanagerConfig                     # 定义资源类型，这里是 AlertmanagerConfig
metadata:
  name: alertmanager-config-example          # 配置资源名称
  namespace: monitoring                      # 命名空间，需要和 Alertmanager 实例相同
spec:
  route:                                     # 根路由配置，定义告警的匹配和分发规则
    receiver: default-receiver               # 默认接收器（未匹配到时使用）
    groupBy: ['alertname', 'severity']       # 按这些标签对告警进行分组
    groupWait: 30s                           # 告警分组后，等待 30 秒再发送（用于收集更多告警一起发）
    groupInterval: 5m                        # 同一个分组内新告警间隔至少 5 分钟再发送一次
    repeatInterval: 3h                       # 已经发送的告警，如果仍未恢复，3 小时后重新提醒一次
    routes:                                  # 子路由（可以针对不同条件做不同处理）
      - matchers:                            # 匹配规则
          - name: severity
            value: critical
            matchType: =
        receiver: critical-receiver          # 匹配 severity=critical 的告警发到 critical-receiver
        continue: false                      # 不继续往下匹配，匹配到就结束

  receivers:                                 # 定义告警接收器（通知方式）
  - name: default-receiver
    emailConfigs:                            # 邮件通知配置
    - to: ops-team@example.com               # 收件人邮箱
      from: alertmanager@example.com         # 发件人邮箱
      smarthost: smtp.example.com:587        # 邮件服务器地址和端口
      authUsername: alertmanager@example.com # SMTP 登录用户名
      authPassword:
        name: smtp-secret                    # 从 Secret 获取密码
        key: password

  - name: critical-receiver
    webhookConfigs:                          # Webhook 通知配置
    - url: 'http://alert-webhook-service.monitoring.svc:8080/'  # Webhook 地址
      sendResolved: true                     # 当告警恢复时也发送通知

8.PrometheusRule

PrometheusRule 是 Prometheus Operator 提供的一种 CRD，用于集中管理告警规则（alerting rules）和录制规则（recording rules）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: monitoring.coreos.com/v1  # CRD 的 API 版本
kind: PrometheusRule                  # 资源类型，PrometheusRule 表示规则集合
metadata:
  name: example-prometheus-rules      # 规则名称
  namespace: monitoring               # 命名空间（通常和 Prometheus 实例在一起）
  labels:                             # 标签，用于选择和管理
    role: alert-rules
    prometheus: k8s
spec:
  groups:                             # 规则分组，可以有多个
  - name: example.rules               # 分组名称，逻辑上的分组单位
    interval: 30s                     # 执行规则的间隔，覆盖 Prometheus 全局设置
    rules:                            # 规则列表
    - alert: HighErrorRate             # 告警规则（Alerting Rule）名称
      expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05  
      # 表达式，计算过去 5 分钟的 5xx 错误率是否大于 5%
      for: 10m                         # 条件成立持续 10 分钟才触发告警
      labels:                          # 给告警打标签
        severity: warning
      annotations:                     # 附加说明（展示在告警系统中）
        summary: "High error rate detected"
        description: "More than 5% of requests are failing with 5xx errors on {{ $labels.job }} for 10m."

9.Prometheus资源分类

安装：Operator、Prometheus、Alertmanager、Grafana

监控：ServiceMonitor、Probe、PodMonitor、ScrapeConfig

告警：PrometheusRule

通知：AlertmanagerConfig