16.8.1 监控指标体系与告警设计

监控指标体系与告警设计应围绕集群层、节点层、控制面层、工作负载层与业务层建立统一指标模型，覆盖可用性、性能、容量与错误率四类核心维度。统一指标命名与标签规范，强调可聚合性与可追溯性，避免高基数标签以控制存储与查询成本。

原理草图（指标采集—存储—告警—通知闭环）：

关键指标分层清单（示例）
- 集群与控制面：API Server 请求延迟与错误率、etcd 读写延迟与磁盘使用、scheduler/controller 队列长度与失败率、核心组件重启次数。
- 节点与资源：CPU/内存/磁盘/网络使用与饱和度、节点 NotReady 次数、cgroup OOM、容器重启与镜像拉取失败。
- 工作负载：Pod 就绪率、Replica 不足、HPA 扩缩容次数与失败、P95/P99 延迟、错误率与吞吐量。
- 业务指标：成功率、关键路径延迟、订单/交易 KPI，并与技术指标建立映射。

安装与接入示例（Prometheus + Alertmanager + 基础采集）#

以 kube-prometheus-stack 为例快速落地（含 Prometheus/Alertmanager/Grafana）：

# 1) 添加 Helm 仓库
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# 2) 安装到 monitoring 命名空间
kubectl create ns monitoring

helm install kps prometheus-community/kube-prometheus-stack \
  -n monitoring \
  --set prometheus.prometheusSpec.retention=15d \
  --set grafana.enabled=true \
  --set alertmanager.enabled=true

# 3) 验证 Pod 状态
kubectl -n monitoring get pods

预期效果：出现 kps-prometheus-kube-prometheus-stack-0、kps-alertmanager-0、kps-grafana 等 Pod，状态为 Running。

关键配置示例（指标命名与标签规范）#

在服务中埋点时控制标签：

# 指标命名示例：<域>_<对象>_<度量>_total/seconds/bytes
# labels 限制在: env, cluster, namespace, app, version, instance
metrics:
  name: "http_server_requests_total"
  labels:
    env: "prod"
    cluster: "k8s-prod-01"
    namespace: "order"
    app: "order-api"
    version: "v1"

说明：避免把 user_id、order_id 等高基数标签写入指标。

告警规则示例（SLO/燃尽率 + 多条件）#

创建告警规则文件 /etc/prometheus/rules/slo-burnrate.yaml：

groups:
- name: slo-burnrate
  rules:
  - alert: APIErrorBurnRateFast
    expr: |
      (
        sum(rate(http_server_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_server_requests_total[5m]))
      ) > 0.02
    for: 5m
    labels:
      severity: "P1"
      team: "platform"
    annotations:
      summary: "5xx 错误率过高（快速燃尽）"
      description: "5分钟内错误率超过2%，请检查上游依赖与最近发布"

  - alert: NodeCPUHigh
    expr: |
      (1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))) > 0.85
    for: 10m
    labels:
      severity: "P2"
      team: "infra"
    annotations:
      summary: "节点 CPU 持续高使用率"
      description: "CPU 使用率超过85%持续10分钟，检查热点 Pod"

将规则挂载到 Prometheus（kube-prometheus-stack 可通过 prometheusRule 资源管理）：

kubectl -n monitoring apply -f /etc/prometheus/rules/slo-burnrate.yaml

Alertmanager 路由示例（分级、抑制、升级）#

# /etc/alertmanager/alertmanager.yaml
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster', 'namespace', 'app']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 2h
  routes:
  - matchers:
      - severity="P1"
    receiver: "oncall-p1"
    continue: true
  - matchers:
      - severity="P2"
    receiver: "oncall-p2"

receivers:
- name: "default"
  webhook_configs:
  - url: "http://webhook.default.svc:8080/notify"

- name: "oncall-p1"
  webhook_configs:
  - url: "http://webhook.p1.svc:8080/notify"

- name: "oncall-p2"
  webhook_configs:
  - url: "http://webhook.p2.svc:8080/notify"

inhibit_rules:
- source_matchers:
  - severity="P1"
  target_matchers:
  - severity="P2"
  equal: ['cluster', 'namespace', 'app', 'alertname']

告警内容模板（强制可行动）#

每条告警必须包含：问题描述、影响范围、初步诊断线索、关联仪表盘、标准处置与回滚建议。
示例注释：

annotations:
  summary: "Pod 就绪率下降"
  description: "order-api 就绪率低于95%，影响订单创建接口"
  runbook: "http://docs/runbooks/k8s/order-api-ready"
  dashboard: "http://grafana/d/order-api"

排错示例（告警未触发 / 误报）#

1) 告警未触发

# 检查规则是否加载
kubectl -n monitoring port-forward svc/kps-prometheus-kube-prometheus-stack 9090:9090

# 在 Prometheus UI 中验证规则与表达式
# http://127.0.0.1:9090/alerts
# http://127.0.0.1:9090/rules

# 直接执行表达式，观察是否返回数据
# http://127.0.0.1:9090/graph?g0.expr=rate(http_server_requests_total[5m])

可能原因：指标未采集、标签过滤错误、Prometheus 规则未加载。

2) 告警误报

# 检查高频抖动源
kubectl -n monitoring port-forward svc/kps-alertmanager 9093:9093
# 访问 http://127.0.0.1:9093 查看告警聚合/抑制

# 将 for 时间从 1m 提高到 5m，避免瞬时峰值触发

命令解释示例（关键命令意图）#

helm install kps prometheus-community/kube-prometheus-stack -n monitoring
# 安装监控栈，包含 Prometheus/Alertmanager/Grafana 及常用 Exporter

kubectl -n monitoring get pods
# 验证组件是否正常启动，排查 CrashLoopBackOff

练习#

1) 为 kube-system 命名空间新增“API Server 错误率 > 1% 持续 10 分钟”告警。
2) 设计一个“节点磁盘使用 > 80% 持续 30 分钟”的告警，并配置抑制规则：当 P1 告警存在时抑制 P2。
3) 构建一个仪表盘：全局健康（集群）、服务视图（命名空间）、实例视图（Pod），并确保告警附带对应链接。
4) 模拟错误率上升（用压测或故意返回 500），验证燃尽率告警从触发到通知的链路是否闭环。