今天給大家來聊聊關于Kafka的具體監控工具或監控框架。

令人有些遺憾的是，Kafka社區似乎一直沒有在監控框架方面投入太多的精力。目前，Kafka的新功能提議已超過500個，但沒有一個提議是有關監控框架的。當然，Kafka的確提供了超多的JMX指標，只是，單獨查看這些JMX指標往往不是很方便，我們還是要依賴于框架統一地提供性能監控。

也許，正是由于社區的這種“不作為”，很多公司和個人都自行著手開發Kafka監控框架，其中并不乏佼佼者。今天我們就來全面地梳理一下主流的監控框架。

JMXTool工具

首先，我向你推薦JMXTool工具。嚴格來說，它并不是一個框架，只是社區自帶的一個工具罷了。JMXTool工具能夠實時查看Kafka JMX指標。倘若你一時找不到合適的框架來做監控，JMXTool可以幫你“臨時救急”一下。

Kafka官網沒有JMXTool的任何介紹，你需要運行下面的命令，來獲取它的使用方法的完整介紹。

bin/kafka-run-class.sh kafka.tools.JmxTool

JMXTool工具提供了很多參數，但你不必完全了解所有的參數。我把主要的參數說明列在了下面的表格里，你至少要了解一下這些參數的含義。

圖片

現在，我舉一個實際的例子來說明一下如何運行這個命令。

假設你要查詢Broker端每秒入站的流量，即所謂的JMX指標BytesInPerSec，這個JMX指標能幫助你查看Broker端的入站流量負載，如果你發現這個值已經接近了你的網絡帶寬，這就說明該Broker的入站負載過大。你需要降低該Broker的負載，或者將一部分負載轉移到其他Broker上。

下面這條命令，表示每5秒查詢一次過去1分鐘的BytesInPerSec均值。

bin/kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec --jmx-url service:jmx:rmi:///jndi/rmi://:9997/jmxrmi --date-format "YYYY-MM-dd HH:mm:ss" --attributes OneMinuteRate --reporting-interval 1000

在這條命令中，有幾點需要你注意一下。

• 設置 –jmx-url參數的值時，需要指定JMX端口。在這個例子中，端口是9997，在實際操作中，你需要指定你的環境中的端口。
• 由于我是直接在Broker端運行的命令，因此就把主機名忽略掉了。如果你是在其他機器上運行這條命令，你要記得帶上要連接的主機名。
• 關于 –object-name參數值的完整寫法，我們可以直接在Kafka官網上查詢。我們在前面說過，Kafka提供了超多的JMX指標，你需要去官網學習一下它們的用法。我以ActiveController JMX指標為例，介紹一下學習的方法。你可以在官網上搜索關鍵詞ActiveController，找到它對應的 –object-name，即kafka.controller:type=KafkaController,name=ActiveControllerCount，這樣，你就可以執行下面的腳本，來查看當前激活的Controller數量。
  
  

$ bin/kafka-run-class.sh kafka.tools.JmxTool –object-name kafka.controller:type=KafkaController,name=ActiveControllerCount –jmx-url service:jmx:rmi:///jndi/rmi://:9997/jmxrmi –date-format “YYYY-MM-dd HH:mm:ss” –reporting-interval 1000 Trying to connect to JMX url: service:jmx:rmi:///jndi/rmi://:9997/jmxrmi. “time”,“kafka.controller:type=KafkaController,name=ActiveControllerCount:Value” 2019-08-05 15:08:30,1 2019-08-05 15:08:31,1

總體來說，JMXTool是社區自帶的一個小工具，對于一般簡單的監控場景，它還能應付，但是它畢竟功能有限，復雜的監控整體解決方案，還是要依靠監控框架。

Kafka Manager

說起Kafka監控框架，最有名氣的當屬Kafka Manager了。Kafka Manager是雅虎公司于2015年開源的一個Kafka監控框架。這個框架用Scala語言開發而成，主要用于管理和監控Kafka集群。

應該說Kafka Manager是目前眾多Kafka監控工具中最好的一個，無論是界面展示內容的豐富程度，還是監控功能的齊全性，它都是首屈一指的。不過，目前該框架已經有4個月沒有更新了，而且它的活躍的代碼維護者只有三四個人，因此，很多Bug或問題都不能及時得到修復，更重要的是，它無法追上Apache Kafka版本的更迭速度。

當前，Kafka Manager最新版是2.0.0.2。在其Github官網上下載tar.gz包之后，我們執行解壓縮，可以得到kafka-manager-2.0.0.2目錄。

之后，我們需要運行sbt工具來編譯Kafka Manager。sbt是專門用于構建Scala項目的編譯構建工具，類似于我們熟知的Maven和Gradle。Kafka Manager自帶了sbt命令，我們直接運行它構建項目就可以了：

./sbt clean dist

經過漫長的等待之后，你應該可以看到項目已經被成功構建了。你可以在Kafka Manager的target/universal目錄下找到生成的zip文件，把它解壓，然后修改里面的conf/application.conf文件中的kafka-manager.zkhosts項，讓它指向你環境中的ZooKeeper地址，比如：

kafka-manager.zkhosts="localhost:2181"

之后，運行以下命令啟動Kafka Manager：

bin/kafka-manager -Dconfig.file=conf/application.conf -Dhttp.port=8080

該命令指定了要讀取的配置文件以及要啟動的監聽端口。現在，我們打開瀏覽器，輸入對應的IP:8080，就可以訪問Kafka Manager了。下面這張圖展示了我在Kafka Manager中添加集群的主界面。

圖片

注意，要勾選上Enable JMX Polling，這樣你才能監控Kafka的各種JMX指標。下圖就是Kafka Manager框架的主界面。

圖片

從這張圖中，我們可以發現，Kafka Manager清晰地列出了當前監控的Kafka集群的主題數量、Broker數量等信息。你可以點擊頂部菜單欄的各個條目去探索其他功能。

除了豐富的監控功能之外，Kafka Manager還提供了很多運維管理操作，比如執行主題的創建、Preferred Leader選舉等。在生產環境中，這可能是一把雙刃劍，畢竟這意味著每個訪問Kafka Manager的人都能執行這些運維操作。這顯然是不能被允許的。因此，很多Kafka Manager用戶都有這樣一個訴求：把Kafka Manager變成一個純監控框架，關閉非必要的管理功能。

慶幸的是，Kafka Manager提供了這樣的功能。你可以修改config下的application.conf文件，刪除application.features中的值。比如，如果我想禁掉Preferred Leader選舉功能，那么我就可以刪除對應KMPreferredReplicaElectionFeature項。刪除完之后，我們重啟Kafka Manager，再次進入到主界面，我們就可以發現之前的Preferred Leader Election菜單項已經沒有了。

圖片

總之，作為一款非常強大的Kafka開源監控框架，Kafka Manager提供了豐富的實時監控指標以及適當的管理功能，非常適合一般的Kafka集群監控，值得你一試。

Burrow

我要介紹的第二個Kafka開源監控框架是Burrow。Burrow是LinkedIn開源的一個專門監控消費者進度的框架。事實上，當初其開源時，我對它還是挺期待的。畢竟是LinkedIn公司開源的一個框架，而LinkedIn公司又是Kafka創建并發展壯大的地方。Burrow應該是有機會成長為很好的Kafka監控框架的。

然而令人遺憾的是，它后勁不足，發展非常緩慢，目前已經有幾個月沒有更新了。而且這個框架是用Go寫的，安裝時要求必須有Go運行環境，所以，Burrow在普及率上不如其他框架。另外，Burrow沒有UI界面，只是開放了一些HTTP Endpoint，這對于“想偷懶”的運維來說，更是一個減分項。

如果你要安裝Burrow，必須要先安裝Golang語言環境，然后依次運行下列命令去安裝Burrow：

$ go get github.com/linkedin/Burrow
$ cd $GOPATH/src/github.com/linkedin/Burrow
$ dep ensure
$ go install

等一切準備就緒，執行Burrow啟動命令就可以了。

$GOPATH/bin/Burrow --config-dir /path/containing/config

總體來說，Burrow目前提供的功能還十分有限，普及率和知名度都是比較低的。不過，它的好處是，該項目的主要貢獻者是LinkedIn團隊維護Kafka集群的主要負責人，所以質量是很有保證的。如果你恰好非常熟悉Go語言生態，那么不妨試用一下Burrow。

JMXTrans + InfluxDB + Grafana

除了剛剛說到的專屬開源Kafka監控框架之外，其實現在更流行的做法是，在一套通用的監控框架中監控Kafka，比如使用JMXTrans + InfluxDB + Grafana的組合。由于Grafana支持對JMX指標的監控，因此很容易將Kafka各種JMX指標集成進來。

我們來看一張生產環境中的監控截圖。圖中集中了很多監控指標，比如CPU使用率、GC收集數據、內存使用情況等。除此之外，這個儀表盤面板還囊括了很多關鍵的Kafka JMX指標，比如BytesIn、BytesOut和每秒消息數等。將這么多數據統一集成進一個面板上直觀地呈現出來，是這套框架非常鮮明的特點。

圖片

與Kafka Manager相比，這套監控框架的優勢在于，你可以在一套監控框架中同時監控企業的多個關鍵技術組件。特別是對于那些已經搭建了該監控組合的企業來說，直接復用這套框架可以極大地節省運維成本，不失為一個好的選擇。

Confluent Control Center

最后，我們來說說Confluent公司發布的Control Center。這是目前已知的最強大的Kafka監控框架了。

Control Center不但能夠實時地監控Kafka集群，而且還能夠幫助你操作和搭建基于Kafka的實時流處理應用。更棒的是，Control Center提供了統一式的主題管理功能。你可以在這里享受到Kafka主題和Schema的一站式管理服務。

下面這張圖展示了Control Center的主題管理主界面。從這張圖中，我們可以直觀地觀測到整個Kafka集群的主題數量、ISR副本數量、各個主題對應的TPS等數據。當然，Control Center提供的功能遠不止這些，你能想到的所有Kafka運維管理和監控功能，Control Center幾乎都能提供。

圖片

不過，如果你要使用Control Center，就必須使用Confluent Kafka Platform企業版。換句話說，Control Center不是免費的，你需要付費才能使用。如果你需要一套很強大的監控框架，你可以登錄Confluent公司官網，去訂購這套真正意義上的企業級Kafka監控框架。

小結

其實，除了今天我介紹的Kafka Manager、Burrow、Grafana和Control Center之外，市面上還散落著很多開源的Kafka監控框架，比如Kafka Monitor、Kafka Offset Monitor等。不過，這些框架基本上已經停止更新了，有的框架甚至好幾年都沒有人維護了，因此我就不詳細展開了。如果你是一名開源愛好者，可以試著到開源社區中貢獻代碼，幫助它們重新煥發活力。

值得一提的是，國內最近有個Kafka Eagle框架非常不錯。它是國人維護的，而且目前還在積極地演進著。根據Kafka Eagle官網的描述，它支持最新的Kafka 2.x版本，除了提供常規的監控功能之外，還開放了告警功能（Alert），非常值得一試。

總之，每個框架都有自己的特點和價值。Kafka Manager框架適用于基本的Kafka監控，Grafana+InfluxDB+JMXTrans的組合適用于已經具有較成熟框架的企業。對于其他的幾個監控框架，你可以把它們作為這兩個方案的補充，加入到你的監控解決方案中。