Java 可观测性
指标、日志、追踪三位一体：如何让服务在生产中可提问、可定位。
#concept
#growing
#dev
#java
[!info] related notes
Java 可观测性
这个概念为什么出现
服务变慢或出错时，需要回答：哪条路径、哪个依赖、多少错误、哪个实例。可观测性把日志、指标、追踪连成可查询证据。
[!abstract] 一句话理解 指标描述整体健康，日志提供事件细节，追踪连接一次请求的跨服务因果；用传播上下文关联日志与追踪，指标通过聚合维度或 exemplars 关联诊断信息；不要把每个请求 ID 放进指标标签。
最小可运行示例
场景：为请求生成 correlation id 并打日志
import java.util.UUID;
import java.util.logging.Logger;
public class CorrelationDemo {
private static final Logger log = Logger.getLogger(CorrelationDemo.class.getName());
static void handle() {
String cid = UUID.randomUUID().toString();
log.info(() -> "cid=" + cid + " event=start");
log.info(() -> "cid=" + cid + " event=done");
}
public static void main(String[] args) { handle(); }
}javac CorrelationDemo.java && java CorrelationDemo默认 JUL 配置下，两条消息包含同一 cid。这里只演示进程内日志关联，没有生成 span、导出指标或传播 HTTP 上下文，不能据此声称已经接入分布式追踪。
结合场景再看三个关注点
- 跨服务需传播上下文；生产链路通常使用 W3C traceparent/tracestate 和 OpenTelemetry propagator。任意 UUID correlation id 不自动成为合法 trace context。
- RED/USE 指标思维。
- 采样追踪控成本。
核心概念与准确模型
1. 日志、指标与追踪
日志记录事件，指标聚合随时间变化的测量，追踪由带父子关系/链接的 span 表达调用关系。共享一个 cid 有助于检索，但本身不能证明因果顺序。
2. OpenTelemetry / Micrometer 生态
OpenTelemetry 提供埋点、上下文传播和信号导出能力，不是存储查询后端；Micrometer 常提供 Java 指标门面及后端适配。接入还需配置 SDK/registry、exporter 与接收端，避免重复埋点。
3. SLO 与告警
先定义用户可感知的 SLI、统计窗口与目标，再制定告警。RED 关注请求速率、错误与耗时，USE 关注资源利用率、饱和度与错误；它们是排查视角，不是装好大盘就自动获得的可靠性保证。
边界情况与反直觉行为
- userId、requestId 或包含动态 ID 的原始 URL 不宜作为普通指标标签；优先使用有界的路由模板、状态类别等维度。
- 日志含 PII。
- 只加工具不加黄金指标。
常见误区
[!warning] 常见误区：有仪表盘=可观测 还要能按请求钻取因果。
工程实践
- 统一上下文传播规则，沿用合法上游上下文或在入口创建；异步任务也要传播/清理上下文，不能假设线程切换会自动保留。
- 错误率/延迟分位/饱和度。
- 依赖分类隔离。
- 演练“无日志也能定位吗”。
本节总结
- 日志+指标+追踪
- 关联是关键
- 服务可靠性底座
自测题
- 高基数标签为何危险？
- 追踪采样的权衡？
参考答案
- 时间序列爆炸、成本与查询变差。
- 成本 vs 罕见问题可见性。
延伸阅读与资料来源
| 资料 | 类型 | 支撑内容 |
|---|---|---|
| OpenTelemetry | 标准/项目 | 可观测 |
| Micrometer | 库 | Java 指标 |
Digital Biome