今天分享一个在实践过程中遇到的问题,也许你也遇到过。
针对 RPC 服务做埋点的时候,想知道下面这些指标:
会有下面的代码进行指标的暴露:
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 微服务 入门 实战与进阶》作者, 公众号猿天地发起人。
- END -