最近有写一些关于prometheus监控的文章，也是在实践这块的内容。
- 天天CRUD的我，也想玩玩高大上的Prometheus
- Prometheus为你的微服务保驾护航
- 用了很多年Dubbo，连Dubbo线程池监控都不知道，觉得自己很厉害？
- 思考：prometheus 告警为什么选用alertmanager？
今天分享一个在实践过程中遇到的问题，也许你也遇到过。
针对RPC服务做埋点的时候，想知道下面这些指标：
- QPS
- 响应时间
- 被哪个服务调用了
- 被哪个接口调用了
会有下面的代码进行指标的暴露：
Counter.builder("dubbo.request.total").description("请求数量")
.tags(Tags.of(apiTag, typeTag, originApplicationTag, originApiTag))
.register(meterRegistry).increment();
apiTag：比说OrderService.createOrder
typeTag：success, error, timeout等
originApplicationTag: 来源的服务名称，比如goods-service
originApiTag：来源的API信息，比如GET:goods/1001
在程序中会通过/actuator/prometheus进行数据的暴露，格式如下：
dubbo_request_total{api="GoodsRemoteService.get(int)",originApplication="order-service",originApi="order/1001",type="success",} 59.0
dubbo_request_total这个指标会产生N条，N的决定因素就是dubbo_request_total中这些tag值的重复度，也就是完全一样的数据只有一条，如果有一个tag不一样，就会新产生一条数据。
上线后没多久，就收到了频繁GC的告警。然后排查下来发现指标数据已经堆积了很多。根本原因在originApi，因为接口是Restful风格的资源形式，所以一个接口会产生N条数据，比如order/1001, order/1002 等。
时间越来越长，被访问的数据范围也就越大，内存中堆积的数据也就越多，然后就出问题了。
Restful风格的资源形式在其他的场景中也经常会遇到，比如用Sentinel限流的时候也是一样，在后台也是会显示很多资源，也得做格式化才行。
关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。
网友评论