counter比gauge更适合吞吐量，因其记录只增不减的累计请求数，支持速率计算且避免瞬时值干扰；实操需正确初始化、避免重复统计、规范标签、显式配置导出器并优化高并发性能。
go 里用 otelmetric 记录吞吐量，为什么 Counter 比 Gauge 更合适
吞吐量本质是单位时间内的请求数累加值，属于“只增不减”的计数型指标。用 Gauge 存当前瞬时值，会丢失历史趋势、无法做速率计算（比如 rate()），还容易被采样或上报延迟干扰。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Counter是 OpenTelemetry Go SDK 的默认推荐类型，底层自动支持累积和标签维度切分 - 初始化时必须传入
instrumentation.Scope，否则指标可能静默丢弃（无报错） - 不要在 http handler 内反复调用
counter.Add()前做 if 判断——OpenTelemetry 的 Add 是原子且轻量的，判断反而增加分支开销 - 示例：
counter := meter.NewInt64Counter("http.requests.total")<br>counter.Add(ctx, 1, metric.WithAttributes(attribute.String("method", "GET")))
HTTP 中间件里埋点，怎么避免重复统计和 context 泄漏
常见错误是把 counter.Add() 放在中间件最外层，结果 panic 恢复、重定向、静态文件等路径都计入，或者用 req.Context() 但没传入 span context，导致指标脱离 trace 上下文。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 只在真正进入业务逻辑前调用
Add()，比如 gin 的c.Next()之后、或 http.ServeHTTP 的 handler 执行前 - 务必使用带 span 的 context：
span := trace.SpanFromContext(r.Context())，再传给counter.Add(span.Context(), ...) - 避免在 defer 里调用
Add()——如果 handler panic，defer 可能执行多次；更稳妥的是在 handler 结束时显式调用一次 - 别把
http.Request.URL.Path直接当标签值，需先 normalize（如 /user/123 → /user/{id}），否则标签爆炸导致指标后端 OOM
本地调试时看不到指标数据？检查这三处硬编码陷阱
OpenTelemetry Go 的 metrics 默认不导出，且 SDK 初始化顺序敏感。本地跑起来没数据，90% 是配置链断在某环。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须显式注册
controller.prometheus或controller.Push，不能只建MeterProvider -
controller.Prometheus的Handler()要挂到 HTTP server 上，路径通常是/metrics，但 Go 的http.Handle()不支持带前缀的子路由，直接http.Handle("/metrics", promHandler) - 环境变量
OTEL_METRICS_EXPORTER=none会静默禁用所有导出器——检查os.Getenv("OTEL_METRICS_EXPORTER")是否被误设 - 示例初始化片段：
provider := metric.NewMeterProvider(metric.WithReader(controller.NewPrometheus()))<br>otel.SetMeterProvider(provider)<br>http.Handle("/metrics", promHandler)
高并发下 Counter.Add() 性能掉得厉害？别碰锁，改用批量模式
单次 Add() 在百万 QPS 下会有明显原子操作竞争，尤其带多个属性时。不是函数慢，而是高频调用触发了 CPU cache line bouncing。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
BatchObserver替代高频单点Counter：把每秒请求数聚合后一次性上报，降低调用频次 - 避免在循环内新建
attribute.KeyValue，提前定义好常量：methodGet := attribute.String("method", "GET") - 确认是否启用了
WithResource——资源属性（如 service.name）应全局设置一次，而非每次 Add 都传 - 如果用 Prometheus exporter，注意其
scrape_interval默认 10s，本地压测看实时性要调低，但别低于 1s（Prometheus 自身限制）
吞吐量指标真正的复杂点不在埋点本身，而在标签设计和生命周期对齐：HTTP path 标签要不要带 query？Error 状态该不该拆成独立 counter？这些决策一旦上线就很难回退。