prometheus 采用拉模型，需服务主动暴露 /metrics 接口返回符合文本协议的指标；支持 counter、gauge、histogram、summary 四类指标；配置时需确保网络可达、路径正确，并在 ui 中验证 target 状态为 up。
要让 Prometheus 抓取 Web 服务的运行状态，关键不是“让 Prometheus 主动发现连接”，而是让服务自己把指标以标准格式吐出来——也就是暴露一个 /metrics HTTP 接口。
指标必须由服务主动暴露
Prometheus 是“拉模型”：它定时向目标地址发 HTTP GET 请求，只认文本格式的指标数据。它不会、也不能主动建立 WebSocket 连接或探测 TCP 端口。所以监控任何 Web 服务的前提，是服务内部维护状态，并通过一个普通 HTTP 路由（比如 /metrics）返回符合 Prometheus 文本协议的指标内容。
常见误区包括：
- 用 blackbox_exporter 去“探测” WebSocket 地址 —— 协议不匹配，必然失败
- 在 Prometheus 配置里写
targets: ["localhost:8000"]却没在服务里实现/metrics路由 —— 抓不到数据，日志里只有 404 - 多个进程/线程各自维护计数器 —— 导致指标值错乱或归零
核心指标类型与选择逻辑
暴露什么指标，取决于你要监控什么。Prometheus 官方支持四类基础指标，每种适用场景不同：
-
Counter（计数器）：只增不减，适合统计总量，如
http_requests_total{method="GET",status="200"} -
Gauge（瞬时值）：可升可降，适合反映当前状态，如
active_websocket_connections、memory_usage_bytes -
Histogram（直方图）：按区间分桶统计分布，适合延迟类指标，如
http_request_duration_seconds_bucket{le="0.1"} - Summary（摘要）：直接计算分位数（如 P95），适合对延迟做快速响应判断
实际中，HTTP 请求量、错误数用 Counter；活跃连接数、内存占用用 Gauge；响应时间推荐 Histogram（兼顾查询灵活性和性能）。
代码层实现要点
无论用 Python、Go 还是 Java，暴露指标的核心步骤一致：
- 引入对应语言的
prometheus_client或client_golang库 - 在应用初始化时定义指标变量（如
REQUEST_COUNT = Counter(...)）并注册到全局 registry - 在业务逻辑关键路径埋点：请求入口 +1、出口 -1；耗时开始记录、结束观测；异常发生时 .inc() 错误计数
- 新增一个同步 HTTP 路由（如 FastAPI 的
@app.get("/metrics")），调用generate_latest()返回纯文本指标 - 确保所有指标操作发生在同一进程/事件循环内，避免多实例间状态不同步
Prometheus 配置与验证
服务跑起来后，先手动访问 http://your-service:port/metrics，确认返回内容是类似这样的纯文本：
http_request_duration_seconds_bucket{le="0.05"} 92
active_websocket_connections 3
再配置 Prometheus 的 scrape_configs，指定 job 名称、目标地址和 metrics_path：
- target 必须能被 Prometheus 网络访问到（容器内注意 host.docker.internal 或 service name）
- scrape_interval 建议设为 10–30 秒，太短增加负载，太长影响实时性
- 首次配置后，进 Prometheus UI 的 Status > Targets 页面，看对应 job 是否显示 UP
