Kafka Manager 簡介
- Kafka Manager 可能是現在能找到的最好的可視化的Kafka管理工具, 感謝Yahoo-我人生中打開的一個網站-的開源;
- 使用Kafka Manager, 基本上之前需要運行Kafka相應命令行工具的工作現在都可以可視化的完成:
- 創建Topic, 調整消息保存時長, Partition數量等等配置;
- 管理Topic, 包括Reassign Partitions, Preferred Replica Election等等;
- 消費情況查看, 支持offset保存到zk和broker兩種方式, 列出所有消費的group, 消費每個partition的詳情;
- 集群的簡單健康狀態查看,包括partition分布是否均衡, leader分布是否均衡等;
- 通過JMX查看各種指標, 比如各個broker的網絡流量和消息進出數據, 每個Topic消息的讀寫速度等;
- 下面我們會先簡單介紹下Kafka Manager的實現和在使用中遇到的幾種坑;
Kafka Manager實現
- 實現語言: Scala
- 用到的框架和第三方庫:
- Play framework: Kafka-Mananger本質上是個Web應用, 因此使用play framework的MVC架構實現;
- AKKA: 用于構建高并發、分布式和容錯的應用. Kafka Manager中的所有請求都使用akka來異步處理;
- Apache Curator Framework: 用于訪問zookeeper;
- Kafka Sdk: 用于獲取各Topic的last offset, 使用Admin接口實現各種管理功能;
- 編譯:
整個工程使用 sbt 構建, 具體編譯流程可以在githut上找到. sbt在build過程中會加載很多第三方依賴, 這個在國內有時會很慢, 各種同學各顯神通吧. - 實現:
其實kafka manager的代碼還是很清晰易閱讀的, 如果熟悉scala和play的話應該沒有難度. 不同本人也是現學現用, 好慚愧~~~. 咱們這里撿重點的說吧, 不分析具體代碼實現,只講下實現的方法:
-
獲取集群中所有Topic
使用Curator訪問zk獲取,并監聽zk相關節點 /brokers/topics 的變化; -
獲取Topic的partiton, leader, replicas信息
也是從zk獲取, /brokers/topics/[topic]/partitions; -
獲取Topic的各partition的last offset
使用kafka sdk發送OffsetRequest到kafka集群來獲得, 這個獲取的動作會被封裝成Future[PartitionOffsetsCapture], 每個topic一個Future, 使用Google的LoadingCache來存儲這些future, 利用LoadingCache的超時淘汰機制來周期性的創建新的Future來間隔地發送OffsetRequest獲取當前最新的last offset; -
獲取Kafka本身管理的group的消費情況
使用kafka sdk不斷地消費"__consumer_offsets"這個topic, 來獲取所有group的消費情況,關于__consumer_offsets參考 Committing and fetching consumer offsets in Kafka -
獲取zookeeper管理的group的消費情況
肯定是從zk上讀取, /consumers
上面的這些實現都在 KafkaStateActor.scala 這個文件里.
- 各種Acotr的關系簡圖,僅供參考
Kafka Manager遇到的坑
- 多個kafka manager來管理同一個kafka集群:
你會發現在kafka manager里無法看到所有offset使用kafka本身管理的group.
前面我們講過使用kafka sdk不斷地消費"__consumer_offsets", 看看這段代碼(在KafkaStateActor.scala中):
props.put("group.id", "KafkaManagerOffsetCache")
props.put("bootstrap.servers", bootstrapBrokerList.list.map(bi => s"${bi.host}:${bi.port}").mkString(","))
props.put("exclude.internal.topics", "false")
props.put("enable.auto.commit", "false")
props.put("key.deserializer", "org.apache.kafka.common.serialization.ByteArrayDeserializer")
props.put("value.deserializer", "org.apache.kafka.common.serialization.ByteArrayDeserializer")
props.put("auto.offset.reset", "latest")
props.put("group.id", "KafkaManagerOffsetCache")這句說明不管啟動了幾個kafka manager, 消費"__consumer_offsets"都使用同一個group.
解決方案: group.id從配置文件中讀取,每個kafka manager使用不同的group id;
- 客戶端使用某些sdk(比如librdkafka)消費topic, 客戶端crash后, 在kafka manager上查看其group的消費情況, 仍然一直能看到"Consumer Instance Owner"
原因在于處理從broker返回的GroupMetadata response時沒有處理異常情況:
case GroupMetadataKey(version, key) =>
val value: GroupMetadata = readGroupMessageValue(key, ByteBuffer.wrap(record.value()))
value.allMemberMetadata.foreach {
mm =>
mm.assignment.foreach {
case (topic, part) =>
groupTopicPartitionMemberMap += (key, topic, part) -> mm
}
}
}
這里的record.value可能為空, 此時應作清理工作:
if (null != record &&
null != record.value()) {
val value: GroupMetadata = readGroupMessageValue(key, ByteBuffer.wrap(record.value()))
value.allMemberMetadata.foreach {
mm =>
mm.assignment.foreach {
case (topic, part) =>
groupTopicPartitionMemberMap += (key, topic, part) -> mm
}
}
} else {
groupTopicPartitionMemberMap.foreach {
case ((group, topic, part), mmd) =>
if (group == key) {
var tmp = mmd
tmp.memberId = ""
tmp.clientHost = ""
groupTopicPartitionMemberMap += (key, topic, part) -> tmp
}
}
}
- Yikes! Ask timed out on [ActorSelection[Anchor(akka://kafka-manager-system/), Path(/user/kafka-manager)]] after [5000 ms]
訪問kafka manager時出現上面的超時提示, 遇到這個問題,好學不服輸的你肯定會上網各種搜, 然后你會去改kafka manager的各種配置, 調大各種thread pool的容量, 增大queue size, 甚至開大jvm的使用內存, 然而問題并沒有解決, 看來只剩下定時重啟這一招兒了.
這里提供一種解決方案: 這個超時是Actor在執行異步請求時一直等不到返回結果造成的, 主要是前面講過的"獲取Topic的各partition的last offset的Future"沒有返回結果,這些Future是通過Await.ready來阻塞拿到result的, 然而在kafka manager中這個Await.ready沒有給timeout, 是一直等待, 那咱們就給個timeout好了, 代碼在ActorModel.scala中, 有好幾處Await.ready的調用.
找到根源: 再也不用定時重啟, 提了一個pull request到官方:Use a separate thread to get the topic offsets to fixed bug 'Yikes! Ask timed out...', 主要就是不再使用 Future[PartitionOffsetCapture]來獲取topic offset, 因為這個會產生大量的Future, 進而會產生大量的task提交到ThreadExcutor, 其實只需要啟動一個單獨的線程來作這件事就好了.
Consumer offset的詳情不完整
通過上面的源碼分析我們知道km是通過消費"__consumer_offsets"來獲取某一個組的消費情況的,消費這個topic,和消費用戶自己的topic沒什么兩樣, km里使用"props.put("auto.offset.reset", "latest")"默認offset無效時從最新位置來拉取, 如果一個group用戶已經有段時間沒有提交offset(但還沒有完全過期), 則此時在km上看不到相應的gorup信息, 可以簡單改為"props.put("auto.offset.reset", "earliest")"同名group消費不同topic后,其中一個group的消費進程結束后, 仍可以看到其消費詳情
這個問題是最近被發現,之前應該是一直存在著,沒能引起重視.
這里提供一種簡單的,hack的解決方案:
case GroupMetadataKey(version, key) =>
if (null != record &&
null != record.value()) {
val value: GroupMetadata = readGroupMessageValue(key, ByteBuffer.wrap(record.value()))
var topicSet:Set[String] = Set()
value.allMemberMetadata.foreach {
mm =>
mm.assignment.foreach {
case (topic, part) =>
topicSet += topic
groupTopicPartitionMemberMap += (key, topic, part) -> mm
}
}
groupTopicPartitionMemberMap.foreach {
case ((group, topic, part), mmd) =>
if (group == key &&
!topicSet.contains(topic)) {
var tmp = mmd
tmp.memberId = ""
tmp.clientHost = ""
groupTopicPartitionMemberMap += (key, topic, part) -> tmp
}
}
} else {
groupTopicPartitionMemberMap.foreach {
case ((group, topic, part), mmd) =>
if (group == key) {
var tmp = mmd
tmp.memberId = ""
tmp.clientHost = ""
groupTopicPartitionMemberMap += (key, topic, part) -> tmp
}
}
}
}
