新系统上线后偶发慢请求但无法复现，让你设计可观测体系，你会采集什么并怎么关联？
我的判断
偶发慢请求要让日志、指标、trace 和运行时剖析通过 traceId、实例与时间关联，先定位慢在哪一段，再保留足够现场。
每个入口生成或透传 traceId，span 记录服务、实例、接口、下游、数据库语句指纹、状态和耗时，不能把用户隐私和完整 SQL 参数全打进去。日志使用结构化字段，至少能按 traceId、订单号、错误码和实例查询。
指标会同时覆盖 RED 和资源饱和度：请求率、错误率、P50/P95/P99；线程池队列、连接池等待、GC、CPU、磁盘；数据库扫描与锁、Kafka lag、缓存命中。告警以用户影响和持续时间为主，避免每个节点抖一下就报警。
trace 采用头部采样会漏掉偶发慢请求，所以关键链路会保留错误和高延迟尾部采样，或在入口记录轻量慢请求索引。实例出现尖刺时触发一段 JFR/async-profiler，和同时间 trace 对齐。
仪表盘要能从“接口 P99 上升”下钻到具体下游、实例和资源。最后用故障演练验证：制造连接池耗尽、慢 SQL 或 GC，确认告警能发现、trace 能定位、日志能解释。
思路拆解问题分析
可观测性不是把三套工具装上。真正目标是让一次用户请求的 业务标识、调用路径、资源状态和代码现场 在同一时间轴上互相跳转。
容易答偏踩坑误区
- 日志全量打印请求与响应。 成本、隐私和检索噪声都会失控。
- 只看平均延迟。 偶发问题正好藏在 P99 和少数实例里。
- 采样完全随机。 低频错误和长尾请求可能一条都留不下。