來這公司一年碰到的問題比我過去10年都多

來源：艾小仙

無意間發現我們 Kafka 管理平臺的服務的 open files 和 CPU 監控異常，如下圖，有一臺機器 CPU 和 opfen files 指標持續在高位，尤其是 open files 達到了4w+。

原因分析

第一反應是這個服務請求很高？但是這個服務是一個管理服務不應該有很高的請求量才對，開啟監控一看，QPS少的可憐。

既然機器還在就找 devops 同學幫忙使用 Arthas 簡單看下是什麼執行緒導致的，竟然是 GC 執行緒，瞬時 CPU 幾乎打滿了。

檢視了 GC 監控，每分鐘 5~6 次相比其他的正常節點要多很多，並且耗時很長。

問題節點GC Count

正常節點GC Count

應該是程式碼出問題了，繼續求助 devops 將線上有問題的機器拉了一份 dump，使用 MAT 工具分析了下，開啟 dump 就提示了兩個風險點，兩個都像是指標相關的物件。

檢視詳情發現兩個可疑物件，一個是 60+M 的 byte[]， 一個是 60+M 的 map，都是指標相關的物件，問題應該出在指標上。

初步去排查了下程式碼，看是否有自定義指標之類的，發現一個 job 會對指標進行操作，就把 job 停了一段時間，GC 少了很多，但是 open files 只減少了一點點， 很明顯不是根本原因。

繼續深入，將 byte[] 儲存成字串檢視(確實文字也有60+M)，發現全是 JMX 的指標資料，我們的系統使用了兩種指標一種是Micrometer，一種是 prometheus-jmx-exporter，這個 byte[] 陣列就是第二種指標的資料。

並且這些指標中發現有非常多的 kafka_producer 開頭的指標。

為了驗證是否屬於 JMX 的指標資料，再次求助 devops 拉取線上有問題機器的 JMX 指標介面， 看返回的是否是 60M+ 的指標資料，發現根本拉不下來。

到此基本確認問題出在 JMX 指標上， 那這些指標誰註冊的呢?

透過指標名稱在原始碼裡搜尋，發現是來自org.apache.kafka.common.network.Selector.SelectorMetrics，是 kafka-client註冊的指標。

具體的建立順序如下，每建立一個KafkaProducer，就會以 client id 為唯一標識建立一個SelectorMetrics， 而建立 KafkaProducer 會建立一個守護執行緒，並開啟一個長連線定時去 Broker 拉取/更新 Metadata 資訊，這個就是open files飆高的根本原因。

KafkaProducer -> Sender -> Selector -> SelectorMetrics

難道建立了很多 KafkaProducer？？？檢視構造方法呼叫的地方，找到了真兇。。。

這段程式碼是為了支援延遲訊息，業務服務每發一個延遲訊息，就會執行一次這段邏輯， 就會建立一個 KafkaProducer，並且會隨著收到的訊息越來越多導致建立的 KafkaProducer 越來越多，直至系統無法承受。。。

慶幸的是我們延遲訊息並不是太多，沒有直接把系統給打掛掉

那為什麼只有一個節點會有問題，其他節點沒有問題呢？這個比較簡單直接說結果了，就是這段消費邏輯消費的 topic 只有一個分割槽....

解決方案:

由於 Kafka 管理平臺會連線多個 Broker，所以此處將建立的 KafkaProducer 根據 Cluster 快取起來進行復用。

問題總結:

1. 1. KafkaProducer 本身是一個很重的物件，並且執行緒安全，建立的時候注意考慮場景

2. 2. 此次問題完全是憑運氣提前發現了，證明監控系統也存在不夠完善的地方， 我們使用 Prometheus 的標準差函式 (stddev() by()) 配置了資源嚴重傾斜的監控告警，防止出現類似的問題。