3. 可观测性三大支柱在AI系统中的映射
传统微服务的可观测性三支柱——日志（Logs）、指标（Metrics）、追踪（Traces）——在AI系统中依然成立，但它们的采集对象、语义和关联方式发生了明显变化。AI系统不是单一服务，而是由数据管道、特征存储、训练作业、模型注册、推理服务、向量检索等多个环节组成的链路。若直接套用Web服务的埋点方式，往往只能看到“服务是否存活”，却看不到“模型为什么变差”。本节先厘清三支柱在AI场景中的映射关系，再给出可落地的采集与关联方法。
一、三支柱在AI系统中的角色重定义
在AI系统中，三支柱各自承担不同的观测职责，且必须通过统一的关联键（如 run_id、request_id、model_version、feature_view）串联起来，否则会形成信息孤岛。
- 日志：记录离散事件与上下文，例如训练作业启动参数、数据校验失败原因、推理请求的输入摘要与异常堆栈。AI日志的特点是“结构化字段多、单条体积大”，需要区分系统日志、数据日志、模型日志三类。
- 指标：记录可聚合的数值时间序列，例如训练 loss/learning rate、推理 QPS/延迟分位数、特征新鲜度、数据管道吞吐。指标适合做告警和趋势判断，但难以解释单次异常。
- 追踪：记录一次请求或一次作业在多个组件间的调用路径与耗时，例如一次推理请求经过网关、特征服务、向量检索、模型服务、后处理的完整链路。追踪是定位“慢在哪、错在哪”的关键。
二、训练、推理、特征与数据管道的映射差异
不同环节对三支柱的依赖程度不同，采集重点也不同。下表给出一个可参考的映射框架（示例参数为教学假设，非实测值）。
| 环节 | 日志重点 | 指标重点 | 追踪重点 |
|---|---|---|---|
| 数据管道 | 批次ID、源表、校验规则、失败行样例 | 吞吐、延迟、空值率、schema漂移计数 | 批次内各算子耗时、上下游依赖 |
| 特征工程 | 特征视图版本、回填范围、缺失特征名 | 特征新鲜度、覆盖率、分布偏移 | 特征读取→计算→写入的链路 |
| 模型训练 | 超参、数据版本、checkpoint路径、异常堆栈 | loss、学习率、GPU利用率、吞吐样本/秒 | 数据加载→前向→反向→保存的算子级耗时 |
| 推理服务 | 请求ID、模型版本、输入摘要、降级原因 | QPS、P50/P95/P99延迟、错误率、token数 | 网关→特征→检索→模型→后处理的完整span |
可以看到，数据管道和特征工程更偏“批处理+数据质量”，训练更偏“长周期+资源”，推理更偏“低延迟+高并发”。因此，三支柱的采集频率、保留策略和告警阈值必须按环节分别设计，不能一刀切。
三、统一关联键：让三支柱真正联动
AI系统可观测性最常见的失败模式是：日志里有 request_id，指标里只有服务名，追踪里只有 trace_id，三者无法互查。解决方法是定义一组贯穿全链路的关联键，并在所有采集点注入。
# 推荐的统一关联键（示例）
run_id # 一次训练或一次批处理作业
request_id # 一次推理请求
trace_id # 一次分布式调用链
model_version # 模型注册表中的版本号
feature_view # 特征视图名称与版本
dataset_ver # 训练/评估数据集版本
在推理服务中，网关生成 request_id 与 trace_id，并透传到特征服务和模型服务；模型服务在日志中写入 model_version 与 feature_view；指标按 model_version 打标签。这样，当 P95 延迟升高时，可以先看指标定位到某个 model_version，再用 trace_id 找到慢 span，最后用 request_id 查日志确认输入特征是否异常。
四、从采集到判读：一个推理链路的观测示例
假设某推荐推理服务出现 P95 延迟从 120ms 升至 480ms。按三支柱联动排查：指标显示延迟升高集中在 model_version=v7；追踪显示耗时集中在“向量检索”span，从 30ms 升至 350ms；日志显示该时段检索请求的 top_k 从 50 被改为 200。结论是参数变更导致检索耗时上升，而非模型本身变慢。这个例子说明：指标负责“发现异常”，追踪负责“定位环节”，日志负责“解释原因”。
五、落地要点与常见误区
第一，日志要结构化。训练日志中至少包含 run_id、dataset_ver、超参摘要；推理日志中至少包含 request_id、model_version、输入摘要与降级标记。非结构化日志在AI场景中几乎无法用于关联分析。
第二，指标要带维度标签。仅记录“推理延迟”意义有限，应带上 model_version、endpoint、feature_view 等标签，才能按版本、按接口、按特征视图下钻。但标签基数要控制，避免 request_id 这类高基数键进入指标标签。
第三，追踪要覆盖异步与批处理。训练作业和Spark管道不是典型HTTP请求，需要用作业级 trace 或 span 手动埋点，记录数据加载、特征计算、模型保存等阶段耗时。
第四，保留策略要分层。推理日志和追踪采样率可设为 1%～10%（高流量场景），但错误请求应全量保留；训练日志和指标可按 run_id 长期保留，便于回溯模型退化原因。特征新鲜度、数据漂移等指标建议保留至少一个完整训练周期，以便对比。
综上，三支柱在AI系统中的适配核心是：日志提供“发生了什么”，指标提供“是否异常、趋势如何”，追踪提供“在哪一环、耗时多少”。三者通过统一关联键联动，才能覆盖从数据管道到推理服务的完整可观测链路。实际落地时，先统一关联键，再按环节设计采集内容与保留策略，最后用一次真实异常演练验证联动是否有效。