总在不轻易间就留了个频繁GC的坑

最近有写一些关于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微服务 入门 实战与进阶》作者, 公众号猿天地发起人。