Kubernetes 集群的运维面板上往往堆满了节点 CPU、内存和磁盘指标，但这些资源数据并不能直接回答一个核心问题：用户当前访问应用时是否顺畅。一个节点的 CPU 使用率达到 80% 可能只是批处理任务在正常运行，用户的订单请求却可能因为某个组件超时已经失败。用户体验指标采集的目标，是把监控视角从底层资源切换到用户请求链路，用延迟、错误率、吞吐量和满意度分数来刻画真实服务质量。
一、为什么资源指标无法代替用户体验指标
资源监控擅长回答节点是否繁忙，但不擅长回答用户是否满意。USE 方法从利用率、饱和度和错误三个维度分析资源，对容量规划和故障定位很有帮助；而面向用户的 RED 方法关注请求速率、错误数和耗时，这三项指标直接对应了用户在一次访问中的感受。举个例子，一个 Java 应用的堆内存使用率稳定在 70%，但 Full GC 导致应用线程停顿，请求延迟 P99 可能从 300 毫秒飙升到 5 秒。只看内存曲线很难发现这次停顿，而请求延迟指标会立刻暴露问题。
在 Kubernetes 中，Pod 重启、HPA 扩缩容、网络策略变更、服务端点更新等操作都可能造成短暂请求失败。如果只监控容器资源，这些失败会被平均化甚至被忽略。用户体验指标则不同，它从入口流量和服务调用中直接获取每一次请求的结果，能够捕捉到用户真实感受到的抖动和不可用。因此，采集体系必须将应用层指标与基础设施指标分开设计，避免用资源健康度掩盖服务质量问题。
二、关键指标与数据来源设计
一个完整的 Kubernetes 用户体验指标采集体系通常覆盖四类指标：请求延迟、错误率、吞吐量和满意度分数。请求延迟建议同时采集 P50、P95 和 P99 分位数，因为平均值容易被长尾请求拉高；错误率需要区分 4xx 客户端错误和 5xx 服务端错误；吞吐量可以按每秒请求数或每分钟业务操作数统计；满意度分数常用 Apdex，它把响应时间划分为满意、可容忍和失望三个区间，输出 0 到 1 的分数。
| 指标类别 | 推荐指标 | 主要数据来源 |
|---|---|---|
| 请求延迟 | P50、P95、P99 | 服务网格、OpenTelemetry SDK、Ingress 日志 |
| 错误率 | 5xx 比例、业务失败数 | 入口网关、应用埋点 |
| 吞吐量 | 每秒请求数、每分钟业务操作数 | 应用指标、网关日志 |
| 满意度 | Apdex、首屏时间 | Prometheus 计算、前端 RUM |
数据来源可以分成四层。入口层从 Ingress Nginx、Envoy 或 Gateway API 获取流量日志，这些数据包含了外部用户访问应用的完整路径。服务层通过 OpenTelemetry SDK、Micrometer 或 Prometheus 客户端直接上报业务指标，例如订单创建耗时、支付失败次数。基础设施层由 kube-state-metrics 和 Metrics Server 提供 Pod 状态、资源请求与限制等数据，用于关联用户指标和资源事件。前端层则可以引入真实用户监控，采集首屏时间、白屏时间和交互延迟，进一步还原浏览器端的体验。
设计指标时还要注意标签治理，例如为每个指标统一附加 service、namespace、cluster、environment 等标签。标签数量过多会推高 Prometheus 的基数，因此不要将订单号、用户 ID 等高基数字段作为指标标签，这些信息更适合放在日志或链路追踪中。
三、使用 OpenTelemetry Collector 统一采集指标
OpenTelemetry Collector 可以作为统一的数据接收和转发层，应用通过 OTLP 协议将指标推送到 Collector，再由 Collector 写入 Prometheus。这种方式的优点是应用无需直接暴露 Prometheus 抓取端点，也便于在基础设施侧做批量处理和过滤。以下是一个简化版 Collector 配置，接收 OTLP 指标并转发到 Prometheus remote write。
receivers:
otlp:
protocols:
grpc:
http:
exporters:
prometheusremotewrite:
endpoint: http://prometheus-remote-write:9201/write
service:
pipelines:
metrics:
receivers: [otlp]
exporters: [prometheusremotewrite]
上面的配置会在 Collector 中启动 gRPC 和 HTTP 两个 OTLP 接收端口。应用只需要配置 OpenTelemetry SDK 的 exporter 指向 Collector 的 OTLP 端点，就能将请求耗时、错误计数等指标发送出去。Collector 可以使用 Deployment 或 DaemonSet 部署在集群中，如果应用分布在多个命名空间，建议通过 Service 暴露稳定地址，并在应用侧配置重试和超时。
对于已有 Prometheus 客户端库的应用，可以继续使用 Prometheus 抓取方式。在 Pod 上添加 annotations，让 Prometheus 自动发现并抓取 /metrics 端点。这样不需要修改业务代码，也能快速接入现有服务。两种方式可以并存，关键是指标命名和标签需要统一，否则后续聚合计算会非常痛苦。
四、计算 Apdex 与配置体验告警
Apdex 的计算公式是满意请求数加上可容忍请求数的一半，再除以总请求数。假设满意阈值设为 300 毫秒，可容忍阈值设为 1200 毫秒，那么响应时间低于 300 毫秒的请求记为满意，300 到 1200 毫秒之间记为可容忍，超过 1200 毫秒记为失望。通过 PromQL 的 histogram 数据类型可以方便地实现这一计算。
(
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (service)
+
sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) by (service)
) / 2 / sum(rate(http_request_duration_seconds_count[5m])) by (service)
这段 PromQL 先计算 5 分钟内落在这两个桶以下的请求速率，求和之后除以总请求速率的两倍，得到 Apdex 分数。需要注意的是，histogram 的桶边界必须与应用实际耗时分布匹配，如果桶设置太大，Apdex 会失去区分度；如果桶设置太小，则会增加指标基数。
除了 Apdex，错误率和延迟也是告警的重要来源。下面配置一个 PrometheusRule，当某个服务 5 分钟内的 5xx 错误率超过 1% 时触发告警。
groups:
- name: user-experience
rules:
- alert: HighErrorRate
expr: sum(rate(http_requests_total{status=~"5.."}[5m])) by (service) / sum(rate(http_requests_total[5m])) by (service) > 0.01
for: 5m
labels:
severity: warning
annotations:
summary: 服务错误率超过1%
告警规则中使用了正则匹配 status=~"5.." 来筛选所有 5xx 状态码。错误率阈值需要结合业务容忍度设置，例如支付服务可以设为 0.5%，后台管理页面可以放宽到 2%。避免使用固定阈值，优先结合 Apdex 和延迟分位数一起判断，减少误报。
落地后还要持续优化采集体系。指标保留时间、采集频率和标签治理需要定期回顾，避免 Prometheus 存储压力过大。同时可以将用户体验指标与 Kubernetes 事件关联，例如当 Apdex 下降时快速定位是否发生 Pod 重启、节点驱逐或滚动发布。只有把用户指标嵌入日常发布和故障处理流程，采集才算真正产生价值。
Kubernetes用户体验指标Prometheus修改时间：2026-08-25 06:57:50