Kubernetes监控告警体系搭建：Prometheus指标采集与告警规则配置

Kubernetes集群跑起来之后，第一件事就是把监控告警体系搭好。没有监控的集群等于裸奔：节点挂了、Pod重启、磁盘打满，等用户报障才发现，事故已经发生。本文以Prometheus生态为例，讲清楚K8s监控的架构分层、指标采集、告警规则和Alertmanager配置，覆盖从部署到报警触发的完整链路，内容可直接应用到生产集群。

一、K8s监控体系分层：四层指标各看什么

• 基础设施层：节点CPU、内存、磁盘、网络（node-exporter采集）。
• Kubernetes层：Deployment副本数、Pod状态、调度情况（kube-state-metrics采集）。
• 容器层：cAdvisor采集容器CPU/内存/网络指标，Prometheus已内置。
• 业务层：应用自定义指标，通过Prometheus客户端或micrometer暴露。

监控不能只盯节点，Pod重启次数、OOM Kill、调度失败这类K8s层指标才是集群健康度的直接反映。

二、用kube-prometheus-stack快速部署全套组件

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm upgrade --install kps prometheus-community/kube-prometheus-stack \
  -n monitoring --create-namespace \
  --set grafana.enabled=true \
  --set alertmanager.enabled=true

这个chart一把拉起Prometheus、Alertmanager、Grafana、node-exporter、kube-state-metrics和默认告警规则，适合作为监控体系的地基。生产环境建议把持久化存储打开（Prometheus默认是emptyDir，重启丢数据）：

--set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=100Gi
--set prometheus.prometheusSpec.retention=15d

三、指标采集配置：ServiceMonitor与PodMonitor

采集对象用ServiceMonitor声明，Prometheus Operator自动生成抓取任务。示例：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-metrics
  namespace: prod
spec:
  selector:
    matchLabels:
      app: kou5-api
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics

应用侧只要在容器里暴露/metrics端点（Spring Boot加micrometer-registry-prometheus，Go用promhttp），采集就自动通了。没有ServiceMonitor机制的老环境，用prometheus.io/scrape: “true”注解也能兼容。

四、告警规则：覆盖集群高发故障的阈值模板

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kou5-prod-rules
  namespace: monitoring
spec:
  groups:
  - name: node.rules
    rules:
    - alert: NodeMemoryUsageHigh
      expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 85
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "节点内存使用率超过85%"
    - alert: PodRestarting
      expr: increase(kube_pod_container_status_restarts_total[15m]) > 3
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "{{ $labels.pod }} 频繁重启"
    - alert: PVCDiskAlmostFull
      expr: kubelet_volume_stats_used_bytes / kubelet_volume_stats_available_bytes > 0.8
      for: 5m

告警规则三要素：表达式（expr）、持续时间（for）、严重级别（labels.severity）。for参数是防抖关键，指标抖动几秒不要立即报警，持续5分钟再触发，能砍掉大量噪声。规则里把namespace、pod、job这些标签带全，Alertmanager分派和人工排查才有依据。

五、Alertmanager告警路由与抑制配置

route:
  group_by: ['namespace', 'alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: dingtalk
  routes:
  - match:
      severity: critical
    receiver: dingtalk-critical
receivers:
- name: dingtalk
  webhook_configs:
  - url: http://alert-bot:8080/webhook
    send_resolved: true

配置要点：group_by把同一命名空间的同类告警聚成一条；repeat_interval决定恢复前重复通知频率，默认4小时以上避免刷屏；critical和warning走不同接收人。Alertmanager的抑制规则（inhibit_rules）可以做到节点宕机时不再重复报警该节点上的所有Pod，必须配。

六、监控告警体系落地检查清单

部署完按下面几条验收：1）Prometheus target页面无DOWN采集点；2）Grafana导入Node Exporter Full、K8s cluster面板，关键指标有数据；3）造一次故障（kill一个Pod、灌满一个磁盘）验证告警真的能打出来；4）测试告警分组和抑制是否生效。监控体系的价值在告警链路跑通之后才开始体现，定期做故障演练是保持告警有效性的唯一手段。