Kubernetes监控体系：Prometheus与Grafana实战指南

虎猛

1. Kubernetes监控体系全景解读

在容器化部署成为主流的今天，一个中等规模的Kubernetes集群可能同时运行着数百个Pod实例。上周我们生产环境就遇到过这样的情况：某个微服务Pod内存泄漏导致节点OOM（Out Of Memory），但由于缺乏有效的监控手段，问题直到影响终端用户才被发现。这正是我们需要建立完善监控体系的原因——就像给集群装上"神经系统"，实时感知每个组件的健康状态。

典型的Kubernetes监控需要覆盖四个维度：

基础设施层：节点CPU/内存/磁盘等物理资源指标
容器运行时层：Pod/容器的资源消耗情况
应用性能层：服务响应时间、错误率等业务指标
编排系统层：API Server、Scheduler等控制面组件的运行状态

2. 监控工具选型与架构设计

2.1 核心组件对比

经过多次压力测试验证，我们最终确定的监控方案组合是：

code复制Prometheus（指标采集）+ Grafana（可视化）+ Alertmanager（告警）

这个组合的优势在于：

Prometheus的Pull模型天然适合Kubernetes动态环境，通过ServiceDiscovery自动发现监控目标
Grafana的仪表盘模板生态丰富，可直接导入社区成熟的K8s监控模板
Alertmanager支持灵活的告警路由和抑制规则，避免告警风暴

重要提示：生产环境建议将Prometheus部署为StatefulSet并配置持久化存储，否则重启后历史数据会丢失

2.2 数据采集架构

监控数据流向设计如下：

mermaid复制graph LR
    A[Kubelet cadvisor] -->|暴露容器指标| B(Prometheus)
    C[kube-state-metrics] -->|暴露资源对象状态| B
    D[Node Exporter] -->|暴露节点指标| B
    B -->|存储TSDB| E[Grafana]
    B -->|触发告警| F[Alertmanager]

实际部署时需要特别注意：

为Prometheus配置合理的scrape_interval（通常15-30秒）
设置适当的retention_period（生产环境建议至少15天）
对重要指标配置recording rules减少查询开销

3. 详细部署实操指南

3.1 Helm部署Prometheus Stack

使用Helm可以一键部署完整监控套件：

bash复制helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-monitor prometheus-community/kube-prometheus-stack \
    --namespace monitoring \
    --set prometheus.prometheusSpec.retention=30d \
    --set grafana.adminPassword='YourSecurePassword'

关键参数说明：

retention：调整数据保留周期
storageSpec：生产环境必须配置持久卷
serviceMonitorSelectorNilUsesHelmValues：设置为false以监控所有ServiceMonitor

3.2 配置示例解析

以下是监控API Server的典型ServiceMonitor配置：

yaml复制apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: kube-apiserver
spec:
  endpoints:
    - port: https-metrics
      scheme: https
      tlsConfig:
        insecureSkipVerify: true
      bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
  namespaceSelector:
    matchNames: [default]
  selector:
    matchLabels:
      component: apiserver

4. 核心监控指标详解

4.1 必监控的黄金指标

根据Google SRE方法论，这些指标需要重点监控：

指标类型	示例指标	告警阈值建议
错误率	apiserver_request_errors	>5%持续5分钟
延迟	apiserver_request_duration_seconds	P99>1s
流量	container_cpu_usage_seconds_total	同比变化>50%
饱和度	node_memory_MemAvailable_bytes	<10%总内存

4.2 关键Kubernetes指标

promql复制# 节点CPU使用率
100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Pod内存使用量
sum by(pod) (container_memory_working_set_bytes{container!=""})

# 持久卷剩余空间
kubelet_volume_stats_available_bytes / kubelet_volume_stats_capacity_bytes * 100

5. 告警规则最佳实践

5.1 生产级告警示例

yaml复制groups:
- name: node.rules
  rules:
  - alert: NodeOutOfDisk
    expr: kubelet_volume_stats_available_bytes / kubelet_volume_stats_capacity_bytes * 100 < 10
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Node {{ $labels.instance }} disk will fill up soon"
      description: "{{ $value }}% space left on {{ $labels.instance }}"

5.2 告警分级策略

我们采用三级告警机制：

Warning：需要关注但无需立即处理（如磁盘使用率>80%）
Critical：需要立即介入（如节点NotReady）
Disaster：影响业务连续性（如所有副本不可用）

经验之谈：避免"狼来了"效应，Critical以上告警应该<5条，确保每条都值得半夜被叫醒

6. 性能优化实战技巧

6.1 Prometheus调优参数

在高负载集群中需要调整这些参数：

yaml复制prometheus:
  prometheusSpec:
    retention: 7d
    resources:
      limits:
        memory: 16Gi
    enableAdminAPI: false  # 禁用危险的管理接口
    query:
      lookbackDelta: 5m    # 减少内存占用

6.2 长期存储方案

当数据量超过单个Prometheus实例处理能力时：

使用Thanos或VictoriaMetrics实现水平扩展
配置Prometheus远程写入到InfluxDB/TimescaleDB
对历史数据做降采样处理

7. 故障排查手册

7.1 常见问题速查表

现象	可能原因	排查命令
指标缺失	ServiceMonitor配置错误	kubectl get servicemonitor -o yaml
Prometheus容器不断重启	内存不足	kubectl describe pod prometheus-0
Grafana无法登录	密码被重置	kubectl exec -it grafana-pod -- grafana-cli admin reset-admin-password

7.2 诊断工具箱

这些命令能快速定位问题：

bash复制# 检查指标端点是否可达
kubectl run -it --rm debug --image=curlimages/curl -- curl http://prometheus:9090/metrics

# 查看Prometheus日志
kubectl logs -f prometheus-0 -c prometheus

# 检查服务发现状态
kubectl port-forward svc/prometheus 9090
open http://localhost:9090/targets

经过三个月的生产验证，这套监控体系成功将我们的平均故障发现时间从47分钟缩短到2.3分钟。最关键的经验是：监控不是简单的工具堆砌，而需要持续优化指标和告警阈值，就像调整显微镜的焦距一样，既要看到细节又不失全局。