根本原因是指标暴露未显式启用：flask/fastapi需挂载中间件或调用start_http_server()，gunicorn需在post_fork中启动；histogram比summary更适合模型延迟监控，需合理设buckets并包裹完整推理流程。
模型预测延迟突增，prometheus_client 暴露指标没反应？
根本原因常是 Flask/FastAPI 启动时没挂载 MetricsMiddleware 或没调用 start_http_server()。Python 进程里指标暴露必须显式开启 HTTP 服务端口，不是“装了包就自动上报”。
实操建议：
- 用
prometheus_client时，别只 pip install 完事：FastAPI 项目需手动加中间件，Flask 项目得在应用启动后调用start_http_server(8000) -
Counter、Gauge等指标对象必须定义在模块顶层（非函数内），否则每次请求重建实例，历史值清零 - 若用 Gunicorn 部署，
start_http_server()要放在post_fork钩子里，否则只有主进程监听，worker 进程不暴露指标 - 验证是否生效：直接
curl http://localhost:8000/metrics，看到# HELP开头的文本才算通
怎么采集模型推理耗时？Summary 和 Histogram 到底选哪个
Summary 直接算分位数（如 p95），但客户端计算、不可聚合；Histogram 在服务端打点、支持跨实例聚合，适合线上监控。模型延迟要看全局趋势和异常尖峰，必须用 Histogram。
实操建议：
- 定义
Histogram时设好buckets：模型延迟常见于 10ms–2s 区间，推荐[0.01, 0.05, 0.1, 0.2, 0.5, 1.0, 2.0]，太密浪费存储，太疏看不清拐点 - 务必在预测函数最外层用
with predict_latency.time():包裹，别在预处理或后处理里计时——那不是真实推理延迟 - 如果用 PyTorch，注意
.cuda()和.cpu()同步开销大，time()要包住整个model(input)调用，不能只包 forward
Prometheus 抓不到指标？检查这三处 scrape_config
Prometheus 配置写错一个字段，整个 job 就静默失败，连 error log 都不打。最常卡在 target 发现和协议细节上。
实操建议：
-
targets写的是容器名还是宿主机 IP？Docker Compose 里用host.docker.internal，K8s 里用service-name.namespace.svc.cluster.local -
metrics_path默认是/metrics，但有些框架（如 MLflow）暴露在/monitoring/metrics，漏写就 404 -
scheme别默认 http：如果模型服务启了 HTTPS 但没配insecure_skip_verify: true，抓取直接超时，且 Prometheus 不报错，只显示 “DOWN”
Grafana 看板里 rate() 曲线毛刺多、数值跳变
rate() 对计数器做每秒速率计算，但原始采样间隔不稳定或数据断点，会导致结果失真。模型 QPS 低时（比如每分钟几笔请求），rate(predict_total[5m]) 可能频繁归零又突增。
实操建议：
- 改用
irate()查看最近两个点的瞬时变化，适合调试；生产看板一律用rate()，但区间至少设成[10m]，避免分钟级抖动 - 如果模型请求稀疏，把
Counter改成Gauge记当前并发请求数，再用avg_over_time(concurrent_requests[5m])更稳 - 确认 Prometheus 的
scrape_interval≤ 15s，否则低频请求可能被漏采——尤其当模型 batch size 大、实际调用间隔长时
指标埋点位置、Prometheus 抓取节奏、Grafana 查询区间，这三者的时间尺度必须对齐，差一拍，图就不是你想看的那个“实时”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
