团队为HTTP请求耗时指标增加标签，候选标签有service、route、status_code、user_id和trace_id。为了控制指标系统的时间序列规模，最不适合作为该指标标签组合的是（）。
用户、订单和链路ID的取值近乎无界，会为大量请求创建独立时间序列，增加内存、存储和查询成本。个体请求定位更适合用日志或链路追踪。
选项分析
通常可接受。这些标签取值相对有限，便于按服务、接口和状态聚合。
通常可接受。固定枚举不会随每个用户和请求无限增长。
正确。多个近乎唯一的标签会造成严重的时间序列基数膨胀。
通常可接受，但仍应控制环境和错误类别的枚举范围。
本题为什么容易错
监控越细不一定越好。指标系统擅长回答“哪类请求变慢”，日志和追踪擅长回答“这一笔请求发生了什么”，把两类任务混在一起会付出很高成本。
简短答案
为什么不能把userId和traceId直接作为监控指标标签，正确答案是 C（user_id、trace_id、order_id）。用户、订单和链路ID的取值近乎无界，会为大量请求创建独立时间序列，增加内存、存储和查询成本。个体请求定位更适合用日志或链路追踪。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| service、route、status_code | 本题干扰项 | 通常可接受。这些标签取值相对有限，便于按服务、接口和状态聚合。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| service、route、固定枚举的请求结果 | 本题干扰项 | 通常可接受。固定枚举不会随每个用户和请求无限增长。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| user_id、trace_id、order_id | 本题正确答案 | 正确。多个近乎唯一的标签会造成严重的时间序列基数膨胀。 | 看到题干核心场景时优先联想到它 |
| service、部署环境、有限的错误类别 | 本题干扰项 | 通常可接受，但仍应控制环境和错误类别的枚举范围。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- service、route、status_code：通常可接受。这些标签取值相对有限，便于按服务、接口和状态聚合。
- service、route、固定枚举的请求结果：通常可接受。固定枚举不会随每个用户和请求无限增长。
- service、部署环境、有限的错误类别：通常可接受，但仍应控制环境和错误类别的枚举范围。
知识点详解
每组不同标签值通常对应一条独立时间序列。标签组合数随各维度取值数量相乘增长，因此用户ID、邮箱、订单号、请求ID等无界字段会迅速放大基数。可靠的指标设计应采用受控维度，并为指标系统设置基数监控和采集预算。
备考速记
指标看群体，日志追个体；唯一ID别拿来做指标标签。
时间序列在时间序列场景中的作用
HTTP指标保留service、route模板和status_code；发生慢请求后，从指标上的示例或日志找到traceId，再进入链路追踪查看具体调用。这样既能聚合，也能下钻。
同类题怎么考
- 识别导致时间序列爆炸的高基数标签。
- 区分指标、日志和链路追踪的适用问题。
时间序列在系统架构设计师软考中的考法
看到label设计题，优先找唯一ID、原始路径和自由文本。它们通常是高基数来源；固定枚举和路由模板相对安全。
解题思路
可以用一个简单乘法判断风险。20条路由×5种状态×10个实例，大约1000组；如果再乘100万用户，立刻变成十亿级组合。C中的三个字段都接近每次请求唯一，风险最高。
考点定位
指标标签应优先使用取值范围有限且可聚合的维度。唯一标识符适合做日志字段或追踪属性，不适合做常规指标标签。
易错提醒
- 把原始URL直接作标签，路径中的订单号形成海量取值。
- 错误信息全文作为label，每种文本都生成新序列。
- 只限制单个标签数量，没有估算多个标签组合后的乘积。
备考提示
- 评审指标时估算各标签取值数量的乘积。
- 需要定位单个请求时，用traceId把指标、日志和链路串联，而不是把traceId塞进指标标签。
你可能还想了解
- userId为什么不能作为指标标签？
- 什么是高基数Label？
- 指标、日志和链路追踪怎么分工？
本文小结
近乎唯一的用户、订单和链路ID会造成指标时间序列爆炸，应使用有限标签聚合，并通过日志和追踪定位个体请求。