Kubernetes容器编排监控告警体系搭建：Prometheus到Alertmanager实战

为什么Kubernetes集群需要完整的监控告警体系

Kubernetes的动态调度特性使传统基于主机的监控方式失效——Pod随时可能被调度到不同节点，IP地址不断变化，容器生命周期短促。一套面向K8s的监控告警体系必须能自动发现服务、采集指标、触发告警，并在故障发生时快速定位到具体的Pod或容器。SRE稳定性工程的核心原则之一就是：如果无法度量，就无法改善。

监控架构选型：Prometheus生态的核心组件

云原生监控的事实标准是Prometheus生态，由以下组件构成：

Prometheus Server：核心采集和存储引擎，通过HTTP拉取（Pull模式）各目标的metrics端点。自带时序数据库TSDB，支持本地存储和远程写入。

Node Exporter：部署在每个Worker Node上，采集CPU、内存、磁盘IO、网络等主机级指标。

kube-state-metrics：监听Kubernetes API，暴露集群状态指标（Pod状态、Deployment副本数、资源请求/限制等）。

Alertmanager：接收Prometheus发送的告警，执行去重、分组、路由和通知（邮件、企业微信、钉钉等）。

Grafana：可视化面板，对接Prometheus数据源，展示实时和历史指标。

用Helm快速部署监控栈

kube-prometheus-stack这个Helm Chart集成了上述所有组件，一条命令即可部署：

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=15d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.storageClassName=local-path \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi

部署完成后，Prometheus会自动发现K8s集群中的Endpoints，开始采集指标。Grafana默认内置了K8s集群监控Dashboard，包含节点、Pod、网络等关键视图。

关键告警规则配置

告警规则定义在Prometheus的Rule文件中，以下是最核心的K8s告警规则：

# alertmanager-rules.yaml
groups:
- name: kubernetes-alerts
  rules:
  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[5m]) * 60 * 5 > 0
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod正在CrashLoopBackOff"

  - alert: NodeNotReady
    expr: kube_node_status_condition{condition="Ready",status="true"} == 0
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "节点NotReady"

  - alert: HighCPUUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "节点CPU使用率超过85%"
      
  - alert: PVCNearCapacity
    expr: kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes > 0.85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "PVC使用率超过85%"

Alertmanager通知路由与抑制

Alertmanager的核心能力是告警去重和智能路由。配置示例：

# alertmanager-config.yaml
route:
  group_by: ['alertname', 'namespace']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
  - match:
      severity: critical
    receiver: 'oncall-team'
    repeat_interval: 15m
  - match:
      namespace: 'production'
    receiver: 'prod-team'

inhibit_rules:
- source_match:
    severity: critical
  target_match:
    severity: warning
  equal: ['alertname', 'namespace']

这条抑制规则的含义：当同一命名空间下同一个告警名存在critical级别时，自动抑制warning级别的通知，避免告警风暴。

监控体系的日常维护要点

监控数据保留策略需要平衡存储成本和排查需求。生产环境建议保留15-30天短期数据，长期数据可通过Prometheus的remote_write写入对象存储（如Thanos或VictoriaMetrics集群版）。定期审查告警规则的有效性——连续3个月未触发的告警规则应考虑降级或删除，频繁误报的规则需要调整阈值或添加更多条件。CI/CD流水线中也可以加入告警规则的语法检查，避免格式错误的规则导致Prometheus加载失败。