K8s监控体系实战：Prometheus告警与Grafana可视化全解析-代码聚汇网

K8s集群跑起来之后，第一件事不是写业务，也不是调优，而是把监控体系搭好。没有监控的K8s集群就像没有仪表盘的飞机，表面上在飞，实际上你完全不知道引擎温度、油量、气压是什么状态。我见过太多人等到线上Pod OOM、节点磁盘写满、API Server响应变慢之后才开始慌慌张张查指标，结果发现连历史数据都没有，排障全靠猜。Prometheus + K8s这套组合，就是目前云原生监控的绝对主流，不管你是刚把K8s跑通，还是已经在生产环境运维了大半年，都需要搞清楚这套体系是怎么工作的。

这篇文章我不打算按官方文档照本宣科，而是从实战角度把Prometheus和K8s集成的完整链路拆开讲清楚：为什么选择Prometheus、采集链路是怎么运作的、部署时有哪些坑、告警规则应该怎么配、自定义业务指标怎么接进来。适合所有正在搭建或优化K8s监控体系的人参考。

1. Prometheus凭什么成为K8s监控的事实标准

先说一个很多人问过的问题：K8s监控方案那么多，Zabbix、Datadog、SkyWalking、VictoriaMetrics，为什么最后大家都用Prometheus？这背后不是简单的"社区选型从众"，而是K8s本身的架构设计和Prometheus的拉取模型天然契合。

K8s集群里的监控对象有三个层次：基础设施层（节点CPU、内存、磁盘、网络）、平台层（API Server、kubelet、etcd、Scheduler）、业务层（Pod里的容器进程、自定义业务指标）。传统监控工具比如Zabbix需要在每台机器上装Agent，然后由Agent主动推数据到Server端，这种推模型在K8s这种容器频繁创建销毁、Pod IP随时变化的环境里非常别扭。而Prometheus采用的是拉取模型——由Prometheus Server主动去各个目标抓取指标，目标列表通过服务发现动态获取，根本不关心Pod的IP是否变化。

这个设计带来的好处很明显：

天然适配K8s的服务发现机制：Kubernetes本身就维护着所有Pod、Service、Node的API，Prometheus可以直接通过kubelet、APIServer获取目标，不需要额外维护一份静态主机清单。
指标抓取与存储解耦：被监控对象只需要暴露一个/metrics接口，Prometheus会用HTTP协议周期性拉取，没有安装Agent的负担，也基本不侵入业务进程。
多维数据模型：Prometheus的指标名和标签（label）组合起来，能够灵活描述"哪个命名空间的哪个Pod在哪个节点上的什么指标"，这种维度正是容器环境排障最需要的。
PromQL查询语言：告警规则、Grafana图表、临时排查都靠它，语法表达力强，后面我会重点讲。

另外，K8s社区已经把Prometheus生态的各类Exporter当作基础组件来推广：node-exporter负责节点指标、kube-state-metrics负责K8s对象状态指标、cAdvisor（内置在kubelet里）负责容器运行指标。这些组件都是在K8s官方或CNCF项目里直接推荐的，整个生态已经完全围绕Prometheus的指标格式来构建。你几乎找不到一个K8s插件或中间件不提供Prometheus metrics接口，这就是事实标准的力量。

还有一个很多人忽略的点：Pull模型天然解决了监控系统的单点风险。如果某个被监控对象挂了，Prometheus会持续记录抓取失败的状态和数据缺失，事后排查时你能清楚看到"这个Pod在什么时间点开始失联"。如果是推模型，数据推不进来的时候你往往区分不清是网络问题、客户端挂了还是服务端处理不过来。这个细节在故障追责时特别重要。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 采集链路拆解：从节点指标到Pod指标到底是谁在干活

很多教程一上来就让你直接部署Prometheus，然后看到一堆target就以为完成了。但如果你不理解采集链路里每个组件到底负责什么，后面遇到数据缺失、指标含义不清的问题会很痛苦。我把这条链路上的关键角色逐个拆开说。

2.1 node-exporter：负责"机器"视角的指标

node-exporter是部署在每个K8s节点上（通常用DaemonSet）的指标采集器，监控对象是宿主机操作系统——CPU使用率、内存使用率、磁盘空间、磁盘IO、网络收发、文件系统状态等。它采集的数据大多来自Linux的/proc和/sys文件系统，所以不需要往内核里装额外的东西，权限也只需要挂载宿主机的一些只读路径。

以磁盘告警为例，node_filesystem_avail_bytes这个指标就是node-exporter提供的。你在Prometheus里看到的node_*前缀指标，基本都来自它。

2.2 kubelet内置的cAdvisor：负责"容器"视角的指标

cAdvisor是Google开源的容器资源监控工具，从K8s早期版本开始就集成在kubelet中，你不需要单独部署它。它负责采集节点上每个容器的CPU、内存、网络、文件系统使用情况，暴露在kubelet的/metrics/cadvisor端点。

这就是为什么K8s能"开箱即用"地看到每个Pod的CPU内存占用——kubectl top pod的底层数据来源就是cAdvisor。当你在Prometheus里查询container_cpu_usage_seconds_total、container_memory_working_set_bytes这类指标时，数据就来自这里。

这里有个关键点：很多对容器监控的误解来自不清楚cAdvisor和node-exporter的分工。node-exporter看到的是"这台机器还有多少内存"，cAdvisor看到的是"这个容器用了多少内存"。告警阈值应该分开设计：节点内存不足时你可能要考虑驱逐Pod或扩节点，单个Pod内存持续上涨时你要找的是业务代码问题。

2.3 kube-state-metrics：负责"K8s对象状态"的指标

node-exporter和cAdvisor都是偏物理资源维度的，但K8s运维还需要知道集群里各种对象的状态：Deployment期望副本数是多少？实际Ready几个？Pod处于什么阶段（Running、Pending、Failed）？PVC状态是否正常？Job有没有成功跑完？这些信息来自K8s API，而不是操作系统。

kube-state-metrics做的事就是监听Kubernetes API，把Deployment、Pod、Service、PVC、HPA等对象的状态翻译成Prometheus指标。比如：

kube_deployment_status_replicas_available：Deployment当前可用副本数
kube_pod_status_phase：Pod当前阶段
kube_persistentvolumeclaim_status_phase：PVC状态（Bound/Lost/Pending）

这些指标是编写K8s平台告警（关于副本数、Pod重启、PVC容量等）的主要数据来源。很多人部署了Prometheus但pod相关告警发不出来，原因往往就是没有部署kube-state-metrics。

2.4 服务发现：Prometheus怎么知道该抓谁的指标

传统静态配置方式在K8s环境下根本不现实，因为Pod IP和数量随时在变。Prometheus支持多种服务发现机制，K8s集成中最常用的是kubernetes_sd_configs，通过访问Kubernetes API动态获取节点、Pod、Service、Endpoints列表。

这里有个核心概念需要理解：采集目标不等于采集指标。Prometheus通过服务发现拿到的是"要抓取的target列表"，每个target上可能有多个metrics端点需要通过relabel规则来区分。

举个例子，kubelet本身暴露了多个metrics路径：/metrics（kubelet自身指标）、/metrics/cadvisor（cadvisor容器指标）、/metrics/probes（探针指标）。你不能把这三个路径都配成一个target，否则数据就乱了。常见做法是通过__metrics_path__这个标签来区分，这也是初学者在配置采集规则时最容易出错的地方。

relabel_config是Prometheus服务发现里最有威力的功能，它允许你在抓取前对target的标签进行增删改。比如把__meta_kubernetes_namespace映射成namespace标签、把__meta_kubernetes_pod_name映射成pod标签，这样在查询时就能按namespace和pod维度聚合。理解relabel是玩转K8s监控的一大门槛，后面我会给一个直接可用的配置示例。

2.5 指标生命周期：从Exporter到Prometheus再到告警

完整的链路是这样的：各种Exporter（node-exporter、kube-state-metrics、业务自定义Exporter）暴露/metrics端点，Prometheus根据服务发现规则找到这些端点，周期性抓取指标并按照指标名+标签集存储到TSDB（时序数据库）中，然后通过PromQL查询引擎响应Grafana图表和告警规则。

再往上一层，Alertmanager负责接收Prometheus推送过来的告警，经过分组、抑制、静默处理后，通过Webhook、邮件、钉钉、企业微信等渠道发出通知。

3. 从零部署：用Helm把Prometheus全家桶铺起来

部署Prometheus有两种主流方式：直接用Kubernetes原生资源手写ServiceMonitor和Deployment，或者用Helm Chart一键部署。我建议生产环境直接用Helm，尤其是kube-prometheus-stack这个chart，它把Prometheus、Alertmanager、Grafana、node-exporter、kube-state-metrics以及常用告警规则全部打包好了，一条命令就能拉起一套完整的监控体系。

3.1 为什么推荐kube-prometheus-stack

早期社区用的是prometheus-operator，后来改名为kube-prometheus-stack，现在它是最主流的K8s监控部署方案。它的核心思想是把Prometheus的部署和配置抽象成Kubernetes自定义资源（CRD），你不需要手写Prometheus的yaml配置文件，只需要声明ServiceMonitor、PodMonitor、PrometheusRule这些CRD对象，Operator会自动把它们翻译成Prometheus配置并热加载。

这个方式的生产价值非常明显：

配置即代码：新增一个监控目标，只需创建一个ServiceMonitor对象，不需要SSH到Prometheus容器里改配置文件。
配置热更新：Prometheus Operator会监听CRD变化并自动reload配置，不需要手动重启服务。
内置大量常用告警规则：安装chart时可以选择带上KubernetesApp的告警规则（Pod频繁重启、节点不可用、PVC容量不足等），省去从零写规则的精力。

3.2 部署步骤与关键参数

先准备一个values文件。直接使用Helm默认值可以跑起来，但下面这些参数几乎是一定要覆盖的：

yaml复制# values-custom.yaml
prometheus:
  prometheusSpec:
    retention: 15d                       # 指标保留时长，生产环境至少15天
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard     # 改成你的集群默认StorageClass
          resources:
            requests:
              storage: 100Gi             # 按指标量评估
    resources:
      requests:
        memory: 2Gi
        cpu: 500m
      limits:
        memory: 4Gi

alertmanager:
  alertmanagerSpec:
    storage:
      volumeClaimTemplate:
        spec:
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 10Gi

grafana:
  adminPassword: "your-strong-password"
  persistence:
    enabled: true
    storageClassName: standard
    size: 10Gi
  sidecar:
    datasources:
      enabled: true
      maxDataSources: 3
      defaultDatasourceEnabled: true

nodeExporter:
  tolerations:
    - key: "node-role.kubernetes.io/control-plane"
      operator: "Exists"
      effect: "NoSchedule"

kube-state-metrics:
  metricLabelsAllowlist:
    - pods=[*]
    - deployments=[app.kubernetes.io/name]

执行命令：

bash复制helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  -n monitoring \
  -f values-custom.yaml

部署完成后检查：

bash复制kubectl get pods -n monitoring
kubectl get svc -n monitoring

可以看到Prometheus、Alertmanager、Grafana等Pod都起来了。如果节点有控制平面污点（control-plane的taint），记得给node-exporter和kube-state-metrics加上tolerations，否则它们不会被调度到master节点，master节点的指标就丢了。

3.3 用ServiceMonitor接入自定义监控目标

部署好之后，你可能需要监控一个自建中间件（比如Redis集群）或者业务服务。打开Prometheus的Targets页面你会发现，kube-prometheus-stack只自动采集了Kubernetes自身的指标，你自定义服务的指标并不会自动出现。你需要为它创建一个ServiceMonitor对象。

假设你的业务服务在default命名空间，服务名是my-app，暴露metrics的端口是9090，路径是/metrics：

yaml复制apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: my-app-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: my-app
  namespaceSelector:
    matchNames:
      - default
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

这里有几个坑需要强调：

ServiceMonitor的namespace通常要放在monitoring，或者你通过namespaceSelector指定扫描范围。
selector匹配的是Service的标签，不是Pod的标签。很多人给Pod打了标签，却忘了Service也需要打对应标签。
endpoints里的port必须是Service端口定义里的名称。

创建完成后，Prometheus会在几十秒内自动发现这个target。在Prometheus UI的Status -> Targets里就能看到新目标的状态。

3.4 手动Prometheus部署方案：什么时候该绕开Operator

kube-prometheus-stack很强大，但它默认做了很多封装，在某些边缘场景（比如只想临时验证一个配置、或者网络环境下无法访问外网拉取chart镜像），你可能会想手动部署。

手动部署的基本思路是：用ConfigMap保存prometheus.yml配置，用Deployment运行Prometheus容器，挂在ConfigMap作为配置文件，再用Service暴露9090端口。但这种方式有两个问题：一是配置文件修改后需要手动重启，二是服务发现和目标配置全得手写，维护成本高。

我的建议是：除非是学习实验或资源极其受限，否则直接上Operator。手动方式作为理解原理的练习可以，生产环境维护起来太痛苦了。

4. Grafana可视化：从数据到可读图表的最后一公里

数据能抓了，但Prometheus自带的UI做查询和排查还行，做展示和长期观察就太简陋了。Grafana是这套监控体系里负责可视化的组件，通过Prometheus作为数据源，把PromQL查询结果渲染成折线图、柱状图、热力图等各种图表。

4.1 数据源配置

kube-prometheus-stack在部署Grafana时已经通过sidecar自动把Prometheus配成了默认数据源，正常情况下你不需要手动配置。但我遇到过很多次的情况是：因为网络或启动顺序问题，数据源没自动配好。手动配置时，URL要填Prometheus的Service地址，通常是http://kube-prometheus-stack-prometheus.monitoring.svc:9090，注意要用集群内Service名而不是NodePort地址。

4.2 Dashboard从哪里来

Grafana最方便的地方在于有庞大的官方Dashboard市场，绝大多数常用场景的图表都有人做好了。K8s监控刚起步时，直接使用ID为315（Kubernetes Cluster Monitoring）和8588（Kubernetes Deployment Statefulset Daemonset Metrics）这两个dashboard，基本上能覆盖集群概览和资源使用的主要场景。

导入dashboard的方法有两个：一个是到Grafana官网找到对应的dashboard JSON，复制后在Grafana里Import；另一个是直接在导入框输入dashboard ID，前提是Grafana能访问dashboards.grafana.com。

但要说实话，官方Dashboard不一定完全适配你的环境。比如某些变量（如namespace、node）的查询方式可能和你的标签定义不一致，导致图表空白。遇到这种情况不要死磕模板，打开Prometheus UI里实际查一下label_values()函数的返回结果，调整dashboard变量即可。

4.3 我自己常用的一套面板组合

监控体系跑起来后，我通常会为不同角色准备不同视角的Dashboard：

集群概览（Ops视角）：节点CPU/内存/磁盘使用率排名、集群容量剩余趋势、API Server请求QPS和延迟、etcd健康状态。
工作负载视角（开发视角）：每个命名空间下Deployment的副本数、Pod重启次数、CPU Throttling、内存增长趋势。
资源效率视角（成本视角）：节点资源请求量vs使用量对比、各命名空间资源占用排行，方便评估扩容和降配。

对于面板的细节，我有几条经验：

时间序列图默认用$__rate_interval作为rate函数的时间范围，而不是硬编码5m，这样图表在不同时间跨度下都能保持合理。
使用$namespace、$node这类模板变量，让同一张图可以在不同维度间切换，避免为每个命名空间建一堆重复面板。
磁盘使用率建议用百分比而不是绝对值，因为不同节点磁盘大小不一样。

5. 告警规则实战：磁盘告警、Pod异常和CPU Throttling

监控不只是"看"，更重要的是"出了问题能及时收到通知"。Prometheus的告警规则用PromQL表达式定义触发条件，配合Alertmanager完成通知分发。这一节我从热词里挑几个大家最关心的场景，给出可以直接落地的规则和解释。

5.1 节点磁盘告警：阈值和PromQL写法

磁盘满了是K8s集群最危险的故障之一，节点磁盘写满可能导致镜像拉取失败、容器无法创建、甚至节点进入NotReady状态。常见的告警规则是监控根分区使用率：

yaml复制groups:
  - name: node-disk
    rules:
      - alert: NodeFilesystemSpaceFillingUp
        expr: |
          (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"} /
           node_filesystem_size_bytes{fstype!~"tmpfs|overlay|squashfs"}) * 100 < 20
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "节点磁盘即将写满 (instance {{ $labels.instance }})"
          description: "设备 {{ $labels.device }} 当前可用空间不足20%，已持续5分钟。"

这里有三个细节要说明：

排除tmpfs和overlay是因为它们是临时文件系统和容器层虚拟文件系统，没有真正的磁盘空间概念，不排除它们会造成大量误报。
for: 5m表示指标值连续5分钟都满足条件才触发告警，避免瞬时抖动造成骚扰。
阈值20%是通用的起步值，建议根据实际磁盘容量调整：如果磁盘是500GB，20%还有100GB空间，不用太紧张；但如果是30GB的小盘，20%只剩6GB，等告警到的时候可能已经在崩溃边缘了。我习惯给大盘设置10%，小盘设置25%。

还有一种更推荐的"预测型"告警：不仅看当前剩余值，还看下降趋势。用predict_linear函数基于过去6小时的数据预测未来24小时磁盘使用情况：

yaml复制expr: |
  predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"}[6h], 24*3600) < 0

这条规则的含义是：如果按照最近6小时的消耗速度继续下去，未来24小时内磁盘空间会用完，那么就触发告警。对付日志增长速度快的服务节点特别有用，能提前预警而不是等到真的写满才报警。

5.2 Pod重启与副本异常：盯住kube-state-metrics

磁盘监控是基础设施层面的，工作负载层面的告警来自kube-state-metrics。核心就是盯住Pod可用副本数和Pod重启次数：

yaml复制- alert: KubernetesPodRepeatedlyRestarting
  expr: |
    increase(kube_pod_container_status_restarts_total[1h]) > 5
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "Pod频繁重启 ({{ $labels.namespace }}/{{ $labels.pod }})"
    description: "容器 {{ $labels.container }} 在过去1小时重启了超过5次。"

- alert: KubernetesDeploymentReplicasMismatch
  expr: |
    kube_deployment_spec_replicas != kube_deployment_status_replicas_available
  for: 10m
  labels:
    severity: critical
  annotations:
    summary: "Deployment副本数不匹配 ({{ $labels.namespace }}/{{ $labels.deployment }})"
    description: "期望副本数 {{ $labels.deployment }} 的可用副本数低于期望值，持续10分钟。"

特别注意：increase()函数在指标重启后可能会产生幻觉值，因为它基于counter跳变来推断，因此建议配上for: 10m来过滤掉瞬时抖动。

5.3 CPU Throttling：最容易被误读的容器CPU问题

CPU Throttling在K8s运维里是高频热搜词，因为它直接影响业务延迟，但很多人不知道它到底是怎么来的。我单独拉一节来讲。

先理解CFS配额机制：当你在Pod里给容器设置limits.cpu后，内核会通过CFS带宽控制来限制这个容器在一段时间内最多使用的CPU时间。比如limits.cpu: 1意味着容器每100ms最多使用100ms的CPU时间。如果容器实际需要更多CPU时间，内核就会强制它"暂停"，这段被强制暂停的时间就是Throttling。

PromQL里跟这个相关的指标是container_cpu_cfs_throttled_periods_total和container_cpu_cfs_periods_total，它们都来自cAdvisor。计算throttle比例：

promql复制sum by (namespace, pod, container) (
  rate(container_cpu_cfs_throttled_periods_total[5m])
) /
sum by (namespace, pod, container) (
  rate(container_cpu_cfs_periods_total[5m])
) > 0.2

如果这个比例长期高于20%到30%，说明容器被CPU限流了，业务延迟大概率是这里造成的。但高throttle比例并不一定等于CPU资源不足，还可能是错误地设置了过小的CPU limit，比如给一个本来需要2核的服务设置了limits.cpu: 500m。这种情况下即使节点还有大量空闲CPU，内核仍然会强制限流。这也就是为什么老有人说"我明明没到limit，为什么被throttle了"——它是硬限流，不是按使用率动态限流。

排查思路一般是：

先看container_cpu_usage_seconds_total的实际使用率，确认是否真的需要更多CPU。
再对比limits.cpu和实际使用率，如果实际使用率远低于limit但还是高频throttle，那大概率是cpu.cfs_period_us设置导致的突发能力不足，可以考虑调整内核参数或修改CPU request/limit。
同时看一下工作节点的CPU水位，如果节点本身CPU已经饱和，单纯调整Pod的limit也解决不了问题，需要扩容节点。

6. 权限与安全：给不同角色开最小权限的监控账号

热词里有一条"k8s只开只读权限的用户"，这说明大家在多团队协作时对权限控制有真实需求。监控体系里面其实牵扯两类权限：一类是人访问Grafana/Prometheus的权限，另一类是Prometheus访问K8s API的权限。这两个容易混，分开说。

6.1 Prometheus访问K8s API的权限（RBAC）

Prometheus通过服务发现要去查询K8s API，所以需要给它一个ServiceAccount并绑定Role（或ClusterRole）。服务发现需要读哪些资源，取决于你的采集目标类型。如果只是监听集群的Pod、Service、Endpoints、Node，需要以下权限：

yaml复制apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-readonly
rules:
  - apiGroups: [""]
    resources: ["nodes", "nodes/metrics", "services", "endpoints", "pods"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["networking.k8s.io"]
    resources: ["ingresses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["discovery.k8s.io"]
    resources: ["endpointslices"]
    verbs: ["get", "list", "watch"]

然后用RoleBinding或ClusterRoleBinding把它绑定到Prometheus的ServiceAccount上。kube-prometheus-stack默认创建好了一整套RBAC，所以不用你手动配。如果你是自己手动部署的Prometheus，这一步千万别漏，否则服务发现会报一堆Forbidden错误。

6.2 给同事开一个只读账号看Grafana

如果一个开发同学只想知道"我的服务现在Pod有没有重启、CPU有没有超限"，给他一个Grafana只读账号就够了。Grafana的权限模型是：Viewer角色只能查看仪表盘，但不能修改、不能管理数据源。创建方式是在Grafana的Server Admin -> Users -> Invite里添加用户，角色选Viewer。

如果想更细粒度地控制某个团队只能看到自己命名空间的Dashboard，可以通过Grafana的Folders和Team功能实现：把特定Dashboard放到一个Folder里，然后给这个Folder配置权限，只允许某个Team查看。这个需要Grafana的Organization或Team配合操作，比单纯的Viewer稍微复杂一点，但多团队协作时确实需要这么做。

6.3 通过kubectl查看指标时的权限控制

还有一类需求是给开发同学一个kubectl只读账号，让他能自己看kubectl top pod、kubectl get events。创建方式是生成一个ServiceAccount，绑定一个ClusterRole，再生成对应的kubeconfig。这是一个常见的运维操作，核心思想跟上面Prometheus的RBAC类似，给最小的get/list/watch权限。注意不要把cluster-admin绑给普通开发，那是给自己埋雷。

7. 把业务指标接进来：从一个Redis集群和缓存命中率说起

热词里有一条很有代表性："prometheus如何监控redis集群"和"收集vllm-ascend的缓存命中率指标"。这是从"监控基础设施"到"监控业务"的跃迁，很多人在这个阶段卡住了。这一节我用两个典型案例讲清楚接入业务指标的标准姿势。

7.1 监控Redis集群：用redis_exporter

Redis集群通常包含多个节点，有的还有Proxy和Sentinel。监控Redis的标准做法是使用redis_exporter，它通过redis://协议连接到Redis实例，拉取INFO、CONFIG等命令的输出，转换成Prometheus指标格式。

在K8s里部署redis_exporter有几种方式：

以Sidecar容器方式跑在Redis Pod旁边，这样Exporter和Redis生命周期一致，指标采集走localhost，性能开销极小。
以独立Deployment方式部署，通过连接串指向Redis Service。
在Redis Pod里通过annotation配合PodMonitor来采集。

推荐第一种Sidecar方式。部署Pod时在同一个Pod里多加一个容器：

yaml复制containers:
  - name: redis
    image: redis:7.0
    ports:
      - containerPort: 6379
  - name: redis-exporter
    image: oliver006/redis_exporter:v1.55.0
    args: ["--redis.addr=redis://localhost:6379"]
    ports:
      - containerPort: 9121
        name: metrics

然后用PodMonitor（而不是ServiceMonitor）来抓取，因为Sidecar容器没有独立的Service：

yaml复制apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: redis-exporter-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: redis
  namespaceSelector:
    matchNames:
      - default
  podMetricsEndpoints:
    - port: metrics
      path: /metrics

关键指标看这几个：

redis_up：Exporter和Redis连通性
redis_memory_used_bytes / redis_memory_max_bytes：内存使用率，Redis如果设置了maxmemory，这个告警能提前预判内存淘汰风险
redis_connected_clients：连接数异常上涨
redis_keyspace_hits_total和redis_keyspace_misses_total：命中率，下面是重点。

7.2 缓存命中率指标：从业务代码到Prometheus

缓存命中率这类指标，redis_exporter自带的redis_keyspace_hits_total和redis_keyspace_misses_total可以直接算：

promql复制sum(rate(redis_keyspace_hits_total[5m])) /
(sum(rate(redis_keyspace_hits_total[5m])) + sum(rate(redis_keyspace_misses_total[5m]))) * 100

但如果你要监控的是业务层面的缓存命中率，比如一个AI推理服务的KV Cache命中率，就必须自己在业务代码里埋点暴露指标。

以vLLM这类推理框架为例，缓存命中率通常是基于请求里的cache hit token数和总token数计算的。你需要做的就是在代码里用Prometheus客户端库暴露一个counter指标：

python复制from prometheus_client import Counter, Gauge

CACHE_HIT_TOKENS = Counter(
    "llm_cache_hit_tokens_total",
    "Total number of cache hit tokens",
    ["model", "instance"],
)
CACHE_TOTAL_TOKENS = Counter(
    "llm_cache_total_tokens_total",
    "Total number of tokens processed",
    ["model", "instance"],
)

每次服务请求结束时，把本次的命中token数和总token数累加到这个counter上。然后暴露/metrics端点：

python复制from prometheus_client import start_http_server
start_http_server(9090)

部署之后，用ServiceMonitor（如果Pod有对应的Service）或PodMonitor把metrics接进来，然后在Grafana里用PromQL计算命中率：

promql复制100 * (
  sum(rate(llm_cache_hit_tokens_total[5m]))
  /
  sum(rate(llm_cache_total_tokens_total[5m]))
)

这里有个建议：直接用Counter类型 + rate()函数算比率，而不是用Gauge存百分比值。Counter的语义是"累计值"，正好匹配"从开始到现在共命中多少次"这种业务语义，而且rate()会自动处理重启、采样间隔不一致的问题，计算结果更稳定。

8. 高负载期的常见故障与排查链路

监控系统搭建完成并不代表可以高枕无忧。Prometheus本身也会成为瓶颈，尤其是在集群规模扩大、指标数量暴增之后。我把自己在实际运维中遇到的几类高频问题整理成故障排查链路，按现象到根因的逻辑来讲。

8.1 Prometheus内存爆掉、OOM不断重启

kube-prometheus-stack部署的Prometheus默认没有配置内存limit，但实际生产中很常见的问题是Prometheus内存涨到几个GB甚至十几个GB然后OOM。根因通常是指标基数过大——也就是高基数标签组合太多。

什么情况会造成高基数？举例来说，如果你的业务Pod打了user_id这种高维度标签，每个用户一个标签值，标签基数是百万级别，那么任何一个query在计算时都要扫描数百万条时间序列，内存自然撑不住。

排查链路：

先用kubectl describe pod prometheus-kube-prometheus-stack-prometheus-0 -n monitoring查看OOM Kill事件。
进入Prometheus的TSDB Status页面，看Head Stats里的series count，正常的集群几千到几万series，如果到了百万级就有问题了。
通过TSDB Status -> Label Values找出高基数标签。比如看pod这个标签的取值数量是否异常，或者某个自定义标签是否数值化了。
如果是业务指标引入了高基数标签，修改代码去掉标签或降低基数；如果是采集配置有问题（比如把__meta_kubernetes_pod_annotation_*里面带随机值的内容当成了标签），修正relabel规则。

预防措施：

在Prometheus的global配置里设置scrape_timeout为10s而不是默认的0s（不超时），防止某些不正常的target把抓取线程拖死。
结合业务实际需求合理设置retention，没必要保留两年的高精度数据。
评估是否需要拆分多个Prometheus实例，比如一个管基础设施，一个管业务指标。

8.2 采集target显示down，但不是发红也不是完全消失

这是最常见的K8s监控问题：Targets页面某个target显示down，但切换查看其他target又正常。排查链路如下：

确认target地址是否可达：从Prometheus容器里wget或curl该地址的/metrics，确认端口和路径是否正确。如果不可达，检查Service的selector标签是否匹配Pod，Pod是否处于Running状态。
确认指标接口响应是否正常：有时候target地址能通，但/metrics接口返回500或4xx，这可能是因为Exporter本身启动失败了或者配置错了。看Pod日志确认。
确认抓取超时设置：如果业务服务的/metrics接口处理太慢（比如内部要跑一堆查询聚合），抓取超时就会导致down。把scrape_timeout调大一点，或者优化metrics接口的响应速度。
检查TLS认证问题：很多组件（如Kubelet）默认启用了HTTPS和自签证书，Prometheus抓取时需要跳过证书校验或配置token。如果一直报x509: certificate signed by unknown authority，就说明抓取端的TLS配置没对。

8.3 数据对不上：同一份Grafana面板，有人看到有数据，有人看到没数据

这个问题通常出在时间范围和分辨率的设置上，而不是数据真的丢了。Prometheus的查询是分段采样的，Grafana面板的时间跨度不同，会自动改变数据聚合粒度。比如7天视图下采样到7分钟一个点，如果原始数据有瞬时抖动或断点，在7天视图里可能被平滑掉；1小时视图里又能看到数据。这不是监控丢了，是密度不够。

另一个常见原因是Grafana模板变量作用域冲突。多个面板共用一个模板变量，某个面板里手动指定了固定的namespace，另一个面板用$namespace，视觉上就会"数据对不上"。

8.4 告警没收到：从规则到通知的全链路排查

告警链路是：Prometheus规则命中 -> 发送给Alertmanager -> 按路由匹配 -> 调用Webhook/邮件通知。

排查步骤：

先在Prometheus的Alerts页面看规则状态，确认是否进入Pending或Firing状态。如果连规则都不触发，那问题在PromQL表达式或for条件上。
查看Alertmanager的Status页面，确认告警是否被接收。
确认Alertmanager的路由配置匹配到了正确的receiver。比如你给namespace A配了钉钉webhook，但告警里的labels不包含namespace，而路由需要按namespace匹配，就会走默认receiver导致没收到。
确认Webhook接收方的安全策略，比如某些Webhook只接受特定IP段，或者配置了签名校验，Alertmanager发过去的请求被拒了。

告警配置里的一个黄金建议是：告警规则里尽量带上namespace、severity、team这些有分类意义的标签，一方面让路由简单，另一方面让值班人一眼就知道该怎么处理。一开始不规划标签，后面告警多了就是灾难。

9. 生产环境优化：存储、成本与长期维护

最后聊几个生产环境中逃不掉的话题。监控系统本身也需要运维，以下优化经验能帮你少踩很多坑。

9.1 指标保留策略与对象存储归档

Prometheus的本地TSDB存储粒度有限，如果磁盘不大，保留15天已经是比较乐观的配置。对于超过保留期的历史指标，常见的做法有：

Thanos：把长期数据存到对象存储（S3、OSS、MinIO）里，通过Sidecar或Receiver模式把Prometheus的TSDB block上传，查询时Thanos Query统一聚合本地+远程数据。
VictoriaMetrics：兼容PromQL，存储效率更高，很多大规模集群直接用VM替换Prometheus。
如果你不想引入额外组件，就把retention设短一点，同时保证告警和实时Dashboard所需的数据都在保留期内。

我在实际项目中见过不少团队一上来就纠结"要不要上Thanos"，但业务指标量只有几万series，根本没有这个必要。监控系统的复杂度应该跟业务规模匹配，5个节点的集群配全Thanos那套纯属自找麻烦。

9.2 Prometheus本身也要监控

这听起来像套娃，但确实是生产环境必须做的事。Prometheus挂了，所有的告警、Dashboard全部失明，这是最危险的故障之一。实践中至少有以下几个方面要盯：

up指标：任何一个target挂了都知道。
Prometheus自身的CPU、内存、磁盘：通过kube-prometheus-stack自带的面板和告警就能覆盖。
Prometheus的WAL目录是否增长过快、是否有写入失败报错：这通常说明TSDB有问题或磁盘IO跟不上。

9.3 多集群方案：一个Prometheus还是每集群一套

如果你有多个K8s集群（测试集群、生产集群、边缘集群），会有两种路线：

每集群一套：隔离性好，故障边界清晰，推荐。
集中一套拉取所有集群：需要搞联邦（Federation）或专门的远程写入，配置复杂，且单点风险高。

我个人强烈建议每集群一套Prometheus，然后通过统一的Grafana数据源管理（Grafana支持配置多个Prometheus数据源，用--data.source变量切换视图）。这样每个集群的监控都不会跨集群互相影响，多个集群的汇总视图通过Grafana的Merging或Prometheus数据源拼接来实现，已经很成熟了。

9.4 成本视角：别让监控吃掉太多节点资源

Prometheus全家桶的资源占用其实不小，尤其是Prometheus本身和Grafana。中小型集群里这套监控可能占掉一个2核4G节点的资源。优化方向有：

适当降低抓取频率：默认15s，如果对实时性要求不高可以调到30s或1分钟，指标总量几乎减半。
关闭不需要的Exporter：比如配置了kube-prometheus-stack默认会采集kube-controller-manager和kube-scheduler的指标，但很多人并不看这两个组件，可以在values里关掉。
Grafana本身不是资源大户，但不必要的插件、旧版本升级不及时也会缓慢涨内存。

10. 写在最后的几个实操心得

监控体系这个事，很多坑是实际使用中被反复教育出来的。我把个人经验浓缩成几条希望大家少走弯路。

第一，先明确你要回答什么问题，再决定采集什么指标。不要上来就追求指标多而全，一个"节点CPU使用率"加上"Pod重启次数"加上"磁盘空间"基本能满足80%的运维需求。指标数量越多，存储成本、查询延迟、告警噪声都会同步上升。

第二，告警规则要精不要多。我见过有人一开始就给每台机器配了20多条告警规则，结果每天被骚扰得麻木了，真出了问题反而没人重视。宁可先配5条关键的（节点不可用、磁盘写满、Pod崩溃循环、API Server异常、证书过期），跑一段时间再按需增加。

第三，把Prometheus的学习当成一个投资。不管是K8s运维、DevOps还是做SRE，Prometheus和PromQL几乎是绕不开的。我招人面K8s岗位时，PromQL熟练度几乎能直接判断一个人有没有真正在生产环境搞过K8s运维。早学早省心。

第四，报警发出去之前，先想清楚收信人能否处理。如果告警信息里没有namespace、没有instance、没有具体的磁盘挂载点、没有建议的排查命令，值班人看到告警只会焦虑，无法行动。我写的每条告警规则，都会反复推敲description字段，把"现在是什么东西出现了什么问题、大概怎么查"都写进去。

我对K8s监控体系的态度一直是：它不酷，甚至有点繁琐，但没有它，业务跑得越快，哪天出问题就摔得越狠。花一个下午把这套东西搭好，长期看是稳赚不赔的事。

K8s监控体系实战：Prometheus告警与Grafana可视化全解析