IT架构师

奔赴山海，保持热爱

0%

K8s 监控告警实战：从 Metrics Server 到 Prometheus 完整指南

发表于 更新于 分类于 ，
本文字数： 8.8k 阅读时长 ≈ 16 分钟
基于 OpenClaw K8s 集群的监控告警实战，包含 Metrics Server、Prometheus、Grafana 部署和真实告警规则配置

K8s 监控告警实战：从 Metrics Server 到 Prometheus 完整指南

写在前面：这篇文章源于今晚（2026-03-10）的真实需求。OpenClaw 部署到 K8s 后，我们需要完整的监控告警体系来保障服务稳定性。这是从 0 到 1 的完整实施过程。

一、背景及痛点分析

1.1 真实场景

没有监控时的状态：

1
2
3
4
5
6
7
8
9
10
2026-03-10 21:30 - OpenClaw Pod 内存超限
2026-03-10 21:35 - Pod OOMKilled 重启
2026-03-10 21:40 - 再次 OOMKilled
2026-03-10 22:00 - 用户反馈服务不可用
2026-03-10 22:10 - 运维排查，发现内存不足
2026-03-10 22:15 - 调整内存限制，服务恢复

❌ 45 分钟才发现故障
❌ 用户先于运维发现问题
❌ 没有历史数据，无法分析根因

遇到的问题：

  1. 无实时监控：

    • 不知道 Pod 资源使用情况
    • 无法预测资源瓶颈
    • 故障响应慢

  2. 无告警通知：

    • Pod 崩溃无人知晓
    • 节点故障无感知
    • 依赖用户反馈

  3. 无历史数据：

    • 无法分析趋势
    • 无法容量规划
    • 故障复盘无数据

1.2 监控需求

监控层级 监控指标 告警阈值
集群层 节点 CPU/内存/磁盘 CPU>80%, 内存>85%
命名空间层 Pod 数量、资源配额 Pod 数>配额 90%
应用层 副本数、重启次数 重启>3 次/小时
业务层 请求延迟、错误率 错误率>1%

1.3 技术方案选型

方案 优势 劣势 适用场景
Metrics Server 轻量、内置 功能简单、无历史数据 基础监控
Prometheus 功能强大、生态好 资源占用高 生产环境 ✅
Datadog 开箱即用、可视化好 费用高 企业付费
阿里云 ARMS 云原生集成 绑定阿里云 阿里云用户

我们的选择：

  • 基础监控：Metrics Server（快速部署）
  • 生产监控：Prometheus + Grafana（完整功能）

二、解决方案：三层监控架构

2.1 架构设计

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
┌─────────────────────────────────────────┐
│          监控告警体系                    │
├─────────────────────────────────────────┤
│                                         │
│  ┌─────────────┐  ┌─────────────┐      │
│  │  Metrics    │  │  Prometheus │      │
│  │   Server    │  │   + Alert   │      │
│  │  (基础监控)  │  │  (高级监控)  │      │
│  └─────────────┘  └─────────────┘      │
│         ↓                ↓              │
│  ┌─────────────────────────────┐       │
│  │       Grafana               │       │
│  │    (可视化仪表盘)            │       │
│  └─────────────────────────────┘       │
│         ↓                               │
│  ┌─────────────────────────────┐       │
│  │    告警通知                 │       │
│  │  (钉钉/企业微信/邮件)        │       │
│  └─────────────────────────────┘       │
│                                         │
└─────────────────────────────────────────┘

2.2 部署策略

阶段 1：Metrics Server（10 分钟）

  • 快速部署
  • 基础监控
  • kubectl top 命令支持

阶段 2：Prometheus Stack（30 分钟）

  • 完整监控
  • 告警规则
  • Grafana 可视化

阶段 3：自定义告警（20 分钟）

  • 业务指标
  • 告警通知
  • 集成 Feishu/钉钉

三、最佳实践案例：OpenClaw 监控部署

3.1 部署 Metrics Server

步骤 1：部署

1
2
3
4
5
6
# 下载官方配置
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 验证
kubectl get pods -n kube-system | grep metrics-server
# 输出：metrics-server-xxx  1/1  Running

步骤 2：验证功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 查看节点资源
kubectl top nodes

# 输出：
# NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
# node-81    1200m        60%    3200Mi          80%
# node-82    800m         40%    2400Mi          60%
# node-83    600m         30%    1600Mi          40%

# 查看 Pod 资源
kubectl top pods -n openclaw

# 输出：
# NAME                       CPU(cores)   MEMORY(bytes)
# openclaw-gateway-xxx       500m         2500Mi

步骤 3：配置自动扩缩容（HPA）

1
2
3
4
5
6
7
8
9
10
11
12
13
# 创建 HPA
kubectl autoscale deployment openclaw-gateway \
  --namespace openclaw \
  --min=1 \
  --max=5 \
  --cpu-percent=80

# 验证
kubectl get hpa -n openclaw

# 输出：
# NAME                 REFERENCE                     TARGETS   MINPODS   MAXPODS   REPLICAS
# openclaw-gateway     Deployment/openclaw-gateway   60%/80%   1         5         1

3.2 部署 Prometheus Stack

使用 Helm 快速部署：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 添加 Helm 仓库
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 创建命名空间
kubectl create namespace monitoring

# 部署 Prometheus Stack
helm install prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set grafana.adminPassword=admin123 \
  --set prometheus.prometheusSpec.retention=15d \
  --set prometheus.prometheusSpec.resources.requests.cpu=500m \
  --set prometheus.prometheusSpec.resources.requests.memory=1Gi

# 验证
kubectl get pods -n monitoring
# 输出：
# prometheus-kube-prometheus-operator-xxx   1/1  Running
# prometheus-prometheus-xxx                 2/2  Running
# prometheus-grafana-xxx                    1/1  Running
# prometheus-alertmanager-xxx               2/2  Running

访问 Grafana：

1
2
3
4
5
6
7
# 端口转发
kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80

# 访问
# http://localhost:3000
# 用户名：admin
# 密码：admin123

3.3 配置自定义告警规则

创建 OpenClaw 告警规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# openclaw-alerts.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: openclaw-alerts
  namespace: monitoring
  labels:
    release: prometheus
spec:
  groups:
  - name: openclaw
    interval: 30s
    rules:
    # Pod 重启告警
    - alert: OpenClawPodRestarting
      expr: increase(kube_pod_container_status_restarts_total{namespace="openclaw"}[1h]) > 3
      for: 0m
      labels:
        severity: warning
      annotations:
        summary: "OpenClaw Pod 频繁重启"
        description: "Pod {{ $labels.pod }} 1 小时内重启 {{ $value }} 次"
    
    # Pod Pending 告警
    - alert: OpenClawPodPending
      expr: kube_pod_status_phase{namespace="openclaw",phase="Pending"} == 1
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "OpenClaw Pod Pending 时间过长"
        description: "Pod {{ $labels.pod }} Pending 超过 5 分钟"
    
    # 内存使用率高告警
    - alert: OpenClawHighMemoryUsage
      expr: (container_memory_usage_bytes{namespace="openclaw",container="openclaw"} / container_spec_memory_limit_bytes{namespace="openclaw",container="openclaw"}) * 100 > 85
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "OpenClaw 内存使用率高"
        description: "内存使用率 {{ $value }}%"
    
    # CPU 使用率高告警
    - alert: OpenClawHighCPUUsage
      expr: (rate(container_cpu_usage_seconds_total{namespace="openclaw",container="openclaw"}[5m]) / container_spec_cpu_quota{namespace="openclaw",container="openclaw"}) * 100000 > 80
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "OpenClaw CPU 使用率高"
        description: "CPU 使用率 {{ $value }}%"
    
    # 服务不可用告警
    - alert: OpenClawServiceDown
      expr: probe_success{job="openclaw-health"} == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "OpenClaw 服务不可用"
        description: "OpenClaw 服务已宕机超过 1 分钟"

应用告警规则：

1
2
3
4
kubectl apply -f openclaw-alerts.yaml

# 验证
kubectl get prometheusrules -n monitoring

3.4 配置告警通知（Feishu 集成）

Alertmanager 配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# alertmanager-config.yaml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname']
  group_wait: 10s
  group_interval: 10s
  repeat_interval: 1h
  receiver: 'feishu-webhook'
  routes:
  - match:
      severity: critical
    receiver: 'feishu-webhook'
  - match:
      severity: warning
    receiver: 'feishu-webhook'

receivers:
- name: 'feishu-webhook'
  webhook_configs:
  - url: 'http://openclaw-gateway.openclaw.svc.cluster.local:18789/alerts/feishu'
    send_resolved: true

应用配置：

1
2
3
4
5
6
7
# 创建 Secret
kubectl create secret generic alertmanager-openclaw-alerts \
  --from-file=alertmanager.yaml=alertmanager-config.yaml \
  -n monitoring

# 重启 Alertmanager
kubectl rollout restart statefulset prometheus-kube-prometheus-alertmanager -n monitoring

四、深度思考体会

4.1 为什么选择 Prometheus？

我对比过多个方案：

维度 Prometheus Zabbix Nagios
云原生支持 ⭐⭐⭐⭐⭐ ⭐⭐ ⭐
配置复杂度 ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐
查询语言 PromQL（强大） SQL 简单
生态系统 极其丰富 一般 一般
学习曲线 中等 陡峭 平缓

我的结论：

K8s 环境，Prometheus 是唯一选择。云原生、生态好、社区活跃。

4.2 告警规则设计原则

核心思想：

告警是为了行动，不是为了噪音

设计原则：

  1. 可行动性：

    • 收到告警后知道做什么
    • 避免”狼来了”效应

  2. 分级告警：

    • P0（Critical）：立即响应（电话）
    • P1（Warning）：工作时间处理（钉钉）
    • P2（Info）：记录即可（邮件）

  3. 避免告警风暴：

    • 合理设置阈值
    • 使用告警分组
    • 设置静默时间

4.3 监控指标的选择

四个黄金指标（Google SRE 推荐）：

  1. 延迟（Latency）：处理请求需要的时间
  2. 流量（Traffic）：系统需求的数量
  3. 错误（Errors）：请求失败的比率
  4. 饱和度（Saturation）：系统资源的利用率

我的实践：

1
2
3
4
5
6
7
8
9
10
11
12
# 延迟
http_request_duration_seconds

# 流量
http_requests_total

# 错误
http_requests_errors_total

# 饱和度
container_memory_usage_bytes
container_cpu_usage_seconds_total

五、踩坑记录

5.1 坑 1：Metrics Server 启动失败

问题：

1
2
3
4
kubectl logs metrics-server-xxx -n kube-system

# 输出：
# Error: unable to load CA bundle

原因：

  • K8s 集群使用自签名证书
  • Metrics Server 无法验证

解决：

1
2
3
4
5
6
7
8
9
10
# 编辑 Deployment
kubectl edit deployment metrics-server -n kube-system

# 添加参数
spec:
  containers:
  - name: metrics-server
    args:
    - --kubelet-insecure-tls
    - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP

5.2 坑 2：Prometheus 内存不足

问题：

1
2
3
4
kubectl get pods -n monitoring

# 输出：
# prometheus-prometheus-xxx  0/2  OOMKilled

原因：

  • 默认内存限制 1Gi
  • 监控数据多，内存不足

解决：

1
2
3
4
5
# 升级 Prometheus
helm upgrade prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring \
  --set prometheus.prometheusSpec.resources.limits.memory=4Gi \
  --set prometheus.prometheusSpec.resources.requests.memory=2Gi

5.3 坑 3：Grafana 无法访问

问题：

1
2
3
4
kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80

# 浏览器访问 http://localhost:3000
# 输出：Connection refused

原因：

  • Service 类型是 ClusterIP
  • 端口转发配置错误

解决：

1
2
3
4
5
6
7
8
9
10
11
# 查看 Service
kubectl get svc -n monitoring | grep grafana

# 正确端口转发
kubectl port-forward svc/prometheus-grafana -n monitoring 3000:80

# 或者使用 NodePort
kubectl patch svc prometheus-grafana -n monitoring \
  -p '{"spec": {"type": "NodePort"}}'

# 通过 NodePort 访问

5.4 坑 4：告警规则不生效

问题：

1
2
3
4
5
6
7
kubectl get prometheusrules -n monitoring

# 输出：
# NAME            AGE
# openclaw-alerts  5m

# 但 Prometheus 没有触发告警

原因：

  • PrometheusRule 的 label 不匹配
  • Prometheus 没有发现规则

解决：

1
2
3
4
# 确保 label 匹配
metadata:
  labels:
    release: prometheus  # 必须与 Prometheus 的 serviceMonitor 匹配

六、如何优化改进或扩展

6.1 进一步优化方向

1. 长期存储：

1
2
3
# 使用 Thanos 实现长期存储
helm install thanos thanos-io/thanos \
  --set thanosObjectStorage.config_secret=thanos-objstore-config

2. 日志聚合：

1
2
3
# 部署 Loki + Promtail
helm install loki grafana/loki-stack \
  --set promtail.enabled=true

3. 链路追踪：

1
2
# 部署 Jaeger
helm install jaeger jaegertracing/jaeger

6.2 扩展到其他领域

业务监控：

1
2
3
4
5
6
7
8
9
10
11
12
# 自定义业务指标
- apiVersion: v1
  kind: ServiceMonitor
  metadata:
    name: openclaw-business
  spec:
    selector:
      matchLabels:
        app: openclaw
    endpoints:
    - port: metrics
      path: /metrics/business

多集群监控：

1
2
# 使用 Federation
# Prometheus 联邦集群

6.3 最佳实践总结

监控部署清单：

  • Metrics Server 部署
  • Prometheus Stack 部署
  • Grafana 仪表盘配置
  • 告警规则配置
  • 告警通知配置
  • 验证告警触发

告警规则清单：

  • Pod 重启告警
  • 资源使用率告警
  • 服务可用性告警
  • 磁盘空间告警
  • 节点故障告警

七、总结

7.1 核心要点

  1. Metrics Server - 基础监控，10 分钟部署
  2. Prometheus - 完整监控，支持告警
  3. Grafana - 可视化仪表盘
  4. Alertmanager - 告警通知
  5. 告警规则 - 可行动、分级、避免噪音

7.2 实战经验

这篇文章是今晚 50 分钟实战的总结：

  • 部署 Metrics Server
  • 部署 Prometheus Stack
  • 配置 OpenClaw 告警规则
  • 集成 Feishu 通知

7.3 后续计划

本周：

  • 配置 Grafana 仪表盘
  • 测试告警通知
  • 完善告警规则

本月：

  • 部署 Loki 日志系统
  • 配置业务监控
  • 建立监控文档

本季度：

  • 实现多集群监控
  • 配置长期存储（Thanos）
  • 建立 SLO/SLI 体系

作者：John，高级技术架构师，CrystalForge 项目负责人
时间：2026-03-11 01:05
地点：深圳
项目：OpenClaw K8s 监控告警实战