滴滴開源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 平臺建設之初就把易用性做爲主要目標，所以在產品設計上很是注重用戶的使用體驗，前期經過反覆的用戶調研和內部討論，最終提煉出普通用戶和運維用戶的高頻操做，將這些操做都經過平臺實現，下降用戶的使用成本。

• 方便的平常用戶使用

用戶只關注本身的Topic的信息(默認)，以減小沒必要要信息的干擾；

足夠的指標信息，以保證用戶能自助解決問題的同時減小沒必要要信息的干擾；

• 高效的運維操做

提煉用戶、運維人員建立Topic、調整配額、擴展分區、集羣遷移、集羣重啓等高頻運維操做，將高頻操做平臺化，簡化用戶操做，大大下降運維成本。

提供總體集羣直觀的全局視角，以提升排查問題的效率以及對集羣規模的直觀感知，並提供詳盡的局部視角，以提升排查問題的效率；

• 友好的生態

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

• 體貼的細節

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 的專家服務能提供瞭如下功能：

• 分區熱點遷移

a.背景：Kafka只具有Topic遷移的能力，可是不具有自動均衡的能力，Region內部分Broker壓力很是大，可是部分Broker壓力又很低，高低不均。若是不當即處理，輕則沒法繼續承接用戶的需求，重則因爲部分Broker壓力過大致使集羣出現穩定性問題。

b.解決方案：

i. 在滴滴 kafka 引擎上增長 topic 在不一樣磁盤上分佈的指標；

ii. kafka manager 經過定時採集的 topic 指標來分析 topic在不一樣磁盤上的分佈均勻度；

iii. 針對不均勻的 topic 發起遷移操做，並在遷移時進行流量控制，保證遷移不會影響集羣的穩定性。

• 分區不足擴容

a.背景：kafka 集羣的 topic 相關的元信息存儲在 zookpeer 上，最終由 controller 將其同步到各個broker。若是元信息過大，controller 同步的壓力就會隨之上升成爲整個集羣的瓶頸點，若是遇到某臺 broker 出現問題，整個集羣的數據同步就很是慢，從而影響穩定性。

b.解決方案：

i. 在用戶申請建立 topic 的時候，平臺進行分區數的管控，分區數不能設置的特別大，然而隨着 topic 流量的上升，topic 分區可能不足。若是遇到 topic 流量突增，超過了單分區能承載的能力，會致使分區所在的Broker出現壓力，如cpu和load升高等問題，客戶端也會出現發送堆積的狀況。

ii. 基於現有的機型以及客戶端的消費發送能力的壓測，咱們定義了單分區的承載流量，同時咱們實時對每一個 topic 的流量進行監控，當某個 topic 的峯值流量持續的達到和超過閾值以後，會對該 topic 進行標記或者告警，定義爲分區不足的 topic。

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

• topic資源治理

a.背景：公共集羣中用戶申請建立的 topic，它們的使用狀況是各不相同的，還存在着部分 topic 根本不使用還佔據集羣元數據的狀況，這對原本就十分擁擠的公共集羣形成很大的資源浪費和穩定性風險，所以針對集羣中的不使用的 topic進行治理就很是必要。

b.解決方案：

i. 實時對集羣中全部 topic 的流量進行採集監控，智能的分析 topic 的流量趨勢，若是發現 topic 的流量持續在一段時間內爲0，則進行標記或者告警。

ii. 針對監控發現的必定週期無流量、無生產消費連接的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 的功能和體驗。

開源團隊