日志监控是模型上线后稳定运行的关键防线，需聚焦输入层、模型层、业务层三类信号，用轻量规则实时告警，结构化日志绑定推理服务，并定期回放日志做健康快照。
日志监控不是机器学习的主战场，但它是模型上线后稳定运行的关键防线。没有有效的日志监控，再好的模型也可能在 silent failure 中悄然失效——比如预测准确率突然下跌、延迟飙升、特征分布偏移，却没人发现。
明确日志要监控什么，而不是记录一切
盲目打日志只会制造噪音。重点盯住三类信号：
- 输入层：请求量、请求耗时、原始特征值范围（如 age 是否出现负数、price 是否突增100倍）
- 模型层：预测置信度分布、类别输出频次、异常分数（如 Isolation Forest 的 outlier score）
- 业务层：关键路径成功率（如“推荐→点击→下单”链路断在哪）、人工反馈标记（如用户点“不感兴趣”）
例如，电商推荐模型上线后，除了记录 predict() 返回结果，务必同步记录 raw_features['user_active_days'] 和 model_version。否则当某天活跃天数字段被上游误填为字符串，模型静默报错，你只能靠猜。
用轻量规则+简单统计替代复杂模型做实时告警
刚起步别急着上 Anomaly Detection 模型。先跑通基础水位线：
- 每5分钟统计一次 p95 延迟，超阈值（如 800ms）立刻发钉钉
- 每天凌晨校验特征缺失率，user_id 缺失 > 0.1% 就触发企业微信提醒
- 用直方图比对昨日/今日的预测分分布，KL 散度 > 0.3 则标为“需人工核查”
这些规则写成 Python 脚本 + Cron，配合 ELK 或 Grafana 就能跑起来。等数据积累够了、问题模式清晰了，再考虑用 LSTM 或 Prophet 做趋势预测式告警。
把日志和线上推理服务绑死，拒绝“事后补录”
很多团队让模型服务输出日志，再由另一个脚本异步采集——这会导致时间错乱、丢失失败请求、难以关联 trace ID。正确做法是：
- 在推理接口内部（如 FastAPI 的 endpoint 函数里）直接写结构化日志，包含 request_id、timestamp、input_hash、output、duration_ms
- 所有日志统一走 stdout，由容器平台（如 Kubernetes）自动收集到日志中心
- 失败请求必须记录 error_type（KeyError / NaNInput / OOM）和 stack snippet 前2行，不能只记“predict failed”
这样查问题时，输入、输出、错误、时间戳全部对得上，不用拼凑三四个系统日志。
定期回放日志做“健康快照”，比实时告警更早发现问题
告警是救火，快照是体检。每周固定时间跑一次：
- 抽样 1 万条线上请求日志，重跑离线预测，对比线上结果差异率
- 统计各特征的空值率、极值占比、与训练集分布的 JS 距离
- 生成 HTML 报告，高亮变化 >15% 的指标，附带原始日志片段示例
这个过程不需要实时性，但能提前发现数据漂移、特征工程 bug、甚至上游逻辑变更（比如某天开始 user_tags 字段从数组变成字符串）。
基本上就这些。日志监控不是炫技，而是让机器学习真正落地时“看得见、说得清、控得住”。不复杂，但容易忽略。
