brpc内置HTTP监控服务需显式设置options.http_port（默认0禁用），启用后/status、/vars、/metrics、/flags等路径才生效，各路径功能独立：/status返回聚合指标概览（加?console=1为纯文本），/vars提供原始键值对计数器供脚本解析，/metrics需手动注册并符合Prometheus文本协议规范，/flags支持部分gflags热更新。
启动时开启 http_port 就能暴露监控接口
brpc 的内置 HTTP 服务不是独立组件，而是 Server 启动时通过 options.http_port 显式启用的。不设这个值，/status、/vars 等路径根本不会响应——哪怕服务跑起来了，curl http://localhost:8080/status 也会返回 404。
关键点在于：它和 RPC 主端口（如 server.Start(8000, &options) 中的 8000）是分离的，http_port 是额外监听的端口，专用于监控和调试。
-
http_port = 0表示禁用，这是默认行为 -
http_port = 8080表示监听 8080，所有内置路径都走这个端口 - 如果机器有防火墙或 Kubernetes Service 暴露限制，必须确保该端口在容器/POD 中开放并映射到宿主机
/status 和 /vars 返回内容差异大，别混用
/status 是概览页，返回服务生命周期、连接数、线程数、QPS、延迟分布等聚合指标，适合人工快速判断“服务挂没挂、压得重不重”。而 /vars 是原始计数器列表，比如 rpc_count、rpc_latency、connection_count，每一行一个键值对，适合脚本解析或 Prometheus 抓取。
常见误操作是用浏览器打开 /vars 想看“实时图表”，结果只看到满屏文本；或者用 curl 直接请求 /status 却没加 ?console=1，返回的是 HTML 页面源码（含 JS），无法直接 pipe 给 jq 或做自动化判断。
- 命令行查状态：用
curl "http://localhost:8080/status?console=1"获取纯文本格式 - 脚本采集指标：直接 GET
/vars，无需参数，响应体是每行key value的格式 - 想看图形化界面？必须用浏览器访问
/status（不带?console=1），它会加载内置前端
对接 Prometheus 必须用 DumpPrometheusMetricsToIOBuf
brpc 原生支持 Prometheus 格式，但不是靠简单转发 /vars 实现的。它的 /metrics 路径（需显式注册）底层调用的是 DumpPrometheusMetricsToIOBuf 函数，该函数把 bvar 指标转成标准 Prometheus 文本格式（# TYPE ... + metric_name{labels} value），包括类型声明、HELP 注释、样本时间戳等完整字段。
如果你自己写 handler 把 /vars 的输出硬塞给 Prometheus，会报错：text format parsing error in line 1: invalid metric name——因为 /vars 输出根本不满足 Prometheus 的文本协议规范。
- 默认不提供
/metrics路径，需手动注册：调用brpc::AddBuiltinServices(&server)或自行添加brpc::PrometheusMetricsService - 确认路径生效：
curl http://localhost:8080/metrics | head -n 5应看到类似# HELP rpc_count Total number of RPC calls的内容 - Kubernetes 中配置 Prometheus ServiceMonitor 时，
metrics_path必须设为/metrics，不是/vars
/flags 支持热更新，但部分参数改了不生效
/flags 页面允许运行时修改 gflags 参数，比如 max_concurrency、idle_timeout_sec，点击右侧 (R) 输入新值后立即生效，无需重启。这对线上紧急调参非常有用。
但要注意：不是所有 flag 都支持热更新。例如 http_port 本身就在 Server 启动后固定，改了 /flags 里的值也不会重新监听端口；再比如 num_threads（工作线程数）在 Server 启动后不可变，改了只是覆盖内存变量，实际线程池大小不变。
- 哪些能热更？看 brpc 源码里对应 flag 是否被
bvar::GFlag包装，并在逻辑中定期读取（如bvar::GFlag<int> idle_timeout_sec("idle_timeout_sec")</int>） - 不确定时，最稳妥方式是查
/flags页面——能点开编辑框的，基本就是支持热更的 - 生产环境慎用热更：某些参数变更可能触发内部状态重建，引发短暂抖动，建议先在预发验证
brpc 的 HTTP 监控能力很轻量，但每个路径的行为逻辑、数据格式和适用场景都不同。最容易被忽略的是：它没有“全局开关”控制所有监控路径，http_port 开启后，/status、/vars、/metrics、/flags 是各自独立注册的，漏掉某一个就少一块关键能力。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
