https://cwiki.apache.org/confluence/display/KAFKA/KIP-714%3A+Client+metrics+and+observability

背景故事

隨著Kafka的應用越來越多越來越豐富，大家也會開始遇到各種陰陽怪氣的現象，因此集中監控和管理Kafka客戶端也逐漸成為一個重要的課題，但是你們會怎麼管理呢？是不是需要收集很多客戶端指標才好判讀數據？說到收集客戶端指標，身為JVM的一份子，我們想當而然就是使用JMX來暴露各種資訊，也可以把JMX的資訊串接到其他metrics收集的系統，如此就可以好好觀察各個客戶端應用的指標 ... 就這樣嘛？

當然事情沒這麼單純，如果只是以JMX來看的話，至少會有兩個問題，首先Java偉大是很偉大，但這個世界畢竟不是只有Java，光是靠JMX暴露指標就會形成不同系統指標串接上的麻煩，畢竟其他系統必須要能讀懂JMX指標。第二個則是就算串接可以使用JMX，但難道要每一個客戶端都安裝一個串接的角色嘛？這不是光想就覺得很恐怖，畢竟真實的應用場景下可能有成千上萬的客戶端應用，光是部屬和管理可能就會讓你晚上做惡夢。

這就是爲何Kafka要選擇整合OpenTelemetry，跟著業界已經成為知名標準的協定，Kafka 3.7.0之後可以將客戶端應用的各種指標以OpenTelemetry的格式封裝，然後傳遞和存放到Kafka伺服器端，換言之，上述的第一個問題就可以解決了，JMX不夠權威是吧？那麼我們現在用OpenTelemetry就沒話說了吧！至於第二個問題自然就是靠Kafka伺服器端來解決，成千上萬的客戶端在啟動telemetry後，都會自動定期的把指標傳遞到伺服器端，如此管理者就不需要再去部屬管理那些成千上萬的客戶端，只要好好地去伺服器那邊就可以把客戶端的各種指標以telemetry的格式拿走。

欸等等，伺服器端怎麼保存那些指標？該不會又是放在topic裡面？當然不是，或者說我們曾經想過這個方式，例如直接讓每個客戶端再內建一個producer來偷偷傳遞metrics到特定的topic，當然這樣做簡單省事但可能也有一些副作用，首先如剛剛提到的客戶端成千上萬，再讓每個內建一個複雜的producer，這個複雜就是好複雜成雙，不好不好。而且這樣還會出現一個尷尬的現象，那個用來傳metrics的producer是不是也需要一個producer幫他傳遞metrics。

所以呢，kafka選擇了一個簡單粗暴的方式，設計一組新的請求來專門傳遞metrics，同時在伺服器端允許維護者開發自己的接收者，也就是可以自己決定收到metrics後愛幹啥就幹啥，如此如此，我們就可以省去把資料放在topic的需求，同時也避免了尷尬的俄羅斯娃娃。

所以呢，如果你看到這裡覺得這個嶄新的metrics機制真的是太帥了，那就現在立刻馬上下載kafka 3.7以上的版本來玩玩看吧！

廣告

歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術