指标、日志、追踪回答的是不同的问题

一句话总结

指标说明整体趋势并触发告警，结构化日志提供单个事件的上下文，追踪标识符则解释跨越边界的因果关系。三种信号必须通过同一请求产生的安全关联字段连接起来。

为什么一行日志无法解决故障

error happened 这个字符串无法说明失败发生得多频繁、出现在哪条路由、处于什么状态。订单创建数和 HTTP 延迟指标可以呈现变化与阈值。JSON 日志中的 event、route、status、duration_ms 便于检索单个请求。如果在响应头和日志中写入相同的 trace ID，就能准确定位用户报告的请求；如果有多个服务，还应把该 ID 传播到后续调用。

指标名应像 orders_created_total、http_request_duration_seconds 一样明确体现单位和累计语义。如果把用户 ID 或订单 ID 用作指标标签，基数会爆炸。此类唯一值在确有需要时可以写入日志，但必须遵守个人信息与秘密值策略。认证头、Cookie、密码、连接字符串、内部服务 DNS 都不应记录在任何信号中。

如何在实际环境中验证

评分器向服务器发送创建请求，从响应中取得 trace ID，并从 /metrics 读取两个核心指标。服务器退出后，它会逐行把日志解析为 JSON，确认同一条记录包含相同的 trace ID、/orders 路径、201 状态，以及数值类型的 duration_ms。仅仅在源码中出现 json 或 trace_id 字符串并不是证据。如果导入时产生输出，或日志中出现令牌原文，也会判定失败。

区分三种信号的用途

“收集日志、指标和追踪”这句话很常见，但如果不先确定提出什么问题时该看哪一种，即使三者齐全，故障发生时仍会迷失方向。

问题	查看什么	原因
现在有问题吗	指标	成本低且覆盖全局；只在这里设置告警
哪里慢	追踪	显示单个请求经过各区段的耗时
为什么会这样	日志	提供当时的上下文；成本最高，因此最后查看

只基于指标设置告警。 如果基于日志字符串设置告警，消息稍作修改就会悄悄失效，而且通常直到故障发生时才会发现。

用同一个标识符连接三种信号。 为每个请求生成追踪 ID，写入日志，也作为指标的示例(exemplar)关联。这样就能从“某个慢请求”直接跳到该请求的日志。没有这种连接时，只能按时间翻找日志；流量一大，这种方法就失去作用。

基数问题主要发生在指标中。 把用户 ID 写入日志通常可以接受，但把它放进指标标签会导致时间序列爆炸。高基数值应放在日志和追踪中，指标只保留低基数值。

还要从用户侧再测一次。 即使服务器返回 200，用户仍可能失败。加入一项前端测量或从外部运行的合成监控，就能避免“内部指标正常却不断收到用户反馈”的情况。

决定记录什么的标准是“它会帮助做出什么决定”。 不会改变任何决策的指标只会让仪表板混乱并增加成本。每次制作仪表板时，先写下一句“看到这个页面后要采取什么行动”，往往一半内容都会被删掉。

实务判断标准

好的可观测性不是事后输出大量调试文字，而是先确定运维问题，再设计低成本信号。通过指标观察成功率、错误率、延迟和流量，再借助 trace 与日志缩小特定异常的范围。接下来的部署课程会介绍：即使这些信号正常，也不要把流量发送到尚未就绪的 Pod，并应如何设计探针与运行安全边界。