Kafka監控與指標解析-UnderReplicatedPartitions

• 1 Kafka監控

• 2 指標採集和統計機制

• 3 常見指標分析

1 Kafka監控

Kafka 使用 Yammer Metrics 在伺服器中報告指標,Java 客戶端使用 Kafka Metrics，這是一個內建的指標註冊表. 兩者都通過 JMX 公開指標

啟用JMX並上報指標

Kafka 預設禁用遠端 JMX，Kafka啟動JMX方式

方式一：

JMX_PORT=埠號 nohup bin/kafka-server-start.sh config/server.properties &

在這裡插入圖片描述

方式二：

在啟動腳本里面 對JMX_PORT 賦值，在 kafka-server-start.sh 增加一句

export JMX_PORT="埠號"

然後再啟動指令碼,JMX就會自動開啟了

方式三：在IDEA中啟用JMX

如果你是在IDEA啟動Kafka原始碼的形式開啟JMX 那麼你可以在啟動的時候加入以下引數

-Djava.rmi.server.hostname=127.0.0.1
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=埠
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

方式四：安全啟用JMX

在生產場景中啟用遠端 JMX 時，您必須啟用安全性，以確保未經授權的使用者無法監視或控制您的代理或應用程式以及執行它們的平臺.

更詳細的請看：使用 JMX 技術進行監控和管理

檢視JMX指標的方式

啟動JMX之後, 我們在Zookeeper中的節點 /brokers/ids/{brokerID} 資料中可以看到我們的埠是否註冊成功。

{
 "features": {},
 "listener_security_protocol_map": {
  "PLAINTEXT": "PLAINTEXT"
 },
 "endpoints": ["PLAINTEXT://localhost:9092"],
 "jmx_port": 9999,
 "port": 9092,
 "host": "localhost",
 "version": 5,
 "timestamp": "1659670870502"
}

其中資料 jmx_port": 9999 就可以指定我們的JMX已經開啟並且埠號是 9999

使用jconsole連線資訊並開啟

在按照JDK的時候，jconsole已經安裝好了, 我們可以直接使用這個工具來視覺化介面監控Java程式執行狀況。

shizhenzhen@localhost  % jconsole

這裡可以連線本地的也可以是遠端的，連結之後, 選擇MBean就可以看到指標了

2 指標採集和統計機制

多圖詳解Kafka中的資料採集和統計機制

3 常見指標分析

指標的屬性

Kafka中的指標有幾百個,我們這邊不可能把每一個指標都給分析一遍,這裡我們從裡面挑出來幾個監控指標來分析分析

想要檢視所有指標請跳轉官網：Kafka監控

我們用 jconsole 連線上Broker之後, 可以看到所有的指標,如下圖

如圖所示有很多的指標,並且每個指標有很多的屬性值

比如指標

kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec 表示的是這臺Broker每秒寫入的訊息條數。

但是這個資料是如何統計的呢, 可以看看 圖解Kafka中的資料採集和統計機制

一般情況下我們獲取這個資料的話 是拿的 OneMinuteRate 一分鐘內流入的平均速度。

kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec.OneMinuteRate

當然還有 FiveMinuteRate 、 FifteenMinuteRate

每個指標下面都會有很多屬性，一般可能有以下幾個

屬性名	描述
RateUnit	時間單位, 值固定為SECONDS 秒，它和EventType組成這個指標的單位,即messages/s
EventType	事件型別,對於MessagesIn來說，它的值是messages, 表示訊息的個數,對於其他一些型別的指標來說可能會有所不同
Count	訊息流入的總數
MeanRate	平均速率，自統計開始時候的平均
OneMinuteRate	一分鐘內流入的平均速率
FiveMinuteRate	五分鐘內流入的平均速率
FifteenMinuteRate	十五分鐘內流入的平均速率

那如果我還想知道在這臺Broker上某個Topic的指標呢？

剛剛上面說的指標是流入這臺Broker的訊息數速率, 但是它的子目錄下還有各個Topic的統計資料 指標名： kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec,topic=P1_R1

常見重要指標

1. UnderReplicatedPartitions 失效副本分割槽數

指標: kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

含義:失效副本的分割槽數量, 程式碼邏輯為 統計 該Broker上的Leader分割槽，並且該分割槽的副本數 - isr數量  > 0 的數量

異常值:非0值

這個UnderReplicatedPartitions表示的是什麼意思呢？我們直接看程式碼它是怎麼統計的

ReplicaManager

通過程式碼所示, UnderReplicatedPartitions 是 Gauge 型別,也就是說表示 瞬時資料, 會不停的把這個資料上報給JmxReport 那麼主要的數值計算邏輯是：

leaderPartitionsIterator.count(_.isUnderReplicated)

def isUnderReplicated: Boolean = isLeader && (assignmentState.replicationFactor - isrState.isr.size) > 0
  

程式碼邏輯：統計 該Broker上的Leader分割槽，並且該分割槽的副本數 - isr數量  > 0 的數量

簡單來說：UnderReplicatedPartitions值表示該Broker上的Leader分割槽存在有沒有完全同步並跟上ISR的副本的 分割槽數量

問題分析

如果你這個指標出現了 , 說明該Broker上的Leader分割槽存在Follower副本跟不上ISR的情況。

這麼個情況就是 副本為何掉出ISR 的問題了

PS：當我們在進行分割槽副本重分配的時候可能會出現這種情況,因為有可能新增了副本並且還沒有跟上ISR.

1. 可能存在某個Broker宕機

看 KnowStreaming 的展示, Broker2存在5個 UnderReplicatedPartitions , 通過左邊可以看到剛好是Broker-0宕機了。

這種很容易就找到問題所在, 然後啟動Broker恢復副本同步。

2. 可能副本所在磁碟故障/寫滿,導致副本離線

當磁碟出現故障時，會導致磁碟IO能力下降、叢集吞吐下降、訊息讀寫延時或日誌目錄offline等問題。

當磁碟寫滿時，相應磁碟上的Kafka日誌目錄會出現offline問題，此時，該磁碟上的分割槽副本不可讀寫，降低了分割槽的可用性與容錯能力，同時由於leader遷移到其他Broker，增加了其他Broker的負載

我們可以通過指標 OfflineLogDirectoryCount 來及時發現日誌Offline的情況。

指標: kafka.log:type=LogManager,name=OfflineLogDirectoryCount

含義:離線日誌目錄數量

異常值:非0值

如果我們這個值是>0 的話，表示已經有目錄處於離線中了, 具體是哪個處於離線中我們也可以通過指標來確定

指標: kafka.log:type=LogManager,name=LogDirectoryOffline,logDirectory="絕對路徑地址"

含義:該目錄是否離線

異常值:非0值,   0表示正常, 1表示離線

當然如果你想監控到具體的離線目錄的話，你可以先把Broker上的所有目錄絕對路徑查詢出來,然後再遍歷一下這個指標就行了。

如果確定是目錄離線了, 那麼接下來就是讓副本上線就行了, 如果磁碟滿了可以考慮刪除舊資料或更換磁碟，如果磁碟壞了那就換磁碟吧。

3. 效能問題,導致副本來不及同步資料

首先我們先了解一下Kafka的 ISR的伸縮機制

一般會有兩種情況導致副本失效

1. Follower副本程序卡住,在一段時間內根本沒有向Leader發起同步請求，比如頻繁的Full GC.

2. Follower副本程序同步過慢, 在一段時間內都無法追趕上Leader副本,比如I/O開銷過大。

出現1的情況可能性不是那麼大,你可以通過檢視kafka的gc日誌 kafkaServer-gc.log 來確定是否存在頻繁的Full GC

其他情況呢, 我們可以先檢查一下是否有一些異常日誌出現， 看看具體的異常是什麼

Error sending fetch request {} to node {}

Failed to connect within $socketTimeout ms"

因為ISR伸縮的時候,在更新HW的時候需要加一個 leaderIsrUpdateLock 寫鎖, 這個時候訊息的傳送、客戶端的讀取等等都會發生鎖競爭，併發度會下降。

解決問題的方案

我們可以嘗試的調大 replica.lag.time.max.ms ，2.5之前預設值是10s, 後面是30s.

也可以調大 num.replica.fetchers 的值,這個值表示的是：Broker去讀取訊息的Fetcher執行緒數,增加這個值可以增加follow broker中的I/O並行度。預設是1

更多指標

持續更新，敬請期待!!!