阿里大佬是怎麼監控Kafka？此次算是長見識了

本文已收錄GitHub，更有互聯網大廠面試真題，面試攻略，高效學習資料等

監控 Kafka，從來都是個老大難的問題。不管是在我維護的微信公衆號，仍是 Kafka QQ羣裏面，你們問得最多的問題，必定是 Kafka 的監控。你們提問的內容看似五花八門，但真正想了解的，其實都是監控這點事，也就是我應該監控什麼，怎麼監控。

我我的認爲，和頭疼醫頭、腳疼醫腳的問題相似，在監控 Kafka 時，若是咱們只監控Broker 的話，就不免以偏概全。單個 Broker 啓動的進程雖然屬於 Kafka 應用，但它也是一個普通的 Java 進程，更是一個操做系統進程。所以，我以爲有必要從 Kafka 主機、JVM和 Kafka 集羣自己這三個維度進行監控。

主機監控

主機級別的監控，每每是揭示線上問題的第一步。所謂主機監控，指的是監控 Kafka 集羣Broker 所在的節點機器的性能。一般來講，一臺主機上運行着各類各樣的應用進程，這些進程共同使用主機上的全部硬件資源，好比 CPU、內存或磁盤等。

常見的主機監控指標包括但不限於如下幾種：

• 機器負載（Load）
• CPU 使用率
• 內存使用率，包括空閒內存（Free Memory）和已使用內存（Used Memory）
• 磁盤 I/O 使用率，包括讀使用率和寫使用率
• 網絡 I/O 使用率
• TCP 鏈接數
• 打開文件數
• inode 使用狀況

考慮到咱們並非要系統地學習調優與監控主機性能，所以我並不打算對上面的每個指標都進行詳細解釋，我重點分享一下機器負載和 CPU 使用率的監控方法。我會以 Linux 平臺爲例來進行說明，其餘平臺應該也是相似的。

首先，咱們來看一張圖片。我在 Kafka 集羣的某臺 Broker 所在的主機上運行 top 命令，輸出的內容以下圖所示：

在圖片的右上角，咱們能夠看到 load average 的 3 個值：4.85，2.76 和 1.26，它們分別表明過去 1 分鐘、過去 5 分鐘和過去 15 分鐘的 Load 平均值。在這個例子中，個人主機總共有 4 個 CPU 核，但 Load 值卻達到了 4.85，這就說明，必定有進程暫時「搶不到」任何 CPU 資源。同時，Load 值一直在增長，也說明這臺主機上的負載愈來愈大。

舉這個例子，其實我真正想說的是 CPU 使用率。不少人把 top 命令中「%CPU」列的輸出值看成 CPU 使用率。好比，在上面這張圖中，PID 爲 2637 的 Java 進程是 Broker 進程，它對應的「%CPU」的值是 102.3。你不要認爲這是 CPU 的真實使用率，這列值的真實含義是進程使用的全部 CPU 的平均使用率，只是 top 命令在顯示的時候轉換成了單個CPU。所以，若是是在多核的主機上，這個值就可能會超過 100。在這個例子中，個人主機有 4 個 CPU 核，總 CPU 使用率是 102.3，那麼，平均每一個 CPU 的使用率大體是25%。

JVM監控

除了主機監控以外，另外一個重要的監控維度就是 JVM 監控。Kafka Broker 進程是一個普通的 Java 進程，全部關於 JVM 的監控手段在這裏都是適用的。

監控 JVM 進程主要是爲了讓你全面地瞭解你的應用程序（Know Your Application）。具體到 Kafka 而言，就是全面瞭解 Broker 進程。好比，Broker 進程的堆大小（HeapSize）是多少、各自的新生代和老年代是多大？用的是什麼 GC 回收器？這些監控指標和配置參數林林總總，一般你都沒必要所有重點關注，但你至少要搞清楚 Broker 端 JVM 進程的Minor GC 和 Full GC 的發生頻率和時長、活躍對象的總大小和 JVM 上應用線程的大體總數，由於這些數據都是你往後調優 Kafka Broker 的重要依據。

我舉個簡單的例子。假設一臺主機上運行的 Broker 進程在經歷了一次 Full GC 以後，堆上存活的活躍對象大小是 700MB，那麼在實際場景中，你幾乎能夠安全地將老年代堆大小設置成該數值的 1.5 倍或 2 倍，即大約 1.4GB。不要小看 700MB 這個數字，它是咱們設定Broker 堆大小的重要依據！

不少人會有這樣的疑問：我應該怎麼設置 Broker 端的堆大小呢？其實，這就是最合理的評估方法。試想一下，若是你的 Broker 在 Full GC 以後存活了 700MB 的數據，而你設置了堆大小爲 16GB，這樣合理嗎？對一個 16GB 大的堆執行一次 GC 要花多長時間啊？！所以，咱們來總結一下。要作到 JVM 進程監控，有 3 個指標須要你時刻關注：

1. Full GC 發生頻率和時長。這個指標幫助你評估 Full GC 對 Broker 進程的影響。長時間的停頓會令 Broker 端拋出各類超時異常。
2. 活躍對象大小。這個指標是你設定堆大小的重要依據，同時它還能幫助你細粒度地調優JVM 各個代的堆大小。
3. 應用線程總數。這個指標幫助你瞭解 Broker 進程對 CPU 的使用狀況。

總之，你對 Broker 進程瞭解得越透徹，你所作的 JVM 調優就越有效果。

談到具體的監控，前兩個均可以經過 GC 日誌來查看。好比，下面的這段 GC 日誌就說明了 GC 後堆上的存活對象大小。

2020-07-06T09:13:03.809+0800: 552.982: [GC cleanup 827M->645M(1024M), 0.0019078 secs]

這個 Broker JVM 進程默認使用了 G1 的 GC 算法，當 cleanup 步驟結束後，堆上活躍對象大小從 827MB 縮減成 645MB。另外，你能夠根據前面的時間戳來計算每次 GC 的間隔和頻率。

自 0.9.0.0 版本起，社區將默認的 GC 收集器設置爲 G1，而 G1 中的 Full GC 是由單線程執行的，速度很是慢。所以，你必定要監控你的 Broker GC 日誌，即以 kafkaServer-gc.log 開頭的文件。注意不要出現 Full GC 的字樣。一旦你發現 Broker 進程頻繁 FullGC，能夠開啓 G1 的 -XX:+PrintAdaptiveSizePolicy 開關，讓 JVM 告訴你究竟是誰引起了 Full GC。

集羣監控

說完了主機和 JVM 監控，如今我來給出監控 Kafka 集羣的幾個方法。

1. 查看 Broker 進程是否啓動，端口是否創建。

千萬不要小看這一點。在不少容器化的 Kafka 環境中，好比使用 Docker 啓動 KafkaBroker 時，容器雖然成功啓動了，可是裏面的網絡設置若是配置有誤，就可能會出現進程已經啓動但端口未成功創建監聽的情形。所以，你必定要同時檢查這兩點，確保服務正常運行。

2. 查看 Broker 端關鍵日誌。

這裏的關鍵日誌，主要涉及 Broker 端服務器日誌 server.log，控制器日誌 controller.log以及主題分區狀態變動日誌 state-change.log。其中，server.log 是最重要的，你最好時刻對它保持關注。不少 Broker 端的嚴重錯誤都會在這個文件中被展現出來。所以，若是你的 Kafka 集羣出現了故障，你要第一時間去查看對應的 server.log，尋找和定位故障緣由。

3. 查看 Broker 端關鍵線程的運行狀態。

這些關鍵線程的意外掛掉，每每無聲無息，可是卻影響巨大。比方說，Broker 後臺有個專屬的線程執行 Log Compaction 操做，因爲源代碼的 Bug，這個線程有時會平白無故地「死掉」，社區中不少 Jira 都曾報出過這個問題。當這個線程掛掉以後，做爲用戶的你不會獲得任何通知，Kafka 集羣依然會正常運轉，只是全部的 Compaction 操做都不能繼續了，這會致使 Kafka 內部的位移主題所佔用的磁盤空間愈來愈大。所以，咱們有必要對這些關鍵線程的狀態進行監控。

但是，一個 Kafka Broker 進程會啓動十幾個甚至是幾十個線程，咱們不可能對每一個線程都作到實時監控。因此，我跟你分享一下我認爲最重要的兩類線程。在實際生產環境中，監控這兩類線程的運行狀況是很是有必要的。

Log Compaction 線程，這類線程是以 kafka-log-cleaner-thread 開頭的。就像前面提到的，此線程是作日誌 Compaction 的。一旦它掛掉了，全部 Compaction 操做都會中斷，但用戶對此一般是無感知的。

副本拉取消息的線程，一般以 ReplicaFetcherThread 開頭。這類線程執行 Follower 副本向 Leader 副本拉取消息的邏輯。若是它們掛掉了，系統會表現爲對應的 Follower 副本再也不從 Leader 副本拉取消息，於是 Follower 副本的 Lag 會愈來愈大。

不論你是使用 jstack 命令，仍是其餘的監控框架，我建議你時刻關注 Broker 進程中這兩類線程的運行狀態。一旦發現它們狀態有變，就當即查看對應的 Kafka 日誌，定位緣由，由於這一般都預示會發生較爲嚴重的錯誤。

4. 查看 Broker 端的關鍵 JMX 指標。

Kafka 提供了超多的 JMX 指標供用戶實時監測，我來介紹幾個比較重要的 Broker 端 JMX指標：

• BytesIn/BytesOut：即 Broker 端每秒入站和出站字節數。你要確保這組值不要接近你的網絡帶寬，不然這一般都表示網卡已被「打滿」，很容易出現網絡丟包的情形。
• NetworkProcessorAvgIdlePercent：即網絡線程池線程平均的空閒比例。一般來講，你應該確保這個 JMX 值長期大於 30%。若是小於這個值，就代表你的網絡線程池很是繁忙，你須要經過增長網絡線程數或將負載轉移給其餘服務器的方式，來給該 Broker 減負。
• RequestHandlerAvgIdlePercent：即 I/O 線程池線程平均的空閒比例。一樣地，若是該值長期小於 30%，你須要調整 I/O 線程池的數量，或者減小 Broker 端的負載。
• UnderReplicatedPartitions：即未充分備份的分區數。所謂未充分備份，是指並不是全部的 Follower 副本都和 Leader 副本保持同步。一旦出現了這種狀況，一般都代表該分區有可能會出現數據丟失。所以，這是一個很是重要的 JMX 指標。
• ISRShrink/ISRExpand：即 ISR 收縮和擴容的頻次指標。若是你的環境中出現 ISR 中副本頻繁進出的情形，那麼這組值必定是很高的。這時，你要診斷下副本頻繁進出 ISR 的緣由，並採起適當的措施。
• ActiveControllerCount：即當前處於激活狀態的控制器的數量。正常狀況下，Controller 所在 Broker 上的這個 JMX 指標值應該是 1，其餘 Broker 上的這個值是 0。若是你發現存在多臺 Broker 上該值都是 1 的狀況，必定要趕快處理，處理方式主要是查看網絡連通性。這種狀況一般代表集羣出現了腦裂。腦裂問題是很是嚴重的分佈式故障，Kafka 目前依託 ZooKeeper 來防止腦裂。但一旦出現腦裂，Kafka 是沒法保證正常工做的。

其實，Broker 端還有不少不少 JMX 指標，除了上面這些重要指標，你還能夠根據本身業務的須要，去官網查看其餘 JMX 指標，把它們集成進你的監控框架。

5. 監控 Kafka 客戶端。

客戶端程序的性能一樣須要咱們密切關注。無論是生產者仍是消費者，咱們首先要關心的是客戶端所在的機器與 Kafka Broker 機器之間的網絡往返時延（Round-Trip Time，RTT）。通俗點說，就是你要在客戶端機器上 ping 一下 Broker 主機 IP，看看 RTT 是多少。

我曾經服務過一個客戶，他的 Kafka 生產者 TPS 特別低。我登到機器上一看，發現 RTT 是1 秒。在這種狀況下，不管你怎麼調優 Kafka 參數，效果都不會太明顯，下降網絡時延反而是最直接有效的辦法。

除了 RTT，客戶端程序也有很是關鍵的線程須要你時刻關注。對於生產者而言，有一個以kafka-producer-network-thread 開頭的線程是你要實時監控的。它是負責實際消息發送的線程。一旦它掛掉了，Producer 將沒法正常工做，但你的 Producer 進程不會自動掛掉，所以你有可能感知不到。對於消費者而言，心跳線程事關 Rebalance，也是必需要監控的一個線程。它的名字以 kafka-coordinator-heartbeat-thread 開頭。

除此以外，客戶端有一些很重要的 JMX 指標，能夠實時告訴你它們的運行狀況。

從 Producer 角度，你須要關注的 JMX 指標是 request-latency，即消息生產請求的延時。這個 JMX 最直接地表徵了 Producer 程序的 TPS；而從 Consumer 角度來講，records-lag 和 records-lead 是兩個重要的 JMX 指標。總之，它們直接反映了 Consumer 的消費進度。若是你使用了 Consumer Group，那麼有兩個額外的 JMX 指標須要你關注下，一個是 joinrate，另外一個是 sync rate。它們說明了 Rebalance 的頻繁程度。若是在你的環境中，它們的值很高，那麼你就須要思考下 Rebalance 頻繁發生的緣由了。

總結

好了，咱們來小結一下。本文介紹了監控 Kafka 的方方面面。除了監控 Kafka 集羣，還推薦你從主機和 JVM 的維度進行監控。對主機的監控，每每是咱們定位和發現問題的第一步。JVM 監控一樣重要。要知道，不少 Java 進程碰到的性能問題是沒法經過調整Kafka 參數是解決的。最後，羅列了一些比較重要的 Kafka JMX 指標。