Monitoring & Drift Detection: 解释可观测性三支柱（指标/日志/链路追踪）如何与 ML 模型监控结合。

Core Concept: 可观测性三支柱覆盖基础设施与调用链；ML 监控在其上叠加数据/模型/业务指标，形成基础设施-数据-模型-业务四层闭环。

数学机理：<strong>可观测性三支柱（three pillars of observability）</strong>——(1) <strong>指标（metrics）</strong>——(a) <strong>定义</strong>——随时间变化的可聚合数值（counter/gauge/histogram）；(b) <strong>特点</strong>——低存储、易聚合、适合看板与告警；(c) <strong>例子</strong>——QPS、P50/P95/P99 延迟、错误率、GPU 利用率、内存占用；(d) <strong>局限</strong>——只有聚合值，丢失单请求细节（'知道延迟高了，但不知哪条请求慢'）。(2) <strong>日志（logs）</strong>——(a) <strong>定义</strong>——离散事件的结构化/非结构化记录；(b) <strong>特点</strong>——高细节、高存储、适合排查；(c) <strong>例子</strong>——请求参数、模型输出、异常堆栈；(d) <strong>局限</strong>——量大、难聚合、成本高（需采样/分级）。(3) <strong>链路追踪（traces）</strong>——(a) <strong>定义</strong>——一个请求跨多个服务的调用链（span 树）；(b) <strong>特点</strong>——端到端、可视化延迟分解；(c) <strong>例子</strong>——网关→特征服务→模型服务→后处理各段耗时；(d) <strong>局限</strong>——需埋点、采样率足够才有代表性。<strong>ML 监控的扩展层</strong>——在三支柱之上叠加三层：(1) <strong>数据层</strong>——(a) <strong>分布指标</strong>（特征/标签分布、PSI/KL）；(b) <strong>质量指标</strong>（缺失率、越界率、schema 违规）；(c) <strong>新鲜度</strong>（特征/数据是否按时到达）。(2) <strong>模型层</strong>——(a) <strong>预测分布</strong>（类别占比、分数分布）；(b) <strong>置信度</strong>（预测熵、max-prob 分布）；(c) <strong>漂移</strong>（数据漂移、概念漂移、预测漂移）；(d) <strong>效果</strong>（有标签时的 AUC/NDCG；无标签时的代理指标）。(3) <strong>业务层</strong>——(a) <strong>核心业务指标</strong>（转化率、收入、点击率、留存）；(b) <strong>用户体验</strong>（任务成功率、放弃率）；(c) <strong>业务指标是最终目标</strong>——技术指标正常但业务指标下降仍需排查。<strong>关联机制</strong>——(a) <strong>trace_id</strong>——贯穿三支柱与模型/特征版本，把某条慢请求与哪个模型版本、哪版特征、哪个数据分片关联起来；(b) <strong>模型版本/特征版本</strong>——写入指标/日志/trace 的标签，支持按版本聚合；(c) <strong>端到端可追溯</strong>——从业务指标异常→模型指标→数据指标→基础设施指标逐层下钻。<strong>实现栈</strong>——(a) <strong>指标</strong>——Prometheus/Grafana、CloudWatch；(b) <strong>日志</strong>——ELK/OpenSearch、Loki；(c) <strong>追踪</strong>——Jaeger/Zipkin/OpenTelemetry；(d) <strong>ML 专用</strong>——Evidently/WhyLabs/Arize（漂移与数据质量）、MLflow（实验与模型注册）。<strong>与其他问题的关系</strong>——(a) 与监控体系分层（四层对应）；(b) 与漂移检测（数据/模型层）；(c) 与根因分析（下钻路径）；(d) 与告警设计（指标层触发）。<strong>实践建议</strong>——(a) <strong>三支柱缺一不可</strong>（指标看趋势、日志查细节、追踪找瓶颈）；(b) <strong>用 trace_id 串联</strong>（否则各自为政）；(c) <strong>模型/特征版本作为标签</strong>（支持按版本对比）；(d) <strong>日志采样分级</strong>（控制成本）；(e) <strong>ML 专用工具补足</strong>（通用可观测性看不到数据/模型问题）；(f) <strong>从业务指标反向下钻</strong>（避免只看技术指标）。

深度剖析与工程权衡：① <strong>指标、日志、追踪各有不可替代的作用</strong>——指标看趋势与告警、日志查具体细节、追踪找延迟瓶颈；面试中能说清三者分工是深度理解的标志。② <strong>ML 监控是通用可观测性的扩展而非替代</strong>——通用工具看不到特征分布/预测漂移，需 ML 专用层。③ <strong>trace_id 串联是端到端排查的关键</strong>——否则三支柱各自为政。④ <strong>模型/特征版本作为标签</strong>——支持按版本聚合与回滚验证。⑤ <strong>成本权衡</strong>——日志/追踪全量采集成本高，需采样与分级（错误请求 100% 采样、正常请求 1%）。⑥ <strong>业务指标是最终目标</strong>——技术指标正常但业务下降仍需排查（如推荐准确但用户不点击）。⑦ <strong>面试要点</strong>——被问怎么设计 ML 系统的监控，应给出'<strong>可观测性三支柱（指标/日志/追踪）+ ML 扩展层（数据/模型/业务）+ trace_id 串联 + 版本标签 + 成本控制</strong>'；能指出 ML 监控是通用可观测性的扩展与业务指标是最终目标是深度理解的标志。