最近有寫一些關(guān)于prometheus監(jiān)控的文章，也是在實(shí)踐這塊的內(nèi)容。
- 天天CRUD的我，也想玩玩高大上的Prometheus
- Prometheus為你的微服務(wù)保駕護(hù)航
- 用了很多年Dubbo，連Dubbo線程池監(jiān)控都不知道，覺得自己很厲害？
- 思考：prometheus 告警為什么選用alertmanager？
今天分享一個(gè)在實(shí)踐過程中遇到的問題，也許你也遇到過。
針對(duì)RPC服務(wù)做埋點(diǎn)的時(shí)候，想知道下面這些指標(biāo)：
- QPS
- 響應(yīng)時(shí)間
- 被哪個(gè)服務(wù)調(diào)用了
- 被哪個(gè)接口調(diào)用了
會(huì)有下面的代碼進(jìn)行指標(biāo)的暴露：
Counter.builder("dubbo.request.total").description("請(qǐng)求數(shù)量")
.tags(Tags.of(apiTag, typeTag, originApplicationTag, originApiTag))
.register(meterRegistry).increment();
apiTag：比說OrderService.createOrder
typeTag：success, error, timeout等
originApplicationTag: 來源的服務(wù)名稱，比如goods-service
originApiTag：來源的API信息，比如GET:goods/1001
在程序中會(huì)通過/actuator/prometheus進(jìn)行數(shù)據(jù)的暴露，格式如下：
dubbo_request_total{api="GoodsRemoteService.get(int)",originApplication="order-service",originApi="order/1001",type="success",} 59.0
dubbo_request_total這個(gè)指標(biāo)會(huì)產(chǎn)生N條，N的決定因素就是dubbo_request_total中這些tag值的重復(fù)度，也就是完全一樣的數(shù)據(jù)只有一條，如果有一個(gè)tag不一樣，就會(huì)新產(chǎn)生一條數(shù)據(jù)。
上線后沒多久，就收到了頻繁GC的告警。然后排查下來發(fā)現(xiàn)指標(biāo)數(shù)據(jù)已經(jīng)堆積了很多。根本原因在originApi，因?yàn)榻涌谑荝estful風(fēng)格的資源形式，所以一個(gè)接口會(huì)產(chǎn)生N條數(shù)據(jù)，比如order/1001, order/1002 等。
時(shí)間越來越長(zhǎng)，被訪問的數(shù)據(jù)范圍也就越大，內(nèi)存中堆積的數(shù)據(jù)也就越多，然后就出問題了。
Restful風(fēng)格的資源形式在其他的場(chǎng)景中也經(jīng)常會(huì)遇到，比如用Sentinel限流的時(shí)候也是一樣，在后臺(tái)也是會(huì)顯示很多資源，也得做格式化才行。
關(guān)于作者：尹吉?dú)g，簡(jiǎn)單的技術(shù)愛好者，《Spring Cloud微服務(wù)-全棧技術(shù)與案例解析》, 《Spring Cloud微服務(wù) 入門 實(shí)戰(zhàn)與進(jìn)階》作者, 公眾號(hào)猿天地發(fā)起人。
