Prometheus Operator学习

参考文档视频

https://www.bilibili.com/video/BV194421U7Sn/?spm_id_from=333.1387.collection.video_card.click&vd_source=0372d3f32c3f19a6a2676a7529d6698a

https://www.bilibili.com/video/BV13Q4y1C7hS?spm_id_from=333.788.videopod.episodes&vd_source=0372d3f32c3f19a6a2676a7529d6698a&p=183

https://github.com/prometheus-operator/kube-prometheus

Prometheus Operator 介绍及其主要组件

Prometheus Operator 是一个基于 Kubernetes 自定义资源（CRD）的工具，旨在简化 Prometheus 及其相关监控组件在 Kubernetes 集群中的部署、配置和管理。它通过声明式 API 实现监控栈的自动化运维，大幅降低了传统手动配置 Prometheus 的复杂度。

一、Prometheus Operator 的核心作用

自动化部署：通过自定义资源定义（CRD）声明 Prometheus 服务器、告警规则、服务发现等，Operator 自动完成对应资源的创建和更新。
动态配置：当监控目标（如 Pod、Service）在 Kubernetes 中发生变化时，Operator 自动更新 Prometheus 配置，无需手动修改 prometheus.yml。
高可用支持：支持部署 Prometheus 集群（多副本），并通过持久化存储确保数据不丢失。
生命周期管理：自动处理 Prometheus 版本升级、配置滚动更新等操作，减少人工干预。

二、主要组件及自定义资源（CRD）

Prometheus Operator 核心通过以下自定义资源（CRD）实现监控栈的管理，每个资源对应特定的功能：

1. Prometheus 资源

Prometheus 是最核心的 CRD，用于定义一个 Prometheus 服务器实例的部署配置。

作用：声明 Prometheus 服务器的规格，包括副本数、存储配置、资源限制、监控目标选择等。

关键配置示例：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: example-prometheus
  namespace: monitoring
spec:
  replicas: 2  # 高可用副本数
  retention: 15d  # 数据保留时间
  storageSpec:  # 持久化存储配置
    volumeClaimTemplate:
      spec:
        storageClassName: standard
        resources:
          requests:
            storage: 100Gi
  serviceAccountName: prometheus  # 权限账号
  serviceMonitorSelector:  # 选择要监控的 ServiceMonitor
    matchLabels:
      team: frontend

 

2. ServiceMonitor 资源

ServiceMonitor 用于定义 Prometheus 如何发现和监控 Kubernetes 中的 Service 及其后端 Pod。

作用：通过标签选择器匹配目标 Service，自动生成 Prometheus 的 scrape_configs（抓取配置），无需手动编写服务发现规则。

关键配置示例：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: frontend-monitor
  namespace: monitoring
  labels:
    team: frontend  # 被 Prometheus 资源的 serviceMonitorSelector 匹配
spec:
  selector:  # 匹配目标 Service 的标签
    matchLabels:
      app: frontend
  namespaceSelector:  # 限定监控的命名空间（可选）
    matchNames:
      - app-namespace
  endpoints:  # 抓取目标的端口和路径
    - port: web  # 对应 Service 中定义的端口名
      path: /metrics  #  metrics 暴露路径
      interval: 30s  # 抓取间隔

 

3. PodMonitor 资源

PodMonitor 与 ServiceMonitor 类似，但直接针对 Pod 进行监控（不依赖 Service），适用于无 Service 暴露的 Pod 场景。

作用：通过标签选择器匹配目标 Pod，定义抓取规则（如端口、路径、间隔等）。
适用场景：需要直接监控 Pod 内部 metrics（如 DaemonSet 部署的节点监控组件）。

4. PrometheusRule 资源

PrometheusRule 用于定义 Prometheus 的告警规则和记录规则（Recording Rule）。

作用：替代传统 Prometheus 中手动编写的 rules.yml，通过声明式配置管理告警逻辑，Operator 会自动将规则同步到 Prometheus 服务器。

关键配置示例：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: high-cpu-alert
  namespace: monitoring
  labels:
    prometheus: example-prometheus  # 关联到对应的 Prometheus 实例
spec:
  groups:
  - name: cpu-alerts
    rules:
    - alert: HighCPUUsage
      expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) > 0.8
      for: 5m  # 持续5分钟触发告警
      labels:
        severity: critical
      annotations:
        summary: "Instance {{ $labels.instance }} high CPU usage"

 

5. Alertmanager 资源

Alertmanager 用于定义 Alertmanager 实例的部署配置，负责处理 Prometheus 发送的告警信息（如去重、分组、路由到邮件 / 钉钉等接收端）。

作用：声明 Alertmanager 的副本数、存储、配置等，Operator 自动部署并关联 Prometheus。

关键配置示例：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  name: example-alertmanager
  namespace: monitoring
spec:
  replicas: 3  # 高可用副本数
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: standard
        resources:
          requests:
            storage: 10Gi
  configSecret: alertmanager-config  # 引用存储告警路由配置的 Secret

 

6. ThanosRuler 资源（可选）

ThanosRuler 是与 Thanos 集成的组件，用于集中管理跨 Prometheus 集群的告警规则和记录规则，适用于大规模监控场景。

作用：替代单个 Prometheus 的 PrometheusRule，实现多集群统一告警规则管理。

三、Operator 控制器本身

除了上述 CRD，Prometheus Operator 核心组件是一个 控制器进程，部署在 Kubernetes 集群中（通常以 Deployment 形式运行）。

作用：监听上述 CRD 资源的创建、更新、删除事件，根据声明的规格（Spec）自动协调实际状态（Status），例如：
- 当创建 Prometheus 资源时，控制器会生成对应的 StatefulSet、Service 等资源。
- 当 ServiceMonitor 更新时，控制器会自动更新 Prometheus 的 scrape_configs 并热加载配置。

四、总结

Prometheus Operator 通过自定义资源将监控栈的配置 “Kubernetes 化”，核心组件关系如下：

Prometheus：监控数据采集和存储的核心服务。
ServiceMonitor/PodMonitor：定义监控目标和抓取规则。
PrometheusRule：定义告警和记录规则。
Alertmanager：处理和路由告警。
Operator 控制器：协调所有组件的生命周期，确保实际状态与声明一致。

这种架构使得在 Kubernetes 中管理 Prometheus 监控栈更高效、可扩展，尤其适合大规模集群或多团队协作场景。

问题一：PrometheusRule 如何跟 alert manager 关联？

回答一：

PrometheusRule 与 Alertmanager 的关联是通过 Prometheus 作为中间桥梁实现的。具体流程如下：

一、关联流程概述

plaintext
 
PrometheusRule → Prometheus → Alertmanager

PrometheusRule：定义告警规则（如 CPU 使用率超过 80% 触发告警）。
Prometheus：执行规则，当条件满足时生成告警，并发送到配置的 Alertmanager。
Alertmanager：接收告警，进行去重、分组、路由，并发送通知（邮件、钉钉等）。

二、关键配置步骤

1. PrometheusRule 配置（定义告警规则）

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: example-rules
  namespace: monitoring
  labels:
    prometheus: example-prometheus  # 与 Prometheus 资源的 selector 匹配
spec:
  groups:
  - name: example
    rules:
    - alert: HighCPUUsage
      expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance) > 0.8
      for: 5m  # 持续 5 分钟触发告警
      labels:
        severity: warning  # 标签用于 Alertmanager 路由
      annotations:
        summary: "Instance {{ $labels.instance }} CPU usage is high"

 

2. Prometheus 配置（关联 Alertmanager）

在 Prometheus 资源中指定 Alertmanager 地址：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: example-prometheus
  namespace: monitoring
spec:
  replicas: 2
  alerting:
    alertmanagers:
    - name: alertmanager-example  # Alertmanager 服务名称
      namespace: monitoring
      port: web  # 端口名
      pathPrefix: "/"
  ruleSelector:  # 选择要加载的 PrometheusRule
    matchLabels:
      prometheus: example-prometheus

 

3. Alertmanager 配置（定义路由和接收器）

通过 configSecret 引用包含 Alertmanager 配置的 Secret：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  name: example-alertmanager
  namespace: monitoring
spec:
  replicas: 3
  configSecret: alertmanager-config  # 引用 Secret

 

创建包含路由规则的 Secret（示例 alertmanager-config.yaml）：

yaml
 
 

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  namespace: monitoring
data:
  alertmanager.yaml: |
    global:
      resolve_timeout: 5m
    route:
      group_by: ['alertname', 'severity']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 12h
      receiver: 'default'
      routes:
      - match:  # 根据 PrometheusRule 中的 labels 匹配
          severity: critical
        receiver: 'pagerduty'
    receivers:
    - name: 'default'
      email_configs:
      - to: 'monitoring@example.com'
    - name: 'pagerduty'
      pagerduty_configs:
      - routing_key: <key>

 

三、验证关联是否成功

1. 检查 Prometheus 是否加载了规则

访问 Prometheus UI（通常通过 kubectl port-forward）：

bash
 
kubectl port-forward -n monitoring svc/prometheus-example 9090:9090

打开浏览器 http://localhost:9090/rules，查看是否显示 PrometheusRule 中定义的规则。

2. 检查 Alertmanager 是否接收到告警

访问 Alertmanager UI：

bash
 
kubectl port-forward -n monitoring svc/alertmanager-example 9093:9093

打开浏览器 http://localhost:9093/#/alerts，查看是否有触发的告警。

3. 测试告警触发

手动触发告警（如通过修改规则阈值），验证 Alertmanager 是否收到并正确路由。

四、常见问题排查

1. 告警未触发

检查 PrometheusRule 中的表达式是否正确（可在 Prometheus UI 中测试）。
确认 PrometheusRule 的 labels 与 Prometheus 的 ruleSelector 匹配。

2. 告警未到达 Alertmanager

检查 Prometheus 的日志，确认是否有发送告警的记录。

检查 Alertmanager 服务是否正常运行：

bash
 
kubectl get pods -n monitoring | grep alertmanager

3. Alertmanager 未发送通知

检查 Alertmanager 配置（alertmanager.yaml）是否正确。
确认接收器（如邮件、PagerDuty）配置无误。

五、总结

PrometheusRule 与 Alertmanager 的关联通过以下步骤完成：

PrometheusRule 定义告警规则并添加标签（如 severity: critical）。
Prometheus 通过 alerting.alertmanagers 指定 Alertmanager 地址，并通过 ruleSelector 加载规则。
Alertmanager 通过 route.routes.match 匹配告警标签，实现不同级别告警的差异化处理。

这种分层设计使规则定义、告警生成和通知发送解耦，便于管理和扩展。

问题二：prometheus 和 serviceMonitor 如果运行在不同的namespace里，如何监控？

回答二：

当 Prometheus 和 ServiceMonitor 运行在不同的命名空间时，需要通过以下配置实现跨命名空间监控：

一、核心配置方法

1. 在 Prometheus 中配置跨命名空间选择器

在 Prometheus 资源中添加 namespaceSelector，允许从其他命名空间发现 ServiceMonitor：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: monitoring  # Prometheus 所在命名空间
spec:
  serviceMonitorNamespaceSelector:  # 允许监控的命名空间
    matchNames:
      - apps  # ServiceMonitor 所在命名空间
  serviceMonitorSelector:
    matchLabels:
      team: frontend  # 匹配 ServiceMonitor 的标签

 

2. 在 ServiceMonitor 中指定正确的服务引用

确保 ServiceMonitor 正确引用目标服务（需包含命名空间信息）：

yaml
 
 

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: frontend-monitor
  namespace: apps  # ServiceMonitor 所在命名空间
  labels:
    team: frontend  # 被 Prometheus 选择的标签
spec:
  selector:
    matchLabels:
      app: frontend
  namespaceSelector:
    matchNames:
      - apps  # 目标服务所在命名空间
  endpoints:
    - port: metrics  # 服务暴露的端口名
      path: /metrics

 

二、权限配置（关键！）

Prometheus 服务账户需要被授权访问其他命名空间的资源。通过 ClusterRoleBinding 扩展权限：

yaml
 
 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-crb  # 自定义名称
subjects:
  - kind: ServiceAccount
    name: prometheus  # Prometheus 使用的 ServiceAccount 名称
    namespace: monitoring  # Prometheus 所在命名空间
roleRef:
  kind: ClusterRole
  name: prometheus  # 使用已有的 Prometheus ClusterRole
  apiGroup: rbac.authorization.k8s.io

 

三、验证配置

1. 检查 Prometheus 是否发现了 ServiceMonitor

通过 Prometheus UI 查看：

bash
 
kubectl port-forward -n monitoring svc/prometheus 9090:9090

访问 http://localhost:9090/targets，确认目标服务出现在监控列表中。

2. 查看 Prometheus 配置

检查 Prometheus 自动生成的抓取配置：

bash
 
kubectl exec -n monitoring <prometheus-pod> -- cat /etc/prometheus/config_out/prometheus.env.yaml

确认其中包含来自其他命名空间的 scrape_configs。

四、常见问题与解决方案

1. Prometheus 未发现跨命名空间的 ServiceMonitor

原因：未配置 serviceMonitorNamespaceSelector 或标签不匹配。

解决方案：

yaml
 
spec:
  serviceMonitorNamespaceSelector:
    any: true  # 允许从所有命名空间发现
  # 或使用 matchNames 指定具体命名空间

2. 权限不足错误

错误信息："error":"Get \"http://<service-ip>/metrics\": dial tcp: permission denied"
解决方案：确保通过 ClusterRoleBinding 授予 Prometheus 跨命名权限（见步骤二）。

五、最佳实践

使用标签筛选：在 serviceMonitorSelector 中使用标签过滤，避免监控无关的 ServiceMonitor。
最小权限原则：仅授予 Prometheus 访问必要命名空间的权限，而非 any: true。
监控跨命名空间依赖：通过 Prometheus 监控 ServiceMonitor 资源本身的状态，确保配置生效。

通过以上配置，Prometheus 可以有效监控不同命名空间中的服务，实现灵活的多团队、多环境监控隔离。

posted @ 2025-07-10 12:18 呆瓜小贼66 阅读(88) 评论(0) 收藏举报

刷新页面返回顶部

呆瓜小贼66

Prometheus Operator学习

Prometheus Operator 介绍及其主要组件

一、Prometheus Operator 的核心作用

二、主要组件及自定义资源（CRD）

1. Prometheus 资源

2. ServiceMonitor 资源

3. PodMonitor 资源

4. PrometheusRule 资源

5. Alertmanager 资源

6. ThanosRuler 资源（可选）

三、Operator 控制器本身

四、总结

问题一：PrometheusRule 如何跟 alert manager 关联？

回答一：

一、关联流程概述

二、关键配置步骤

1. PrometheusRule 配置（定义告警规则）

2. Prometheus 配置（关联 Alertmanager）

3. Alertmanager 配置（定义路由和接收器）

三、验证关联是否成功

1. 检查 Prometheus 是否加载了规则

2. 检查 Alertmanager 是否接收到告警

3. 测试告警触发

四、常见问题排查

1. 告警未触发

2. 告警未到达 Alertmanager

3. Alertmanager 未发送通知

五、总结

问题二：prometheus 和 serviceMonitor 如果运行在不同的namespace里，如何监控？

回答二：

一、核心配置方法

1. 在 Prometheus 中配置跨命名空间选择器

2. 在 ServiceMonitor 中指定正确的服务引用

二、权限配置（关键！）

三、验证配置

1. 检查 Prometheus 是否发现了 ServiceMonitor

2. 查看 Prometheus 配置

四、常见问题与解决方案

1. Prometheus 未发现跨命名空间的 ServiceMonitor

2. 权限不足错误

五、最佳实践

公告