滴滴開源Logi-KafkaManager 一站式Kafka監控與管控平臺

桔妹導讀： LogI-KafkaManager脫胎于滴滴內部多年的Kafka運營實踐經驗，是面向Kafka用戶、Kafka運維人員打造的共享多租戶Kafka云平臺，專注于Kafka運維管控、監控告警、資源治理等核心場景，經歷過大規模集群、海量大資料的考驗，內部滿意度高達90%的同時，還與多家知名企業達成商業化合作，

滴滴內部統一使用 kafka 作為大資料的資料通道，當前滴滴共有幾十個 kafka 集群，450+ 的節點，20k+ 的 kafka topic，每天2w億+的訊息量；每周500+UV用戶，需要完成 topic 創建、申請、指標查看等操作；每天運維人員還有大量集群、topic運維操作，因此我們需要構建一個Kafka的管控平臺來承載這些需求，

在平臺建設的初期，我們調研了社區同類產品的使用情況，在調研中發現，外部同類產品無論在監控指標的完善程度、運維管控的能力亦或是使用的體驗、還是整體的安全管控上都無法很好的滿足我們的需求，因此自建滴滴 kafka 云管控平臺勢在必行，

經過前期產品同學的反復調研和設計、中期研發同學高質量的實作、后期針對用戶體驗反饋的持續迭代，kafka 云平臺上線后廣受內部用戶和運維人員的好評，使用滿意度達到90分，與此同時，還進行了開源(https://github.com/didi/Logi-KafkaManager)和商業化輸出，并被多家企業用戶成功采購，

免費體驗地址：http://117.51.150.133:8080/kafka ，賬戶admin/admin，

1.

需求分析

在 Kafka 云平臺建設的初期，我們對之前所面臨的問題和需求進行了歸納分析，主要有以下幾點：

• 資料安全性

由于絕大多數用戶使用的kafka topic 都會由公共集群來承載資料的生產和消費，而當前 kafka 引擎在 topic 級別的安全管控手段較為薄弱，任何人只要知道kafka集群地址和相應的topic便可進行消費，這無疑會造成資料泄漏的安全風險，因此資料的安全性成首要被解決的問題，

• 服務的穩定性

滴滴內部絕大部分的 topic 是在共享集群上，共享集群下多 topic 之間存在著相互影響的問題，如某個 topic 的流量突增可能會大面積地影響其他 topic ，從而導致業務的抖動和集群的不穩定，因此在共享集群下，kafka 服務的穩定性也成為了一個必須被解決的問題，

• 用戶使用友好性

滴滴內部每周有大量的用戶需要進行 topic 的創建、消費、擴partiton、指標查看等操作，用戶高頻使用的功能需要做的足夠的友好和容易上手，這樣才能最大的簡化用戶的操作和減低日常開發和運維人員的答疑成本，因此用戶高頻操作的平臺化支撐，則成為接下來需要解決的問題，

• 問題定位高效性

在日常使用 kafka topic 的程序中，會有大量的問題需要查看和定位，如：訊息生產和消費的速度、訊息堆積的程度、partition的均勻度、topic的分布資訊、broker的負載資訊、副本的同步資訊等，如何使用戶和運維人員快速高效的定位問題、處理問題，是重點需要解決的問題，

• 運維管控便利性

在日常的運維中，會存在著大量的集群、topic的運維操作，如：集群的部署、升級、擴縮容、topic的遷移、leader rebalance等高頻高危的操作，怎么樣在提升運維操作效率的同時，還要保證高危操作不會影響集群穩定性，這個也是需要去重點考慮，

2.

整體設計

從以上的需求分析可以看出，滴滴 kafka 云平臺建設需要解決的問題比較多元，因此在設計之初就需要對整體有一個清晰的思路和規劃，為此我們定義了一個核心設計原則，并對業務進行了合理的分層用以指導我們后續的產品設計和代碼開發，

▍1. 核心設計原則

在平臺的整體設計上，我們制定了“一點三化”的設計原則：

• 一點：以安全和穩定為核心點，建設 kafka 的網關系統，針對 topic 的生產/消費提供安全校驗，同時提供多租戶的隔離方案解決共享集群下多 topic 相互影響的問題；

• 平臺化：著重建設 kafka 云平臺，反復進行需求調研和產品設計，提煉用戶和運維的高頻操作，將這些操作都通過平臺實作，降低用戶的使用成本；

• 可視化：提升topic/集群監控、運維程序中指標的可觀察性，所有指標盡量能在平臺上可以直觀體現，方便使用者及時感知集群運行狀態，快速定位問題；

• 專家化：將日常集群運維的經驗沉淀在平臺上，形成專家服務能力和智能化能力，進一步降低 kafka 集群的維護成本，提升整體穩定性，

▍2. 業務分層架構

在滴滴 kafka manager 具體的業務設計上，我們采取分層設計，從下至上分為以下幾層：

• 資源層：滴滴 kafka 引擎和 kafka manager 除了 zookpeer 之外只依賴 msyql，依賴精簡，部署方便；

• 引擎層：當前滴滴 kafka 引擎版本是2.5，我們在此基礎上開發了一些自己的特性，如磁盤過載保護，并且完全兼容開源社區的 kafka；

• 網關層：引擎層之上我們設計了網關層，網關層的設計非常巧妙，主要提供：安全管控、topic 限流、服務發現、降級能力，具體詳見后文“安全性”的內容；

• 服務層：基于kafka gateway 我們在 kafka manager 上提供了豐富的功能，主要有：topic 管理、監控管理、集群管理等；

• 平臺層：對外提供了一套 web 平臺，分別針對普通用戶和運維用戶，提供不同的功能頁面，盡可能的將一些日常使用中的高頻操作在平臺上進行承接，降低用戶的使用成本，

▍3. 應用邏輯架構

在實際的應用部署和關聯上，整體的 kafka manager 和 kafka 引擎、kafka gateway 之間的邏輯關系比較簡單，具體如下圖所示：

• kafka gateway 包括兩大塊功能：服務發現、元資料網關，詳細介紹見后面的元資料網關設計一節，

• kafka manager 提供我們開發的特色功能，如：topic管理、監控管理、集群管理，以及相應的 web 平臺，普通用戶和研發運維人員日常操作接觸最多，最高頻的操作都將這上面完成，

3.

安全性

以kafka 資料的安全性和集群使用程序中的穩定性保障是我們在構思和設計整個 kafka 云平臺時首要考慮的問題，為此我們設計了一套 kafka 元資料網關和多租戶的隔離模型來解決這些問題，

▍1. 元資料網關設計

用戶在接入原始的 kafka 集群時沒有安全管控，無法有效的管理用戶的使用行為，對資料安全和集群穩定性造成嚴重的風險，因此我們設計了一套 kafka 集群元資料網關系統來解決安全問題，

kafka gateway 系統除了解決資料的安全風隙訓附帶了以下作用：

• 提供 kafka 集群的服務發現服務節點，這樣用戶在使用 kafka 集群服務時，當 kafka cluster boostrap 地址變更時，則不需要用戶改動 kafka 的連接地址，不用重啟 kafka client，保障集群的變更對用戶透明；

• 提供 kafka topic 生產和消費的限流能力，避免用戶無限制的使用集群的流量，流量大的用戶會耗盡系統資源從而影響其他用戶的使用，造成集群的節點故障；

需要注明說明一點，kafka gateway 的設計很巧妙的將這些功能實作在 kafka 引擎內部，因為 kafka 作為一個訊息系統，其本身流量是非常的巨大，如果 kafka gateway 作為一個單獨應用存在，所有流量都先通過 gateway 再進入 kafka 引擎，則對 kafka gateway 機器資源的消耗是非常巨大的，基本等同于需要增加一倍的機器資源，并且整個流程的耗時也會增加，所以在設計之初，就把 kafka gateway 和 kafka 引擎合在一起，這便是滴滴 kafka 引擎的特色能力所在，

搭建好 kafka gateway 系統之后，用戶使用 kafka topic 的流程變為如下：

• 在 kafka manager 上申請租戶(appid)，獲取到對應的租戶密碼(app-password)；

• 利用 appid 申請創建新的 topic，或者申請已存在的 topic 的生產和消費權限；

• 使用 kafka client 時設定好對應的 appid 和 app-password，相應的 topic 鑒權，限流都在 kafka broker 端完成，

▍2. 多租戶隔離模型

在滴滴內部，絕大部分的 topic 是在共享集群上的，在沒有管控的情況下，topic 的各個磁區是隨機的分布在不同的 broker 上，隨著集群中 topic 數量的增加，topic 流量的變大，某個具體 topic 的抖動有可能會影響到其他的 topic，因此共享集群下的 topic 隔離就是非常必要的，為此我們結合 kafka gateway 在 kafka manager 上設計了一套多租戶隔離模型來解決這個問題，具體操作如下：

• 對將kafka 集群中的各個 broker 進行劃分，一組 broker 被分成一個 region，這個 region 在業務上被抽象為一個邏輯集群；

• 用戶在申請創建新的 topic 時需要選擇一個邏輯集群，這樣 topic 的磁區只能創建在一個邏輯集群上，也就是一組 broker 上；

• 具體 topic 訊息的生產和消費就只會和一組 broker 發生關系，如果某個 topic 的抖動也只會影響特定 broker 上的其他 topic，從而將影響限定在一定的范圍內，

4.

平臺化

滴滴 kafka manager 平臺建設之初就把易用性作為主要目標，因此在產品設計上非常注重用戶的使用體驗，前期通過反復的用戶調研和內部討論，最終提煉出普通用戶和運維用戶的高頻操作，將這些操作都通過平臺實作，降低用戶的使用成本，

• 方便的日常用戶使用

1. 用戶只關注自己的Topic的資訊(默認)，以減少不必要資訊的干擾；

2. 足夠的指標資訊，以保證用戶能自助解決問題的同時減少不必要資訊的干擾；

• 高效的運維操作

1. 提煉用戶、運維人員創建Topic、調整配額、擴展磁區、集群遷移、集群重啟等高頻運維操作，將高頻操作平臺化，簡化用戶操作，大大降低運維成本，

2. 提供整體集群直觀的全域視角，以提高排查問題的效率以及對集群規模的直觀感知，并提供詳盡的區域視角，以提高排查問題的效率；

• 友好的生態

  內部版本與滴滴監控系統打通，開源版本與滴滴開源的夜鶯監控告警系統打通，集成監控告警、集群部署、集群升級等能力，形成運維生態，凝練專家服務，使運維更高效，

• 體貼的細節

  kafka 云平臺的建設，它有著自己的設計理念，如：應用、權限、限流等；kafka 集群的 broker 和 topic 的上也存在著各種指標，操作任務，審批流程等，這些都會對用戶的使用造成困惑，雖然產品同學在反復的體驗和持續的優化迭代，但是為了進一步的方便用戶使用，我們在各種用戶可能感覺到困惑指標含義的地方，設定了大量的提示說明，讓用戶不用出頁面就可以基本解決問題，整個使用程序力爭如絲般順滑，

• 出眾的顏值

  常見的內部工具型產品往往都是以滿足功能和需求為主，很多都是功能在頁面上的堆砌，kafka 云平臺在建設之初，在產品設計和前端開發上也力求更高的標準，最終整體的風格相比以往提升巨大，一上線就被用戶稱贊為 “大廠出品” ，相比目前幾款主流開源的 kafka 管理平臺，在頁面美觀程度上大大超出其他同類產品，可以說是“我花開后百花殺”，

5.

可視化

運維人員在日常進行kafka 集群維護和穩定性保障程序中，對集群和 topic 的各項指標都非常關注，因此指標采集展示的準確性和及時性變得非常重要，為此我們將指標的可視化也作為 kafka manager 建設的核心目標，

• 黃金指標定義

針對 broker 和 topic 日常監控和診斷問題程序中最主要的指標進行篩選，這些指標被定義為黃金指標，如：topic 的 messageIn、byteIn等，并在平臺的相關頁面上進行高優高亮展示，便于用戶在日常使用程序中，快速診斷和定位集群可能存在的問題，同時我們還根據 broker 和 topic 的指標監控，制定了一套用于快速識別其運行狀態的健康分演算法，將多個指標進行加權計算，最終得到一個健康分數值，健康分的高低則直觀的展示了 broker 和 topic 實際運行程序中的狀態，便于用戶和運維快速從多個 broker 和 topic 中識別，

• 業務程序資料化

增加基于 topic 生產消費各環節的耗時統計，支持動態開啟與關閉，幫助用戶自助排查問題；關鍵指標業務運行程序化，不同分位數性能指標的監控，方便歷史問題回溯診斷，

• 服務端強管控

服務端記錄客戶端連接版本和型別，連接強感知，集群強管控，元資訊的基石；controller 強管控，指定的主機串列，記錄 controller 歷史運行節點；記錄 topic 的壓縮格式，應用與業務元資訊，業務強感知，

6.

專家化

基于之前全面的kafka資料采集，和運維同學在日常操作程序中的一些經驗總結，我們將高頻的問題和操作沉淀形成特有的專家服務，來智能診斷 kafka 集群和 topic 的健康狀態，并提供對應的處理方案，

kafka manager 的專家服務能提供了以下功能：

• 磁區熱點遷移

1. 背景：Kafka只具備Topic遷移的能力，但是不具備自動均衡的能力，Region內部分Broker壓力非常大，但是部分Broker壓力又很低，高低不均，如果不立即處理，輕則無法繼續承接用戶的需求，重則由于部分Broker壓力過大導致集群出現穩定性問題，

2. 解決方案：

1. 在滴滴 kafka 引擎上增加 topic 在不同磁盤上分布的指標；

2. kafka manager 通過定時采集的 topic 指標來分析 topic在不同磁盤上的分布均勻度；

3. 針對不均勻的 topic 發起遷移操作，并在遷移時進行流量控制，保證遷移不會影響集群的穩定性，

• 磁區不足擴容

1. 背景：kafka 集群的 topic 相關的元資訊存盤在 zookpeer 上，最終由 controller 將其同步到各個broker，如果元資訊過大，controller 同步的壓力就會隨之上升成為整個集群的瓶頸點，如果遇到某臺 broker 出現問題，整個集群的資料同步就非常慢，從而影響穩定性，

2. 解決方案：

1. 在用戶申請創建 topic 的時候，平臺進行磁區數的管控，磁區數不能設定的特別大，然而隨著 topic 流量的上升，topic 磁區可能不足，如果遇到 topic 流量突增，超過了單磁區能承載的能力，會導致磁區所在的Broker出現壓力，如cpu和load升高等問題，客戶端也會出現發送堆積的情況，

2. 基于現有的機型以及客戶端的消費發送能力的壓測，我們定義了單磁區的承載流量，同時我們實時對每個 topic 的流量進行監控，當某個 topic 的峰值流量持續的達到和超過閾值之后，會對該 topic 進行標記或者告警，定義為磁區不足的 topic，

3. 針對監控發現出來的磁區不足的 topic，由運維人員手動進行擴磁區，或者 kafka manager 根據當前集群整個容量情況自動進行擴磁區，

• topic資源治理

1. 背景：公共集群中用戶申請創建的 topic，它們的使用情況是各不相同的，還存在著部分 topic 根本不使用還占據集群元資料的情況，這對本來就十分擁擠的公共集群造成很大的資源浪費和穩定性風險，因此針對集群中的不使用的 topic進行治理就非常必要，

2. 解決方案:

1. 實時對集群中所有 topic 的流量進行采集監控，智能的分析 topic 的流量趨勢，如果發現 topic 的流量持續在一段時間內為0，則進行標記或者告警，

2. 針對監控發現的一定周期無流量、無生產消費鏈接的topic，進行通知和下線清理操作，

7.

同類對比

我們來和外部類似的產品進行一個簡要的功能對比如下：

經過簡單的對比，我們可以看到，經過平臺化、可視化、智能化、安全建設之后，滴滴kafka manager在安全性、用戶體驗、監控、運維管控上都有著顯著的優勢，也提供了很多特色的功能，極大的方便了用戶和運維人員的日常使用，歡迎大家Star和體驗https://www.didiyun.com/production/logi-KafkaManager.html

8.

展望

Logi-Kafka-Manager 已在滴滴內部上線使用，未來我們除了在平臺化、可視化、智能化基礎上持續改進，還會在以下幾個方面持續努力：

• 平滑的跨集群遷移

我們將基于 MirrorMaker + KafkaGateWay 打造一套 kafka Topic 跨集群平滑遷移能力，在 kafka manager 平臺上為 kafka topic 運維管控提供更為高效的遷移能力，進一步提升運維效率，

• 更多的指標監控

進一步的支持 kafka 2.5+ 最新版本的管控，并且新增更多的關鍵指標的監控，從而讓 kafka manager 指標展示和問題定位的能力更強大，

• 持續回饋開源社區

作為在滴滴內部經過大量復雜場景驗證過的 kafka 管控平臺，我們會持續對其進行核心業務抽象，剝離滴滴內部依賴，回饋社區，我們也希望熱心的社區同學和我們交流想法，共同提升滴滴 Logi-KafkaManager 的功能和體驗

開源團隊

?

延伸閱讀

?

內容編輯 | Mango聯系我們 | DiDiTech@didiglobal.com