分布式系统中指标应该如何设计？

简化版

指标设计要围绕服务健康、用户体验和资源容量。常见方法是 RED 和 USE：RED 关注请求量、错误率、耗时；USE 关注资源使用率、饱和度和错误。接口层看 QPS、错误率、P95/P99，资源层看 CPU、内存、连接池、线程池、队列积压。

好的指标要有清晰含义、合理标签、可用于告警和排障。标签不能无限增加，否则会产生高基数问题，导致存储和查询压力爆炸。

详细版

分布式系统指标可以分层设计：入口指标、服务指标、依赖指标、资源指标和业务指标。入口指标看整体流量和成功率；服务指标看每个接口的延迟、错误和吞吐；依赖指标看数据库、缓存、RPC、MQ 的调用情况；资源指标看机器和运行时；业务指标看订单量、支付成功率等业务结果。

指标不仅用于看图，更重要的是告警和定位。比如接口 P99 延迟升高时，要能继续下钻到下游调用耗时、线程池队列、数据库慢查询和错误码分布。

指标标签要谨慎。service、method、status、env、region 这类标签通常有价值；userId、orderId、traceId 这类高基数字段不适合做指标标签，应放日志或 Trace 中。

完整版教学

一、指标回答的是趋势和状态

日志适合看事件，Trace 适合看单次请求，指标适合看整体趋势。比如过去 5 分钟接口错误率是否升高、P99 延迟是否恶化、线程池队列是否堆积，这些都靠指标回答。

指标是告警和容量规划的基础。没有指标，系统只能靠用户投诉发现问题。

二、RED 方法

RED 常用于请求型服务：

Rate：请求速率，比如 QPS。
Errors：错误率，比如 5xx、业务失败、超时。
Duration：耗时，比如平均值、P95、P99。

对于 HTTP/RPC 服务，这三类指标非常核心。一个接口如果 QPS 正常但错误率升高，可能是依赖故障；如果错误率不高但 P99 升高，可能是慢查询、线程池阻塞或下游变慢。

三、USE 方法

USE 常用于资源层：

Utilization：使用率，比如 CPU、内存、磁盘、连接池使用率。
Saturation：饱和度，比如队列长度、线程池排队、磁盘 IO 等待。
Errors：资源错误，比如网络丢包、磁盘错误、连接失败。

USE 能帮助判断系统是不是被资源卡住。比如 CPU 不高但线程池队列很长，可能是下游阻塞而不是计算不足。

四、指标要分层

一个成熟系统通常有：

基础设施指标：CPU、内存、磁盘、网络。
运行时指标：JVM GC、线程数、连接池、线程池。
服务指标：接口 QPS、延迟、错误率。
依赖指标：数据库、缓存、MQ、RPC 调用耗时和错误。
业务指标：订单量、支付成功率、库存扣减成功率。

分层的好处是排障时能从用户影响一路下钻到资源瓶颈。

五、延迟不要只看平均值

平均耗时很容易掩盖问题。比如 99% 请求 20ms，1% 请求 5s，平均值可能看起来还可以，但用户体验已经很差。

所以接口延迟要看 P95、P99、最大值和分布直方图。P99 对排查尾延迟非常重要，尤其在分布式调用链中，一个慢下游就可能拖慢整条链路。

六、标签设计和高基数问题

指标通常由名称和标签组成。标签用于聚合和过滤，例如 service=order、method=createOrder、status=500。

高基数字段会导致时间序列数量爆炸。比如把 userId、orderId、traceId 放入指标标签，每个用户或订单都会生成新的时间序列，存储和查询成本会非常高。

高基数字段更适合放日志或 Trace，不适合作为指标标签。

七、面试回答建议

回答时可以先说 RED 和 USE，再说分层指标：入口、服务、依赖、资源、业务。然后强调 P95/P99、高基数标签和指标用于告警与下钻排障。

如果能举例说明“下单接口 P99 升高如何顺着指标排查”，答案会更有工程味。

八、常见追问和落地边界

面试官常问指标和日志怎么分工。指标用于聚合趋势和告警，日志用于具体事件和上下文。比如“支付失败率 5 分钟内升高到 3%”应该是指标告警；具体失败的是哪些订单、错误码是什么，要查日志或 Trace。

另一个落地边界是指标命名和单位必须统一。latency_ms、latency_seconds 混用会造成误读；同一个错误率指标在不同服务口径不同，也会让告警失真。指标治理要像 API 设计一样规范。

指标还要注意聚合层级。单实例指标适合定位某台机器问题，服务级聚合适合看整体健康，机房级聚合适合判断局部故障。只有单实例指标会太碎，只有全局指标又会掩盖局部异常。一个成熟仪表盘通常能从全局下钻到机房、服务、实例、接口和依赖。

业务指标也不能忽略。技术指标都正常，不代表业务正常。比如下单接口 200 响应很多，但实际订单创建成功率下降，说明业务语义失败没有被技术错误率捕捉。核心业务要有专门成功率和漏斗指标。

九、常见误区与追问

这道题要紧扣「指标设计」本身回答，不能把它混成泛泛的可观测性套话。面试官通常会沿着“为什么需要、流程怎么走、失败怎么兜、代价是什么”继续追问，所以回答要覆盖日志、指标、追踪、上下文传播、采样、告警和排障闭环。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	指标设计要围绕 RED/USE、业务成功率、延迟分位数和资源饱和度，避免高基数标签把系统打爆	不要停在名词解释
流程机制	确定业务目标 -> 选择计数器/直方图/仪表盘 -> 设计标签维度 -> 采集和聚合 -> 设置看板与告警 -> 定期清理无用指标	要说清触发点、状态变化、确认点和失败兜底
工程取舍	接口 P99 从 100ms 升到 800ms，即使平均值还正常，用户体验也可能已经明显变差	可观测性不能替代稳定性设计，它用额外采集、存储和分析成本换更快定位问题

指标设计 面试拆解：
1. 确定业务目标
2. 选择计数器/直方图/仪表盘
3. 设计标签维度
4. 采集和聚合
5. 设置看板与告警
6. 定期清理无用指标

记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「指标设计」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。

误区：指标越细越好。 过多高基数标签会增加存储、查询和成本压力。
误区：平均延迟能代表体验。 要看 P95/P99 等分位数，尾延迟更能暴露问题。
误区：技术指标可以替代业务指标。 CPU 正常不代表下单成功率正常。
追问：RED 指标是什么？ Rate 请求量、Errors 错误数、Duration 耗时。
追问：USE 指标是什么？ Utilization 利用率、Saturation 饱和度、Errors 错误。
追问：什么是高基数标签？ 用户 ID、订单 ID 这类取值巨大标签，会让时序数量爆炸。

十、加强记忆

指标像系统仪表盘。RED 看服务请求是否健康，USE 看资源是否扛得住，业务指标看用户结果是否正常。

指标设计的关键不是多，而是能告警、能定位、成本可控。

简化版

详细版