Micrometer ObservationAPI中DefaultMeterObservationHandler不支持高基数值问题

1. Observation.Context设置高基数值的意义 #

Observation API不是专为指标设计的，它是全链路观测的上下文容器。你放入的requestId、conversationId这类高基数值，核心作用是在单次请求/会话的全链路中传递上下文——比如给日志打唯一标识、给分布式链路追踪提供请求关联依据，让不同环节的观测数据能绑定到同一个请求实例，而非给指标提供标签。

2. 高基数值能不能作为指标额外上下文发布？ #

绝对不建议，强行操作会引发严重问题：

• 从Micrometer机制来看：MeterRegistry会为每个「指标名+标签组合」创建独立的计量器实例。高基数标签意味着每个请求都会生成新的计量器，短时间内就会耗尽内存引发OOM。
• 从监控设计逻辑来看：指标的核心是聚合统计（比如统计某接口的QPS、平均响应时间），高基数标签会让聚合失去意义——你不可能统计每个requestId的请求量，这根本不是指标的使用场景。

3. 指标与日志的关联方法 #

既然高基数信息适合放在日志里，要关联两者，核心是共享唯一追踪标识：

• 利用Observation自带的追踪ID：Observation会自动生成或继承traceId/spanId，你可以把这些ID放入日志框架的MDC（如Logback/Log4j2的MDC），让每条日志都带上标识。同时指标保留低基数标签（如接口名、HTTP方法、状态码），借助APM工具就能通过指标维度定位到对应日志集合，再用traceId找到具体请求的日志详情。
• 自定义关联维度：如果不用APM工具，可在指标里保留低基数维度（比如endpoint），日志里同时带上endpoint和requestId。后续通过日志系统检索，先根据指标的endpoint筛选对应日志，再定位到具体请求的日志内容。

关于动态标签的提醒 #

网上提到的动态标签方案，只适用于有限基数的动态值（比如用户类型、环境标识），绝对不能用于requestId这类高基数场景，否则必然触发内存泄漏，完全违背Micrometer的设计原则。

内容的提问来源于stack exchange，提问作者John Edwards