必须用 counter 记录累计请求数，如 http_requests_total，每次请求 increment()；禁用 gauge 统计 qps，因其跳变会导致 rate() 失真；标签仅限 method、endpoint、status 等低基数字段，避免 url、用户 id 等高基数字段引发序列爆炸。
必须用 Counter，别碰 Gauge
QPS 是速率指标，不是瞬时值。用 Gauge 手动 Set() 每秒请求数，会导致 Prometheus 的 rate() 无法正确计算——因为 rate() 只对单调递增的累计值（如 Counter）做差分求导。Gauge 值跳变、归零、回退都会让结果失真，甚至出现负值或 NaN。
所以埋点第一步就定死：只用 Counter 记录累计请求数，例如 api_called_total，每次请求进来调一次 Increment()。
构建 Counter 要带标签，但别滥用高基数字段
标签（Labels）用于多维下钻分析，但错误使用会撑爆 Prometheus 内存。比如把完整 URL、用户 ID、UUID 当作 label，会导致时间序列爆炸（cardinality explosion）。
推荐做法：
- 固定维度：用
method、endpoint、status这类有限枚举值作为 label - 避免动态值：不使用
request.args、request.url全路径、X-Request-ID等每次请求都不同的字段 - C++ 示例中，应这样注册并打点：
auto& counter_family = BuildCounter()
.Name("http_requests_total")
.Help("Total HTTP requests")
.Labels({{"job", "my_cpp_service"}})
.Register(*registry);
auto& req_counter = counter_family.Add({{"method", "POST"}, {"endpoint", "/v1/chat"}, {"status", "200"}});
req_counter.Increment();
rate() 结果为 0 或 NaN？检查抓取频率和窗口匹配
rate(http_requests_total[1m]) 要求在 1 分钟窗口内至少有 2 个有效样本。如果 Prometheus 的 scrape_interval 设为 30s，那每分钟最多 2 个点；若中间漏采一次，窗口内只剩 1 个点，rate() 就返回 0 或 NaN。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
排查要点：
- 确认
scrape_interval≤ 30s（建议 15s），且 C++ 服务的/metrics端点稳定响应 - 检查
http_requests_total在 Prometheus 表达式浏览器里是否持续递增（而非卡住不动） - 重启 C++ 进程后，Counter 归零是正常行为；Prometheus 自动检测翻转（reset detection），但前提是你的 SDK 正确实现了 reset 语义（主流 C++ client 如
prometheus-cpp支持）
异常 QPS 单独建 Counter，别混进主计数器
业务异常（如参数校验失败、下游超时）需要独立统计，否则会污染主 QPS 曲线，导致容量评估偏差。
做法很简单：
- 定义另一个
Counter，比如app_exceptions_total - 在最外层异常捕获处（如 HTTP handler 的 try/catch 最外侧）调用
Increment() - 加
type和layer标签区分场景，例如：{type="validation", layer="api"} - PromQL 查异常 QPS：
rate(app_exceptions_total[1m])
真正容易被忽略的是：C++ 中 metrics registry 必须是进程全局单例，不能每个请求 new 一个，否则指标不会聚合，rate() 会始终为 0。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
