“可观测性”火了这几年，说到底跟监控的区别就一句话：

监控是你知道要看什么，可观测性是出了你没想到的问题时，你还能找到答案。

前者给你确定性的安全感，后者让你有能力处理不确定的故障。两者不在一个维度上。

三大件里，Metrics、Logging、Tracing，不用一上来全上。我的建议是：先把 Metrics 搞好。

日志你本来就有，问题不是没有日志，是有效的太少。Tracing 等你真的被分布式问题搞痛再说。但 Metrics 不行，CPU、内存、QPS、延迟不看，就真的瞎了。

为什么选 Actuator + Prometheus + Grafana？因为在 Java 生态里，这是标准答案感最强的组合。

Actuator 是 Spring 官方给应用装的探头。JVM、HTTP、线程池、数据源全部暴露出来，不需要你写采集代码。它底下是 Micrometer，类似 SLF4J，今天接 Prometheus，改天公司要上 Datadog，换后面那层就行，应用代码不用动。这个设计的价值是：你做的配置工作不会绑定到某个特定平台。

Prometheus 有意思在它是拉数据，不是等应用推。应用只管暴露端点，Prometheus 自己决定什么时候抓、没抓到怎么办。就算某个实例挂了，之前的数据还在。设计上就比推模式更健壮。

Grafana 做看板就是做得最好。而且社区积累了大量现成的 Spring Boot 看板，你不用从零开始画。

这三件套跑起来快，但真正花时间的不是装环境，而是三件事。

第一，你到底要看什么。JVM 指标上百个，HTTP 几十个，不是每样都要看。我自己的习惯是分梯队：先看服务还活着不，再看用户是不是在遭罪，看 QPS、错误率、P99 延迟，最后才看上一步的诊断依据——CPU、内存、GC、连接池。

第二，告警怎么设。指标多不等于每个都配告警，不然一周几百条告警通知，不到一个月人就麻了。告警应该用在你已经知道会出问题的地方，看板才是用来发现你不知道的问题的。这个搞反了就全白搭。

第三，心态上要接受永远看不到全部。可观测性的目标不是全知全能，而是在关键路径上有足够的信息快速做判断。

实际上手也会遇到麻烦。

指标爆炸最常见。每个 API 路径、每个状态码都单独记录，几万个时间序列一下就上去了。要有意识地做聚合，别什么东西都往里扔。

存储也是硬伤。Prometheus 本地存不了太久，真要长期保留就得接 Thanos 或者 VictoriaMetrics，要么接受近期精确、历史只留聚合值的妥协。

还有一个容易忽略的——看板本身也要维护。隔段时间就要加点新指标、调个阈值。建议把 Grafana 看板的 JSON 丢进 Git，哪天改出问题了还能查。

走完 Metrics，下一步自然就是 Tracing。这时接 OpenTelemetry 就行了，它跟 Micrometer 是同一层的东西，只不过管的是链路。日志也做结构化。最后就是这个格局：

Metrics 告诉你系统怎么样，Logging 告诉你发生了什么，Tracing 告诉你请求经历了什么。三条线谁也替不了谁，加起来才是你对自己系统完整的话。

工具说到底只是入场券，值钱的是你观察、分析、沉淀下来的那套思路。