谈谈rpc的监控

监控的四个黄金指标

• 延迟
• 流量
• 错误
• 饱和度

见google-sre-ebook, 对rpc来说. 我做监控图表时一般是qps/rtt/error, qps对应饱和度和流量(对特定业务做过压测的情况下), rtt(query round trip time)对应延迟。error就不用说了.

监控坑

qps和rtt没有分开counter和histogram

曾经只用histogram做qps和rtt. 这样做的问题在于, 当请求超时时, histogram的count会先下降再上升. 正确的做法是

counter_inc
start_time = now()
call
end_time = now()
histogram

应该用rate统计qps

如

sum(rate(xxxx_count{app="xxx"}[30s])) by (method)

注意采集频率对结果的影响

比如, 5S采集一次. 那么, rate统计的是5S内的平均qps. 实际qps不会平均分布.

用irate统计特定情况下会严重失真.

如下, irate统计qps是0, rate有值, 但也不是真实qps. 实际的请求集中在一瞬间(采集频率对结果的影响).

应该结合平均值, 中位数, %99尾部延迟统计rtt

平均值:

sum(rate(xxx_ts_sum{app="xxx"}[5s])) by (api) / sum(rate(xxx_ts_count{app="xxx"}[5s])) by (api)

中位数:

histogram_quantile(0.5, sum(rate(xxx_ts_bucket{app="xxx"}[30s])) by (le, method))

%99:

histogram_quantile(0.99, sum(rate(xxx_ts_bucket{app="xxx"}[30s])) by (le, method))

按中位数, P99统计rtt时, 要注意buckets的范围

wget http://localhost:9090/metrics如下, 只记录了每个区间请求的数量.
假设buckets 只有[0, 1000, 5000], 而所有请求都是100ms, 统计中位数, p99时, 都会统计为500ms. 因为无法得知0 至 1000ms的具体分布情况.
所以, 在高度集中分布的区间, 需要将buckets划分得细致一些.
同时, 在分析尾部延迟时, 要注意buckets造成的统计偏差.

# TYPE http_ts histogram
# HELP http_ts Http Post execution time.
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="2"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="5"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="10"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="25"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="50"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="100"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="250"} 1
http_ts_bucket{host_name="ubuntu",app="nil",method="post",api="http://127.0.0.1/test",code="200",le="500"} 1