前言：让系统解释自己
同一条用户反馈“下单很慢”，可以引出完全不同的改动。有人扩大线程池，有人增加 Redis 内存，也有人把消息消费改成同步等待。它们都可能让某个局部数字变好，却没有回答最初的问题：用户等待的那段时间，系统到底做了什么？
可观测性首先是一种证据组织能力。指标告诉我们哪些现象值得注意，追踪把一次工作分解成有因果关系的区间，日志补充当时的决定和结果。三个后台同时上线，不会自动得到这种能力；必须先定义工作边界、身份、时间和结果，再让采集与查询保留这些定义。
这本书适合已经会写基本 Java 服务的读者。主线是一套可以执行的小系统：客户端通过 HTTP 网关创建订单，订单服务访问 Redis、发布 RocketMQ 消息，消费者完成异步处理。三个逻辑服务使用真实 OpenTelemetry Java SDK，通过 OTLP 把遥测发送给 Collector。Tempo 保存和查询 trace，Prometheus 抓取指标并计算告警；结构化日志同时输出到应用日志与 OTLP 日志管线。这里没有用一张内存列表替代追踪后端。
为了降低环境复杂度，网关、订单服务和消费者运行在同一个 JVM 内，但使用三个独立的遥测资源与真实 HTTP、Redis、RocketMQ 连接。它适合研究传播边界，不能据此宣称验证了跨主机网络或独立进程的全部行为。我们也没有部署 Grafana 或 Loki；本书直接查询后端 API，日志证据保存在运行产物里。先把证据取得，再决定用什么界面呈现。
先运行，再决定可以声称什么
阅读顺序可以分成三段。第 1—4 章建立证据模型、运行环境和 HTTP 传播；第 5—8 章处理 Redis、消息、日志与指标；第 9—13 章进入 Collector、后端查询、采样、成本与 SLO；第 14—16 章把这些能力组织成故障演练、采集故障处理和生产交付方案。附录包含命令、练习解答、官方来源及从项目自动生成的完整代码。
实验使用固定版本与镜像摘要。它们是本书可以复核的基线，不表示当前生产系统应该照抄这组版本。本地没有容器环境时，也可以查看仓库 Actions 保存的真实集成产物，再按正文检查 JSON、span 关系与日志，而不是只相信一个“测试通过”的徽章。
实验中特别保留了三个容易误判的情况。第一，在 Redis 客户端 span 内注入等待，只能证明这个区间变长，不能证明 Redis 服务端执行变慢。第二，订单接口返回 202，不表示消费者已完成业务。第三，采样关闭后看不到 trace，不表示请求没有发生。我们将通过不同证据区分这些情况。
这本书的使用方法
每章都先给出一个需要解释的问题，再推导所需的信息和采集位置，最后连接到可执行命令或证据文件。代码片段用来说明局部机制；运行入口是 lab/run_ci.sh 与完整项目。没有特别标为实际结果的数字，均是计算示例或实验预期。最终验证记录会给出对应提交和运行入口，避免把旧报告当成新代码的证明。
可观测性不会替代业务正确性测试，也不会因为接入 SDK 就自动具备生产安全、隐私治理和高可用。本书希望帮助你形成一种更具体的习惯：先说明想证明哪件事，找到能反驳自己假设的证据，再修改系统。