云原生可观测性：日志、指标、链路追踪要一起排练

一、只看日志已经不够了

云原生环境里，一个请求可能经过网关、前端 SSR、BFF、多个微服务、队列、数据库和模型服务。只看单个容器日志，像只听鼓不听整首歌。你能知道某个点响了，但不知道整体节奏哪里乱。

可观测性要把日志、指标、链路追踪放在一起。日志回答发生了什么，指标回答系统是否异常，链路追踪回答请求经过哪里、哪里慢。

二、观测链路：三类数据互相补充

flowchart TD
    A[用户请求] --> B[Trace 串联链路]
    B --> C[Metrics 观察趋势]
    B --> D[Logs 定位细节]
    C --> E[告警]
    D --> F[排障]

没有 trace_id，日志很难串起来；没有指标，团队不知道什么时候该看日志；没有日志，trace 只能告诉你慢，不能告诉你为什么慢。三者缺一块，排障体验都会断。

三、字段示例：日志必须结构化

{
  "trace_id": "abc123",
  "service": "ai-gateway",
  "path": "/v1/chat",
  "latency_ms": 320,
  "status": 200,
  "error": ""
}

结构化日志比自由文本更适合检索和聚合。尤其是多服务场景，字段统一能省很多时间。不要每个服务自己发明一套日志格式。

四、工程边界：告警要能指向动作

告警不要只说“服务异常”。要告诉值班同学看哪个面板、可能影响什么、是否有降级开关、最近是否发布。一个不能指导行动的告警，只是在半夜制造噪声。

取舍方面，采样能降低成本，但采样太狠会丢细节；全量记录信息完整，但存储和查询成本高。可以对正常请求采样，对错误和慢请求全量保留。可观测性也要算成本。

还要定期演练。不是出了事故才看面板，而是平时就模拟一个慢接口、一个错误率上升、一次模型服务超时，练习如何定位。可观测性像乐队排练，平时不练，演出时一定乱。

可观测性还要和发布系统打通。面板上能看到最近一次发布、配置变更、扩缩容事件，排障会快很多。很多异常不是凭空出现，而是刚好发生在一次变更之后。把变更叠到指标曲线上，证据会更直观。

成本也要治理。日志、指标、Trace 全量采集很爽，账单也会很刺激。可以按服务等级和错误类型采样，核心链路保留更多，低价值噪声少收。可观测性不是数据越多越好，而是证据足够且成本可控。

最后，告警要有 owner。没有负责人、没有处理手册、没有升级路径的告警，只是在群里制造噪音。可观测性最终要服务行动。

Trace 采样策略也要按业务区分。核心交易、AI 推理、支付回调可以保留更高采样率，普通静态请求可以降低。慢请求和错误请求最好强制保留。这样既控制成本，也不丢关键证据。

日志字段要有统一规范。trace_id、user_id_hash、service、env、version、error_code，这些字段如果每个服务命名不同，查询会非常痛苦。可观测性不是装三个系统，而是让数据能互相对上。

最后，演练后要更新面板和手册。演练发现哪里看不清，就改哪里。可观测性也要迭代。

可观测性还要覆盖前端。前端错误、白屏、资源加载失败、接口耗时、用户区域和版本号，都应该能和后端 trace 关联。用户说页面卡，不一定是后端慢；可能是资源加载、浏览器兼容、前端异常或 CDN 问题。端到端观测才完整。

对于 AI 服务，还要加质量维度。延迟和错误率正常，不代表回答质量正常。可以监控重试率、用户点踩率、引用缺失率、token 消耗和模型拒答率。AI 应用的可观测性比普通服务多一层质量信号。

最后，别让面板变成装饰。每个面板都应该回答一个问题：现在有没有影响用户，影响哪里，下一步看什么。回答不了问题的图，就该删。

五、总结

云原生可观测性要把日志、指标和链路追踪一起设计。字段统一、trace 串联、告警指向动作，再加定期演练，排障才不会靠运气。