生产级 Kubernetes 可观测性体系：从指标到故障闭环

很多团队第一次给 Kubernetes 集群接入监控时，会把目标理解为“装一个 Prometheus，再放几个 Grafana 大盘”。这只是开始。生产级可观测性的核心不是看见更多曲线，而是在业务异常、容量风险、发布回滚、节点抖动、网络丢包和证书过期发生时，团队能够快速判断影响面、定位责任域、执行修复动作，并在事后把经验沉淀为规则。

一套可用的 K8s 可观测性体系至少包含六层：集群基础指标、工作负载指标、应用业务指标、日志检索、分布式追踪、事件与告警。真正成熟的团队会把这些信号串起来，而不是把它们散落在不同工具里。

指标分层

集群层指标回答“平台是否健康”。重点包括节点 CPU、内存、水位、磁盘 inode、网络吞吐、kubelet 状态、APIServer 请求延迟、etcd 延迟、控制器队列深度、调度失败次数等。

工作负载层指标回答“应用是否按预期运行”。常见指标包括 Pod 重启次数、容器 OOMKilled、Deployment 可用副本数、HPA 扩缩容状态、PVC 使用率、Ingress 5xx、Service Endpoint 数量、Pod Pending 时长。

业务层指标回答“用户是否受影响”。这部分不能只靠平台团队提供，必须由应用方暴露，例如订单创建成功率、支付延迟、队列堆积、登录错误率、核心接口 p95 延迟、每分钟请求数。

一个常见误区是只监控资源使用率。CPU 使用率高不一定是故障，用户请求失败率上升才是更强的事故信号。建议告警优先级按用户影响排序：业务错误率、核心路径延迟、入口可用性、数据一致性、容量水位、平台组件异常。

Prometheus 采集模型

Prometheus 适合 K8s 的原因是它天然支持服务发现和标签维度。建议使用 kube-prometheus-stack 或等价方案作为基线，但要避免把默认规则直接当成生产规则。默认规则覆盖面广，噪音也可能很大。

生产环境中建议为不同对象建立清晰标签约定：

• cluster：集群名，便于多集群聚合。
• namespace：团队或环境边界。
• workload：Deployment、StatefulSet 或 Job 名称。
• app：业务应用名。
• env：prod、staging、dev。
• team：责任团队。

标签治理非常重要。高基数字段不要随意进入指标标签，例如 user_id、request_id、订单号。高基数会迅速推高 Prometheus 内存压力，让监控系统本身成为风险点。

告警规则设计

告警要服务于行动。一个没人处理、没有上下文、无法判断影响面的告警，本质上是噪音。建议每条生产告警具备四个要素：触发条件、持续时间、影响说明、处理入口。

示例规则：

groups:
  - name: workload-availability
    rules:
      - alert: DeploymentReplicasUnavailable
        expr: kube_deployment_status_replicas_available < kube_deployment_spec_replicas
        for: 10m
        labels:
          severity: warning
          domain: workload
        annotations:
          summary: "Deployment 可用副本不足"
          description: "namespace={{ $labels.namespace }}, deployment={{ $labels.deployment }} 可用副本低于期望副本超过 10 分钟。"
          runbook: "检查 rollout 状态、Pod 事件、镜像拉取、资源配额和节点调度。"

不要对瞬时抖动过于敏感。K8s 本身是动态系统，滚动发布、节点漂移、镜像拉取、探针失败都可能造成短暂波动。for 字段应根据业务容忍度设定。对用户影响强的入口可用性可以更短，对容量水位可以更长。

日志与事件

日志系统建议至少支持按 namespace、pod、container、trace_id、level、时间范围检索。K8s 日志采集通常用 DaemonSet 部署 Fluent Bit、Vector 或 Promtail，将日志送入 Loki、Elasticsearch、OpenSearch 或云厂商日志服务。

事件是 K8s 排障中经常被忽略的信号。kubectl describe pod 中的 Events 可以直接告诉你调度失败、镜像拉取失败、健康检查失败、卷挂载失败等原因。生产环境建议用 event-exporter 将事件持久化，否则事件会被快速轮转。

关键事件建议纳入告警：

• FailedScheduling
• FailedMount
• ImagePullBackOff
• BackOff
• Unhealthy
• NodeNotReady

分布式追踪

当请求跨越多个微服务时，仅靠日志和指标很难回答“慢在哪里”。分布式追踪可以展示一次请求经过的服务、耗时、错误点和上下游依赖。建议优先采用 OpenTelemetry 标准，减少对某个后端系统的绑定。

落地时要注意采样策略。全量采样通常成本过高，可以采用头部采样与尾部采样结合：正常请求低比例采样，错误请求和慢请求提高采样率。对核心交易链路，可以设置更高采样比例。

仪表盘不是越多越好

Grafana 大盘应围绕角色设计。SRE 需要集群健康视图，应用团队需要服务视图，值班人员需要事故视图，管理者需要稳定性和容量趋势。一个大盘塞满所有指标会降低判断效率。

推荐的核心大盘：

• 集群总览：节点、Pod、APIServer、etcd、调度、控制器。
• 命名空间视图：资源请求、实际使用、配额、重启、错误率。
• 工作负载视图：副本、发布状态、探针、容器资源、日志入口。
• 入口流量视图：Ingress 请求量、延迟、状态码、上游错误。
• SLO 视图：可用性、错误预算、核心业务指标。

从告警到故障闭环

可观测性最终要进入故障管理流程。一次事故结束后，应回看三个问题：告警是否提前发现，仪表盘是否帮助定位，日志和追踪是否足够解释原因。如果答案是否定的，就要补规则、补指标、补上下文。

成熟的闭环包括：

1. 告警触发并进入值班渠道。
2. 值班人员根据 runbook 判断影响面。
3. 通过指标、事件、日志、追踪定位责任域。
4. 执行回滚、扩容、隔离或配置修复。
5. 复盘根因并更新告警、仪表盘、发布策略。

生产建议

把监控系统当成生产系统维护。Prometheus、Alertmanager、日志后端、追踪后端都需要容量规划、备份、权限控制和自监控。监控系统宕机时，业务未必立即中断，但团队会失去驾驶舱。

最后记住一个原则：可观测性不是工具堆叠，而是工程组织的反馈系统。它把集群、应用和团队动作连接起来，让问题更早暴露、影响更快收敛、经验更容易复用。