1. 项目概述：当模型走出Jupyter，真正开始呼吸真实世界空气

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号，专为那些在Jupyter里调通了模型、画出了漂亮ROC曲线、却在部署时被现实狠狠绊了一跤的工程师准备的。它不是讲怎么写model.fit()，而是讲模型第一次被放进API里、第一次接到线上用户请求、第一次因为上游数据格式突变而默默返回500 Internal Server Error时，你该抓哪根日志、看哪个指标、改哪行代码。我带过三支AI工程团队，亲手把27个模型从研究环境推到生产，其中19个在上线后第一周就暴露出至少一个“笔记本里绝对看不到”的问题：特征偏移没监控、GPU显存泄漏没告警、模型版本和数据版本没对齐……这些坑，文档不写，论文不提，但它们每天都在真实系统里吃掉运维时间、拖慢业务迭代、甚至悄悄腐蚀模型效果。这篇内容的核心，就是拆解“Part 4”背后那个被严重低估的环节——模型服务化落地后的持续可观测性与韧性保障。它解决的不是“能不能跑”，而是“跑得稳不稳、坏得明不明、修得快不快”。适合所有已经完成模型训练、正卡在“最后一公里”部署阶段的算法工程师、MLOps工程师和数据平台负责人；也适合技术决策者，用来判断你们当前的模型服务架构是否真能扛住业务增长带来的流量与数据压力。关键词——模型服务化、生产级ML、MLOps可观测性、模型监控、推理服务稳定性——每一个都直指真实世界里的痛处：不是模型不准，是准了你也发现不了它什么时候不准了。

2. 内容整体设计与思路拆解：为什么“可观测性”是Part 4的真正主角

2.1 从“能运行”到“可掌控”的范式跃迁

很多团队把“模型上线”定义为docker run -p 8000:8000 model-service成功返回Running on http://0.0.0.0:8000那一刻。这就像把一辆刚组装好的赛车开上赛道，引擎轰鸣、仪表盘亮起，但车上没有转速表、没有油压警告灯、没有轮胎温度传感器——你只知道它在动，却完全不知道它在以什么状态动。Part 4 的核心设计逻辑，正是完成这场从“能运行”（Operational）到“可掌控”（Controllable）的范式跃迁。它不满足于让模型响应HTTP请求，而是要求你能回答五个关键问题：

1. 现在谁在调用它？（请求来源、用户ID、业务场景）
2. 它正在处理什么数据？（输入特征分布、缺失值比例、异常值标记）
3. 它的输出是否可信？（预测置信度分布、类别漂移、输出延迟P99）
4. 它的健康状况如何？（GPU显存占用率、Python GC频率、线程阻塞数）
5. 如果它坏了，坏在哪？（是模型层崩溃？是特征工程超时？还是下游数据库连接池耗尽？）

这个设计思路的底层驱动力，是真实世界的数据熵增定律：训练数据是静止快照，生产数据是流动河流。上游业务系统升级、埋点逻辑变更、第三方API返回格式调整、甚至用户行为季节性迁移，都会在毫无预警的情况下，让昨天还准确率92%的模型，今天开始对某类用户群体系统性误判。而笔记本里那套print(model.predict(X_test[:5]))的验证方式，在生产环境里连“望远镜”都算不上，顶多是个“放大镜”。

2.2 为什么跳过Part 4会付出十倍代价？

我见过最典型的反面案例，是一家电商公司的推荐模型。他们在Part 1-3完成了模型训练、Docker容器化、Kubernetes部署，上线后首月GMV提升1.2%，团队一片欢腾。但第三周开始，客服工单里“为什么给我推完全不相关商品”的投诉量悄然翻倍，而A/B测试平台显示新模型组的点击率（CTR）只比基线低0.03%，统计上不显著——没人觉得有问题。直到第四周，风控团队发现该模型给高风险用户群体的授信额度预测出现集中性偏高，才紧急回滚。事后复盘，问题根源是上游用户画像服务在一次灰度发布中，将“近30天活跃天数”字段的空值填充逻辑从0改为NULL，导致模型特征工程模块在处理该字段时触发了未捕获的TypeError，进而fallback到默认值1。这个bug在测试环境从未暴露，因为测试数据里该字段无空值；它在生产环境静默存在了17天，只通过业务指标的微小偏移间接体现。修复成本：2名工程师+1名数据科学家，耗时38人小时。而如果Part 4的可观测性体系到位，这个异常会在首次发生时，通过“特征缺失率突增告警”+“模型输出置信度分布偏移告警”双触发，15分钟内定位到具体字段和代码行。这就是跳过Part 4的真实代价：不是省下开发时间，而是把调试成本从“分钟级”放大到“天级”，把问题影响从“局部可逆”扩大到“全局不可逆”。

2.3 架构选型：轻量嵌入 vs 全链路追踪，我们为什么选前者

市面上关于生产模型监控的方案，大致分两类：一类是全链路APM方案（如Datadog APM、New Relic），另一类是MLOps原生可观测性平台（如Arize、Whylogs）。我们的选型结论很明确：在Part 4阶段，必须采用轻量级、可嵌入、与模型服务代码深度耦合的方案，而非依赖外部SaaS或重型Agent。理由有三：
第一，数据主权与实时性冲突。全链路APM需要在应用层注入大量探针，采集HTTP Header、SQL Query、函数调用栈等元数据。但对于金融、医疗等强监管行业，模型输入数据（如用户身份证号哈希、病历文本摘要）的原始特征向量，绝不能未经脱敏就上传至第三方服务。而轻量方案（如Prometheus + 自定义Exporter）只上报聚合指标（如feature_age_mean{model="credit_score"} 32.4），原始数据永远留在内网。
第二，语义鸿沟无法跨越。APM工具知道“某个HTTP请求耗时2.3秒”，但它不知道这2.3秒里，0.8秒花在特征标准化、0.6秒花在PyTorch推理、0.9秒花在缓存查询。只有模型服务代码内部才能精确标注这些语义段。我们曾用OpenTelemetry对一个NLP模型服务做全链路追踪，结果生成的Trace Span里，92%的Span名称是torch.nn.functional.linear这类框架内部函数，真正有意义的业务Span（如compute_user_risk_score）不到5个。
第三，故障定位效率碾压。当一个请求失败时，APM给出的是“Span A → Span B → Span C”的调用链，而轻量嵌入方案能直接告诉你：“在/predict端点第142行，scaler.transform()因输入含NaN抛出ValueError，原始特征income_log在本次请求中缺失率为100%”。后者直接指向修复动作，前者还需人工关联日志、排查上下游。因此，Part 4的技术栈基石，是我们自己编写的ml-observability-sdk——一个仅327行Python代码的库，它不替代Prometheus，而是让Prometheus能读懂机器学习的语言。

3. 核心细节解析与实操要点：构建模型服务的“神经末梢”

3.1 指标体系设计：超越CPU/Memory的ML专属健康仪表盘

生产环境的监控指标，绝不能停留在操作系统层面。一个GPU显存占用率95%的模型服务，可能健康得像头牛；而一个CPU占用率仅15%的服务，可能正因特征偏移陷入无限重试循环。Part 4的指标体系，必须包含三个维度的黄金指标：

第一维度：基础设施层（Infrastructure Metrics）
这是底线，但不是全部。我们采集：

• gpu_memory_used_bytes{model="fraud_detection", gpu="0"}：GPU显存实际使用量（非百分比，避免归一化失真）
• process_cpu_seconds_total{model="fraud_detection"}：进程CPU时间累积秒数（用于计算P99延迟时排除GC暂停干扰）
• http_request_duration_seconds_bucket{le="0.1", model="fraud_detection"}：HTTP请求延迟直方图（关键！必须用_bucket而非_sum，才能计算P99）

提示：不要用node_memory_MemAvailable_bytes这类主机级指标监控容器。Kubernetes Pod的cgroup内存限制是硬边界，主机指标反映的是Node整体负载，与单个模型服务OOM无直接因果关系。必须采集container_memory_usage_bytes{container="model-server"}。

第二维度：服务层（Service Metrics）
这是连接基础设施与业务的桥梁。我们强制要求每个模型服务暴露：

• model_inference_duration_seconds_count{model="fraud_detection", status="success"}：成功推理请求数（注意：status必须区分success/failed/timeout，不能只计总数）
• model_feature_missing_rate{feature="user_age", model="fraud_detection"}：单特征缺失率（按请求批次聚合，非全局平均）
• model_output_confidence_quantile{quantile="0.95", model="fraud_detection"}：预测置信度P95（对分类模型是softmax最大值，对回归模型是预测区间宽度）

第三维度：模型层（Model Metrics）
这才是Part 4的灵魂。我们拒绝“训练时评估，上线后放养”。每小时自动计算：

• model_prediction_drift{metric="ks_test", feature="income", model="fraud_detection"}：KS检验统计量（衡量线上特征分布vs训练分布差异）
• model_label_drift{metric="psi", model="fraud_detection"}：PSI（Population Stability Index）指标，监控标签分布漂移（如欺诈率从0.8%升至1.5%）
• model_performance_degradation{metric="f1_score", model="fraud_detection"}：基于影子流量（Shadow Traffic）的在线评估分数（用同一份线上请求，同时打给新旧模型，对比输出）

注意：所有指标命名严格遵循Prometheus规范：小写字母+下划线，{}内标签按cardinality降序排列（如{model="xxx", version="v2.1", feature="xxx"}，高基数标签feature放最后）。这是为了保证Prometheus TSDB的存储效率，避免标签组合爆炸。

3.2 数据采集实现：如何让指标“长”在模型代码里

指标采集不是加个@timer装饰器就完事。真正的难点在于：如何在不污染核心推理逻辑的前提下，让指标采集具备语义感知能力。我们采用“三明治注入法”：

# ml_observability_sdk/instrumentation.py from prometheus_client import Counter, Histogram, Gauge import time import numpy as np # 全局指标注册器（避免重复创建） INFERENCE_COUNTER = Counter( 'model_inference_duration_seconds_count', 'Count of model inference requests', ['model', 'status', 'http_status'] ) INFERENCE_HISTOGRAM = Histogram( 'model_inference_duration_seconds', 'Model inference duration in seconds', ['model', 'stage'], # stage: 'preprocess'/'inference'/'postprocess' buckets=[0.01, 0.05, 0.1, 0.2, 0.5, 1.0, 2.0, 5.0] ) FEATURE_MISSING_GAUGE = Gauge( 'model_feature_missing_rate', 'Missing rate of a specific feature', ['model', 'feature'] ) def instrument_model_inference(model_name: str): """装饰器：为模型推理函数添加全链路指标采集""" def decorator(func): def wrapper(*args, **kwargs): # 【上层】预处理阶段指标 start_time = time.time() try: # 假设kwargs包含原始输入字典 input_data = kwargs.get('input', {}) for feature_name, value in input_data.items(): if isinstance(value, (list, np.ndarray)) and len(value) == 0: FEATURE_MISSING_GAUGE.labels(model=model_name, feature=feature_name).set(1.0) elif value is None or (isinstance(value, float) and np.isnan(value)): FEATURE_MISSING_GAUGE.labels(model=model_name, feature=feature_name).set(1.0) else: FEATURE_MISSING_GAUGE.labels(model=model_name, feature=feature_name).set(0.0) # 【中层】执行核心推理 preprocess_start = time.time() processed_input = preprocess(input_data) # 特征工程函数 preprocess_duration = time.time() - preprocess_start INFERENCE_HISTOGRAM.labels(model=model_name, stage='preprocess').observe(preprocess_duration) inference_start = time.time() raw_output = func(processed_input, *args, **kwargs) # 原始模型调用 inference_duration = time.time() - inference_start INFERENCE_HISTOGRAM.labels(model=model_name, stage='inference').observe(inference_duration) postprocess_start = time.time() final_output = postprocess(raw_output) # 后处理 postprocess_duration = time.time() - postprocess_start INFERENCE_HISTOGRAM.labels(model=model_name, stage='postprocess').observe(postprocess_duration) # 【下层】后处理阶段指标 total_duration = time.time() - start_time INFERENCE_HISTOGRAM.labels(model=model_name, stage='total').observe(total_duration) INFERENCE_COUNTER.labels( model=model_name, status='success', http_status='200' ).inc() return final_output except Exception as e: # 捕获所有异常，记录失败指标 total_duration = time.time() - start_time INFERENCE_HISTOGRAM.labels(model=model_name, stage='total').observe(total_duration) INFERENCE_COUNTER.labels( model=model_name, status='failed', http_status=getattr(e, 'http_status', '500') ).inc() raise e # 重新抛出，不吞异常 return wrapper return decorator # 在模型服务中使用 @instrument_model_inference(model_name="fraud_detection_v2") def predict(input: dict) -> dict: # 这里是你的纯模型逻辑，完全不感知监控 features = vectorizer.transform([input['text']]) proba = model.predict_proba(features)[0] return {"risk_score": float(proba[1]), "confidence": float(max(proba))}

这个实现的关键细节在于：

• 指标采集与业务逻辑零耦合：predict()函数内部完全不出现prometheus_client或任何监控代码，所有采集由装饰器自动完成。
• 阶段化观测：将total延迟拆解为preprocess/inference/postprocess，当P99延迟升高时，能立刻定位是特征工程慢了（如正则表达式回溯），还是模型本身慢了（如Transformer层数过多）。
• 异常穿透：装饰器捕获异常后，仍raise e，确保错误能被FastAPI/Flask的全局异常处理器捕获并返回正确HTTP状态码，避免监控指标与实际响应不一致。

3.3 实时告警配置：从“收到告警”到“知道怎么修”的距离

有了指标，不等于有了告警。Part 4的告警规则设计，必须遵循“可操作性第一”原则。我们禁用所有“CPU > 80%”这类无意义告警，只保留三类：

第一类：确定性故障告警（Critical）

• count_over_time(model_inference_duration_seconds_count{model="fraud_detection", status="failed"}[5m]) > 10
  含义：过去5分钟内失败请求数超10次。触发即电话告警，SRE立即介入。
• avg_over_time(model_feature_missing_rate{feature="user_id", model="fraud_detection"}[1h]) > 0.9
  含义：user_id特征在过去1小时缺失率超90%。这通常意味着上游数据管道彻底中断，需立即检查Kafka Topic或Airflow DAG。

第二类：漂移预警（Warning）

• model_prediction_drift{metric="ks_test", feature="income", model="fraud_detection"} > 0.2
  含义：收入特征KS检验值超0.2（经验阈值，KS>0.2表示分布差异显著）。触发企业微信消息，通知算法工程师启动数据诊断。
• model_output_confidence_quantile{quantile="0.05", model="fraud_detection"} < 0.3
  含义：预测置信度P5低于0.3，说明模型对大量样本极度不确定。这比准确率下降更早暴露问题，常出现在新用户冷启动场景。

第三类：容量瓶颈告警（Info）

• rate(container_cpu_usage_seconds_total{container="fraud-detection-server"}[5m]) / ignoring(cpu) group_left node_cpu_cores > 0.8
  含义：容器CPU使用率占所在Node总核数比例超80%。这不是故障，而是扩容信号，触发自动伸缩（HPA）或人工评估是否需优化模型（如量化）。

实操心得：告警阈值绝不能拍脑袋定。我们为每个模型建立“基线期”（Baseline Period）：上线后前72小时，所有指标自动学习动态阈值。例如，model_inference_duration_seconds_count的P99延迟基线是123ms ± 15ms，那么告警阈值就设为123ms * 1.5 = 184.5ms。这样能适应不同模型的天然性能差异，避免对轻量模型过度告警。

4. 实操过程与核心环节实现：从零搭建一个可落地的可观测性流水线

4.1 环境准备：最小可行技术栈（Less is More）

Part 4的落地，最忌讳一上来就堆砌技术。我们坚持“最小可行技术栈”（MVTS）原则：只引入绝对必要组件，且全部开源、可审计、无厂商锁定。最终选定的四件套是：

安装命令极简（以Kubernetes为例）：

# 1. 创建Prometheus命名空间 kubectl create namespace monitoring # 2. 部署Prometheus（使用Helm简化） helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm install prometheus prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --set grafana.enabled=true \ --set alertmanager.enabled=true # 3. 为模型服务添加ServiceMonitor（关键！让Prometheus自动发现服务） cat <<EOF | kubectl apply -f - apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: fraud-detection-monitor namespace: monitoring spec: selector: matchLabels: app: fraud-detection-server endpoints: - port: web interval: 15s path: /metrics EOF

注意：ServiceMonitor是Prometheus Operator的核心对象，它告诉Prometheus：“去发现所有带app=fraud-detection-server标签的Service，并从其web端口的/metrics路径拉取指标”。这比手动配置static_configs优雅得多，服务扩缩容时指标采集自动同步。

4.2 模型服务改造：5分钟接入可观测性

假设你有一个基于FastAPI的模型服务，原始代码如下：

# app.py (原始版) from fastapi import FastAPI import joblib app = FastAPI() model = joblib.load("model.pkl") @app.post("/predict") def predict(input: dict): features = [input["age"], input["income"]] pred = model.predict([features])[0] return {"prediction": int(pred)}

接入Part 4可观测性的改造，仅需三步：

第一步：安装SDK

pip install ml-observability-sdk==0.3.1

第二步：添加指标埋点（修改app.py）

# app.py (改造版) from fastapi import FastAPI, HTTPException from ml_observability_sdk.instrumentation import instrument_model_inference import joblib app = FastAPI() model = joblib.load("model.pkl") # 【新增】初始化SDK，指定模型名 from ml_observability_sdk import init_observability init_observability(model_name="fraud_detection_v2", version="2.1.0") @app.post("/predict") @instrument_model_inference(model_name="fraud_detection_v2") # 【新增】装饰器 def predict(input: dict): try: # 【新增】特征校验（这是可观测性的起点） if not isinstance(input.get("age"), (int, float)) or input.get("age") < 0: raise ValueError("Invalid age value") if not isinstance(input.get("income"), (int, float)) or input.get("income") < 0: raise ValueError("Invalid income value") features = [float(input["age"]), float(input["income"])] pred = model.predict([features])[0] return {"prediction": int(pred), "confidence": float(model.predict_proba([features])[0].max())} except ValueError as e: # 【新增】业务异常，返回400，指标自动标记为failed raise HTTPException(status_code=400, detail=str(e)) except Exception as e: # 【新增】未知异常，返回500 raise HTTPException(status_code=500, detail="Internal server error")

第三步：暴露/metrics端点（新增metrics.py）

# metrics.py from fastapi import APIRouter from prometheus_client import CONTENT_TYPE_LATEST, generate_latest from ml_observability_sdk import registry router = APIRouter() @router.get("/metrics") def get_metrics(): return Response( generate_latest(registry), media_type=CONTENT_TYPE_LATEST )

并在app.py中挂载：

# app.py 末尾追加 from metrics import router app.include_router(router)

验证是否成功：

1. 启动服务：uvicorn app:app --host 0.0.0.0:8000
2. 访问http://localhost:8000/metrics，应看到类似：

   # HELP model_inference_duration_seconds_count Count of model inference requests # TYPE model_inference_duration_seconds_count counter model_inference_duration_seconds_count{model="fraud_detection_v2",status="success",http_status="200"} 1.0

3. 在Prometheus UI（http://localhost:9090）中执行查询：model_inference_duration_seconds_count{model="fraud_detection_v2"}，应返回数值。

整个过程不超过5分钟，且零修改模型核心逻辑。这就是Part 4设计的精妙之处：可观测性不是附加功能，而是服务的“呼吸系统”，自然融入每一次请求。

4.3 Grafana看板实战：构建算法工程师的“作战指挥室”

指标采集上来，不等于问题能被看见。Grafana看板的设计，决定了Part 4的价值能否被一线工程师真正用起来。我们摒弃“大而全”的仪表盘，为每个模型定制三张核心看板：

看板1：实时健康概览（Real-time Health Dashboard）

• 左上角：model_inference_duration_seconds_count{model="fraud_detection_v2", status="failed"}[1h]折线图（红色），叠加rate(...[5m])计算每分钟失败率。
• 中上部：model_inference_duration_seconds_bucket{le="0.1", model="fraud_detection_v2"}直方图，直观显示P90/P99延迟是否在SLA内（如P99<100ms）。
• 右侧：container_memory_usage_bytes{container="fraud-detection-server"}和gpu_memory_used_bytes{gpu="0"}双Y轴图，监控资源水位。

关键技巧：在Grafana中，为model_inference_duration_seconds_bucket设置Legend为{{le}}s，并勾选Show>Staircase，这样直方图会自动渲染成阶梯状，P99值一目了然。

看板2：特征漂移监测（Feature Drift Dashboard）

• 主图表：model_prediction_drift{metric="ks_test", feature=~".*", model="fraud_detection_v2"}的热力图（Heatmap），X轴为时间，Y轴为特征名，颜色深浅代表KS值。一眼看出哪个特征在何时开始漂移。
• 下方：model_feature_missing_rate{feature="user_age", model="fraud_detection_v2"}时间序列图，叠加告警阈值线（0.1）。

实操心得：热力图的Min/Max值必须手动设为0/1，否则自动缩放会让KS=0.05和KS=0.5看起来一样“安全”，失去预警意义。

看板3：影子流量评估（Shadow Traffic Dashboard）

• 对比图表：model_performance_degradation{metric="f1_score", model="fraud_detection_v2", version="v2.1.0"}vsmodel_performance_degradation{metric="f1_score", model="fraud_detection_v2", version="v2.0.0"}，用双Y轴展示新旧模型在线F1分数。
• 底部：rate(http_request_duration_seconds_count{path="/shadow-predict", model="fraud_detection_v2"}[1h])，监控影子流量采样率是否稳定（应恒定在10%）。

注意：影子流量必须独立于主流量，我们用Nginx的split_clients模块实现10%请求分流到/shadow-predict端点，该端点不返回结果给客户端，只用于评估。

这三张看板，构成了算法工程师每日晨会的“作战地图”。他们不再需要翻日志、查数据库，打开Grafana就能回答：“模型今天稳不稳？”、“哪个特征在作妖？”、“新版本到底有没有提升？”

5. 常见问题与排查技巧实录：那些文档里不会写的血泪教训

5.1 “指标采集了，但Grafana里看不到数据！”——最常见的5个原因

这是Part 4落地初期最高频的问题。根据我们27个模型的实施记录，原因分布如下：

踩过的坑：有一次，一个模型服务的/metrics端点返回了Content-Type: text/plain; charset=utf-8，但Prometheus期望text/plain; version=0.0.4。Grafana里完全空白，日志里只有一句invalid content type。我们花了3小时排查网络策略，最后发现是prometheus_client库版本太低（0.10.1），升级到0.17.1后自动修复。教训：永远先pip list \| grep prometheus确认SDK版本。

5.2 “告警狂响，但根本不是问题！”——如何驯服告警噪音

告警疲劳是MLOps最大的敌人。我们曾经历过一个模型，因上游数据源每晚2:00例行ETL，导致feature_missing_rate短暂飙升，触发每小时一次告警，持续7天。解决方案是引入“智能静默期”（Smart Silence）：

# alert-rules.yaml groups: - name: fraud-detection-alerts rules: - alert: HighFeatureMissingRate expr: avg_over_time(model_feature_missing_rate{feature="user_id", model="fraud_detection_v2"}[1h]) > 0.5 for: 10m labels: severity: warning annotations: summary: "High missing rate for user_id" description: "user_id missing rate is {{ $value }}% for last hour" # 【关键】添加静默期：每天2:00-2:15自动静默 silence_hours: - "2:00-2:15"

但这还不够。更高级的方案是动态基线告警：

# 不是固定阈值0.5，而是用过去7天同时间段的P95作为基线 avg_over_time(model_feature_missing_rate{feature="user_id", model="fraud_detection_v2"}[1h]) > ( quantile_over_time(0.95, model_feature_missing_rate{feature="user_id", model="fraud_detection_v2"}[7d]) * 2.0 )

这个PromQL的意思是：“如果当前缺失率超过过去7天同时间段缺失率P95的2倍，则告警”。它自动适应数据源的周期性波动，把告警从“绝对值超标”升级为“相对异常检测”。

5.3 “模型明明崩了，指标却显示一切正常？”——指标盲区的终极补救

最危险的情况，是监控体系本身失效。我们设计了三层防御：

第一层：指标自检（Metric Self-Check）
在/metrics端点，除了业务指标，我们强制暴露：

• ml_observability_sdk_last_scrape_timestamp_seconds{model="fraud_detection_v2"}：最后一次成功采集时间戳
• ml_observability_sdk_scrape_errors_total{model="fraud_detection_v2"}：采集失败次数
  然后配置告警：time() - ml_observability_sdk_last_scrape_timestamp_seconds{model="fraud_detection_v2"} > 120（2分钟未更新即告警）。

第二层：端点健康检查（Endpoint Health Check）
在Kubernetes中，为模型服务添加livenessProbe：

livenessProbe: httpGet: path: /healthz port: 8000 initialDelaySeconds: 30 periodSeconds: 10

/healthz端点不仅检查进程存活，还验证：

• 模型文件是否可加载（joblib.load()不报错）
• GPU是否可用（torch.cuda.is_available()）
• Redis缓存连接是否正常

第三层：影子流量兜底（Shadow Traffic Fallback）
当所有指标都“绿”时，我们仍每10分钟发起一次影子流量请求：

curl -X POST http://fraud-detection.internal/shadow-predict \ -H "Content-Type: application/json" \ -d '{"age":