不能用start_http_server()，因其为单进程阻塞式服务，在Gunicorn/uWSGI多worker模式下会导致端口冲突、仅单worker生效，且各worker指标孤立不聚合，造成Counter统计失真；正确方式是使用django-prometheus通过PROMETHEUS_MULTIPROC_DIR统一收集多进程指标。
直接暴露 /metrics 端点即可，但必须用 django-prometheus（不是 prometheus-client 单独启动 HTTP 服务），否则会和 Django 的多进程/WSGI 模型冲突，指标丢失或统计不准。
为什么不能用 start_http_server() 在 Django 里？
Django 通常运行在 Gunicorn/uWSGI 多 worker 模式下。start_http_server() 是单进程阻塞式服务，每个 worker 都会尝试监听同一端口，导致启动失败或仅一个 worker 生效；更严重的是，各 worker 的指标互不共享，Counter 值在不同进程里各自计数，最终抓到的 http_requests_total 只是某个 worker 的局部值。
正确做法是让 Django 自身处理 /metrics 请求，由 django-prometheus 统一聚合所有 worker 的指标（通过 PROMETHEUS_MULTIPROC_DIR 环境变量启用多进程收集）。
- 别在
manage.py或wsgi.py里调用start_http_server(8000) - 不要手动注册
generate_latest(REGISTRY)到视图——除非你明确做了多进程同步，否则默认REGISTRY是空的 - 确认部署时设置了
PROMETHEUS_MULTIPROC_DIR（例如/var/tmp/prometheus-django），并确保该目录对所有 worker 进程可读写
如何验证 /metrics 是否返回有效数据？
访问 http://your-django-app/metrics（不是 /django-rq/metrics 或 /exporters/），响应体应为纯文本、每行以 # HELP 或指标名开头，且包含类似 django_http_requests_total_by_method_total{method="GET"} 的行。常见失败现象：
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 返回 404：检查
urls.py是否正确引入了django_prometheus.urls，路径是否拼写为path('metrics/', include('django_prometheus.urls')) - 返回空或
# HELP Error occured：说明视图执行异常，通常是PROMETHEUS_MULTIPROC_DIR权限不对或路径不存在 - 返回数据但全是
0.0：确认中间件已启用（PrometheusBeforeMiddleware和PrometheusAfterMiddleware），且请求确实经过了 Django 路由（静态文件、media 路径可能被白名单跳过）
哪些指标是开箱即用、值得立刻关注的？
django-prometheus 默认暴露三类核心指标，无需额外代码：
-
django_http_requests_total_by_method_total{method, view, status}：按方法、视图名、状态码统计请求数，用于查失败率和热点接口 -
django_http_requests_latency_seconds_by_view_total{view, method}：直方图，P95 延迟看django_http_requests_latency_seconds_by_view_bucket{le="0.5", ...} -
django_db_connections_total{alias}和django_db_queries_total{alias}：数据库连接池使用与查询次数，能快速识别慢查询或连接泄漏
注意：view 标签值来自 urlpatterns 中的 name 参数，如果没设 name=，会 fallback 到函数名（如 myapp.views.home），不利于 Grafana 分组——务必给关键 URL 配置语义化 name。
curl + Prometheus targets 页面是第一排查工具
别急着调 Grafana 面板。先在服务器上执行：
curl -v http://localhost:8000/metrics
再打开 Prometheus 的 Status > Targets 页面，确认你的 job 状态是 UP，且 scrape_samples_post_metric_relabeling 数值稳定增长。如果这里卡在 0，大概率是 relabel 配置过滤掉了所有指标（比如写了 regex: "django_.*" 却漏了下划线），或者 DNS/防火墙阻断了从 Prometheus 到 Django 的请求。
多进程指标收集依赖临时文件系统，PROMETHEUS_MULTIPROC_DIR 若挂载在内存盘（如 /dev/shm）需特别注意清理策略——残留旧 worker 的 .db 文件会导致新 worker 无法写入，表现为指标突然归零。
