kube-prometheus-stack 核心组件原理解析

在 Kubernetes 生态系统中，监控是一个至关重要的组成部分。kube-prometheus-stack 作为 Prometheus 在 Kubernetes 上的标准部署方案，通过 Prometheus Operator 提供了一套完整的监控解决方案。本文将深入解析 kube-prometheus-stack 中的核心组件，特别是 ServiceMonitor、PodMonitor、Probe 等自定义资源的原理和工作机制。

一、kube-prometheus-stack 概述

kube-prometheus-stack 是一个用于在 Kubernetes 上部署和管理 Prometheus 监控系统的 Helm Chart。它基于 Prometheus Operator，提供了一套完整的监控解决方案，包括：

Prometheus Server 实例
Alertmanager 实例
Grafana 实例
Node Exporter（节点监控）
Kube State Metrics（Kubernetes 集群状态监控）
各种预定义的告警规则和 Grafana 仪表板

二、Prometheus Operator 架构

Prometheus Operator 是 kube-prometheus-stack 的核心组件，它通过 Kubernetes 自定义资源定义（CRD）扩展了 Kubernetes API，使得用户可以通过声明式方式管理 Prometheus 实例。

1. 核心组件

组件	作用
Prometheus Operator	核心控制器，监听自定义资源变化并管理 Prometheus 实例
Prometheus	自定义资源，定义 Prometheus 实例的配置
ServiceMonitor	自定义资源，定义如何监控 Kubernetes Service
PodMonitor	自定义资源，定义如何监控 Kubernetes Pod
Probe	自定义资源，定义如何监控黑盒目标
Alertmanager	自定义资源，定义 Alertmanager 实例配置
PrometheusRule	自定义资源，定义告警规则

2. 工作原理

+------------------+       +-------------------+
|  Custom Resources|       | Prometheus Operator|
| (ServiceMonitor, |<----->|     Controller     |
|  PodMonitor,     |       |                    |
|  Probe, etc.)    |       +-------------------+
+------------------+               |
                                   |
                                   v
                        +---------------------+
                        |  Prometheus Server  |
                        |     Configuration   |
                        +---------------------+

Prometheus Operator 通过监听这些自定义资源的变化，动态生成 Prometheus 配置文件，并重新加载 Prometheus 实例，实现监控配置的自动化管理。

三、ServiceMonitor 原理详解

ServiceMonitor 是 Prometheus Operator 提供的一种自定义资源，用于定义如何监控 Kubernetes Service。它通过标签选择器自动发现目标服务，并生成相应的监控配置。

1. ServiceMonitor 监控什么？

ServiceMonitor 本身并不直接执行监控任务，而是告诉 Prometheus 应该监控哪些服务。具体来说，ServiceMonitor 监控的是：

通过 Service 暴露指标的应用程序
- Web 应用的 HTTP 指标（如请求次数、响应时间等）
- 数据库的性能指标（如连接数、查询延迟等）
- 中间件的状态指标（如队列长度、处理速率等）
Exporter 暴露的系统级指标
- Node Exporter 提供的节点资源使用情况
- MySQL Exporter 提供的数据库性能指标
- Redis Exporter 提供的缓存系统指标
任何通过 HTTP 接口暴露 Prometheus 格式指标的服务

术语解释：Exporter 是一种专门用于收集和暴露指标数据的程序，它可以将各种系统或服务的指标转换为 Prometheus 能够理解的格式。

2. 应用如何暴露指标

要被 ServiceMonitor 监控，应用需要满足以下条件：

应用需要通过 HTTP 接口暴露 Prometheus 格式的指标
通常这些指标位于 /metrics 路径下
应用需要作为 Kubernetes Service 运行

简单示例（Go 语言）

package main

import (
    "net/http"
    
    "github.com/prometheus/client_golang/prometheus"
    "github.com/prometheus/client_golang/prometheus/promhttp"
)

var (
    httpRequestsTotal = prometheus.NewCounterVec(
        prometheus.CounterOpts{
            Name: "http_requests_total",
            Help: "Total number of HTTP requests",
        },
        []string{"method", "endpoint", "status"},
    )
)

func init() {
    prometheus.MustRegister(httpRequestsTotal)
}

func main() {
    // 您的应用路由
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        // 处理请求逻辑...
        w.WriteHeader(http.StatusOK)
        w.Write([]byte("Hello World!"))
        
        // 记录指标
        httpRequestsTotal.WithLabelValues(r.Method, r.URL.Path, "200").Inc()
    })
    
    // 暴露 /metrics 端点
    http.Handle("/metrics", promhttp.Handler())
    
    http.ListenAndServe(":8080", nil)
}

3. 为什么部署了 ServiceMonitor，Prometheus 就会生成对应的 target？

这是一个涉及 Prometheus Operator 内部工作机制的重要问题。当您部署一个 ServiceMonitor 资源时，Prometheus 会自动生成对应的监控目标（target），其工作流程如下：

资源创建：当您创建一个 ServiceMonitor 资源时，该资源会被存储在 Kubernetes API Server 中。
事件监听：Prometheus Operator 持续监听 Kubernetes 集群中的 ServiceMonitor 资源变化事件。一旦检测到新的 ServiceMonitor 资源被创建或更新，Operator 就会触发相应的处理逻辑。
服务发现：Operator 根据 ServiceMonitor 中定义的选择器（selector）查找匹配的 Service。例如，如果 ServiceMonitor 的 selector 是 matchLabels: {app: example-app}，Operator 会查找所有带有 app: example-app 标签的 Service。
配置生成：Operator 为每个匹配的 Service 生成 Prometheus 抓取配置。这个配置包括：
- 目标地址（Service 的 Endpoints）
- 抓取路径（如 /metrics）
- 抓取间隔
- 其他相关配置参数
配置应用：Operator 将生成的配置写入 Prometheus 实例的配置文件，并触发 Prometheus 重新加载配置。
目标监控：Prometheus 根据新配置开始定期从发现的目标抓取指标数据。

这个过程完全是自动化的，您只需要创建 ServiceMonitor 资源，Operator 就会处理其余所有步骤。

4. 基本结构

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

5. 核心字段说明

字段	说明	可选值	默认值
metadata.name	ServiceMonitor 的名称	任意合法的 Kubernetes 资源名称	无
metadata.labels	ServiceMonitor 的标签	任意键值对	无
spec.selector	标签选择器，用于选择目标 Service	matchLabels 或 matchExpressions	无
spec.endpoints	端点配置，定义如何抓取指标	数组，包含 port、path、interval 等	无

6. 工作机制

ServiceMonitor 通过 spec.selector.matchLabels 选择匹配的 Service
Prometheus Operator 监听 ServiceMonitor 资源变化
Operator 自动生成 Prometheus 抓取配置，包含所有匹配 Service 的 Endpoints
Prometheus 根据配置定期从目标抓取指标

7. 实际应用示例

假设我们有一个 Web 应用，它通过 /metrics 端点暴露 Prometheus 格式的指标：

# 应用的 Deployment
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: app
        image: example/app:latest
        ports:
        - name: web
          containerPort: 8080
---
# 为应用创建 Service
apiVersion: v1
kind: Service
metadata:
  name: example-app
  labels:
    app: example-app
spec:
  ports:
  - name: web
    port: 8080
    targetPort: 8080
  selector:
    app: example-app
---
# 创建 ServiceMonitor 来监控这个服务
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
  labels:
    app: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web
    interval: 30s
    path: /metrics
    scheme: http

在这个例子中：

Deployment 创建了 3 个应用实例（Pod）
Service 为这些 Pod 提供了稳定的网络访问入口
ServiceMonitor 告诉 Prometheus 要监控标签为 app: example-app 的 Service
Prometheus 会定期访问每个 Pod 的 /metrics 端点来获取指标

四、PodMonitor 原理详解

PodMonitor 与 ServiceMonitor 类似，但它直接监控 Pod 而不是通过 Service。PodMonitor 适用于那些没有创建 Service 的 Pod，或者需要直接监控 Pod 的场景。

1. 基本结构

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: example-pod
spec:
  selector:
    matchLabels:
      app: example-pod
  podMetricsEndpoints:
  - port: web
    interval: 30s

2. 与 ServiceMonitor 的区别

特性	ServiceMonitor	PodMonitor
监控对象	Service	Pod
发现机制	通过 Service Endpoints	直接发现 Pod
适用场景	标准服务监控	特殊 Pod 监控

五、Probe 原理详解

Probe 是用于黑盒监控的自定义资源，可以监控任何可以通过网络访问的目标，如 HTTP 服务、TCP 端口、ICMP 等。

1. ServiceMonitor 与 Probe 的区别

特性	ServiceMonitor	Probe
监控对象	Kubernetes 内部 Service	任何网络可达的目标
指标来源	应用直接暴露的 metrics	Blackbox Exporter 探测结果
使用场景	白盒监控，详细指标	黑盒监控，可用性检查
部署要求	应用需暴露 /metrics 端点	需部署 Blackbox Exporter
监控内容	应用性能、状态、业务指标等	服务可达性、响应时间等
配置复杂度	相对简单	需配置 Blackbox Exporter

2. 基本结构

apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
  name: example-probe
spec:
  prober:
    url: blackbox-exporter:9115
  targets:
    staticConfig:
      static:
      - http://example.com
      - https://howlaisi.com

3. 核心字段说明

字段	说明	可选值	默认值
spec.prober.url	Blackbox Exporter 地址	有效的 URL	无
spec.module	探测模块	http_2xx, tcp_connect, icmp_ping 等	http_2xx
spec.targets	监控目标配置	staticConfig 或 ingress	无
spec.targets.staticConfig	静态目标配置	静态 URL 列表	无
spec.targets.ingress	Ingress 目标配置	Ingress 资源选择器	无

4. 工作机制

Probe 资源定义监控目标和 Blackbox Exporter 地址
Prometheus Operator 生成监控配置
Prometheus 通过 Blackbox Exporter 探测目标
Blackbox Exporter 执行探测并将结果返回给 Prometheus

5. 实际应用示例

apiVersion: monitoring.coreos.com/v1
kind: Probe
metadata:
  name: website-monitor
spec:
  jobName: website-monitor
  prober:
    url: blackbox-exporter.monitoring.svc:9115
  module: http_2xx
  targets:
    staticConfig:
      static:
      - https://howlaisi.com
      - https://github.com
  interval: 60s

六、PrometheusRule 原理详解

PrometheusRule 是用于定义告警规则和记录规则的自定义资源。

1. 基本结构

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: example-rules
spec:
  groups:
  - name: example
    rules:
    - alert: HighErrorRate
      expr: rate(http_requests_total{status=~"5.."}[5m]) > 1
      for: 10m
      labels:
        severity: critical
      annotations:
        summary: "High error rate"

2. 规则类型

告警规则（Alerting Rules）：当表达式条件满足时触发告警
记录规则（Recording Rules）：预计算复杂表达式并存储结果

七、最佳实践

1. 标签管理

合理使用标签来组织和管理监控资源：

metadata:
  labels:
    app: my-app
    tier: frontend
    team: web-team

2. 命名规范

遵循一致的命名规范：

ServiceMonitor: <app-name>-servicemonitor
PodMonitor: <app-name>-podmonitor
Probe: <target-name>-probe
PrometheusRule: <app-name>-rules

3. 权限控制

使用 RBAC 控制对监控资源的访问：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: prometheus-operator-role
rules:
- apiGroups: ["monitoring.coreos.com"]
  resources: ["servicemonitors", "podmonitors", "probes"]
  verbs: ["get", "list", "watch"]

八、故障排除

1. 目标未被发现

检查以下几点：

ServiceMonitor/PodMonitor 的标签是否与 Prometheus 实例匹配
Selector 是否正确选择了目标资源
目标服务是否正常运行

2. 指标抓取失败

检查以下几点：

端口和路径配置是否正确
网络策略是否允许 Prometheus 访问目标
目标应用是否正常暴露指标

总结

kube-prometheus-stack 通过 Prometheus Operator 提供了一套完整的 Kubernetes 监控解决方案。ServiceMonitor、PodMonitor、Probe 等自定义资源使得监控配置变得简单而灵活，用户可以通过声明式方式定义监控目标，而无需手动管理复杂的 Prometheus 配置文件。

实践要点总结：

ServiceMonitor 用于监控集群内暴露指标的应用，是白盒监控的主要方式
Probe 用于黑盒监控，检查服务的外部可用性
应用需要主动暴露 Prometheus 格式的指标才能被 ServiceMonitor 监控
Probe 通过 Blackbox Exporter 实现探测功能
合理使用标签和选择器来组织监控资源

通过合理使用这些组件，我们可以构建一个强大而灵活的监控系统，为 Kubernetes 应用提供全面的可观测性。

在后续的文章中，我们将深入探讨如何在实际项目中使用 kube-prometheus-stack 进行监控配置，以及如何优化监控性能和管理大规模监控数据。

目录CONTENT

kube-prometheus-stack 核心组件原理解析

kube-prometheus-stack 核心组件原理解析

一、kube-prometheus-stack 概述

二、Prometheus Operator 架构

1. 核心组件

2. 工作原理

三、ServiceMonitor 原理详解

1. ServiceMonitor 监控什么？

2. 应用如何暴露指标

简单示例（Go 语言）

3. 为什么部署了 ServiceMonitor，Prometheus 就会生成对应的 target？

4. 基本结构

5. 核心字段说明

6. 工作机制

7. 实际应用示例

四、PodMonitor 原理详解

1. 基本结构

2. 与 ServiceMonitor 的区别

五、Probe 原理详解

1. ServiceMonitor 与 Probe 的区别

2. 基本结构

3. 核心字段说明

4. 工作机制

5. 实际应用示例

六、PrometheusRule 原理详解

1. 基本结构

2. 规则类型

七、最佳实践

1. 标签管理

2. 命名规范

3. 权限控制

八、故障排除

1. 目标未被发现

2. 指标抓取失败

总结

参考文档

评论区