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

云原生可观测性日志、指标、链路追踪要一起排练一、只看日志已经不够了云原生环境里一个请求可能经过网关、前端 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 串联、告警指向动作再加定期演练排障才不会靠运气。