mbvar 如何通过 LatencyRecorder 获取平均耗时
- Dominant language
- C++
- Stars
- 17.6k
- Forks
- 4.1k
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 69
Description
**Describe the bug (描述bug)**
mbvar 的 prometheus 的上报格式如下:
service_latency{valid="false"} 0
service_latency{valid="false",quantile="80"} 0
service_latency{valid="false",quantile="90"} 0
service_latency{valid="false",quantile="99"} 0
service_latency{valid="false",quantile="999"} 0
service_latency{valid="false",quantile="9999"} 0
service_max_latency{valid="false"} 0
service_qps{valid="false"} 0
service_count{valid="false"} 1
此时没办法通过:avg(service_latency{valid="false"}) 来获取平均耗时,因为 avg 会把所有 service_latency 求平均,包括了 p99等数值。
而 bvar 的 LatencyRecorder 通过拆分名字 latency/latency_99 避免了平均耗时的求 avg 的问题。这应该是 mbvar 的 bug 吧,没办法统计平均耗时了
**To Reproduce (复现方法)**
**Expected behavior (期望行为)**
**Versions (各种版本)**
OS:
Compiler:
brpc:
protobuf:
**Additional context/screenshots (更多上下文/截图)**
Contributor guide
Research direction
Start by tracing how mbvar formats service_latency and related Prometheus metrics, then compare that behavior with bvar's LatencyRecorder naming described in the issue. Determine how average latency should be distinguishable from quantile values and verify the resulting metrics can be aggregated with avg().
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100