滴滴 Logi-KafkaManager 的用戶體驗設計

本期我們將會對滴滴 Logi—KafkaManager 的生產消費、資源申請、生產 / 消費示例和監控告警進行詳細解釋。

生產消費概述：將簡要說明生產 / 消費流程；

資源申請：將簡要說明講解應用資源、集羣資源、Topic 資源含義，及申請流程；

生產 / 消費示例：將簡要說明生產 / 消費客戶端含義，及客戶端代碼的主要配置信息；

監控告警將講解：Topic 核心指標監控，及安全告警的指標上報；

一、生產消費概述

Kafka 中的消息以主題爲單位進行歸類，生產者負責將消息發送到特定的主題（發送到 Kafka 集羣中的每一條消息都要指定一個主題），而消費者負責訂閱主題並進行消費。在生產、消費環節，消費者需通過 Topic+AppID 進行身份鑑權。

應用：也就是 AppID。可以理解爲是 kafka 中的賬戶，並通過 AppID+Password 作爲身份標識；

集羣：用戶可使用平臺提供的共享集羣，若用戶對穩定性、隔離、數據傳輸速率有更高的需求也可爲某一應用申請單獨的集羣；

Topic：可申請創建 Topic 或申請其他 Topic 的生產 / 消費權限。進行生產 / 消費時需要通過 Topic+AppID 進行身份鑑權。

下圖右側是生產消費的流程圖：第一步會先判斷該用戶名下是否擁有應用。若無，則需申請應用；若有，再判斷是否擁有集羣權限。若無集羣權限則需申請集羣，若有，再判斷是否擁有 Topic 的生產消費權限，若無，則需申請 Topic 的相應權限，或創建 Topic。若有權限，便可以通過客戶端進行生產 / 消費。

二、資源申請

應用（AppID）申請

應用（AppID）作爲 Kafka 中的賬戶，使用 AppID+Password 作爲身份標識，在對 Topic 進行生產 / 消費時需通過 Topic+AppID 進行身份鑑權。

用戶在申請應用時，需經由運維人員審批，審批通過後可以獲得 AppID 和密鑰。

點擊進入 Topic 管理 - 應用管理 - 申請應用。填寫申請信息，提交審批，由運維人員進行審批。

審批通過後，可在應用列表查看剛剛創建的應用，點擊詳情，可以查看到 AppID 和密鑰。

集羣申請

用戶可使用平臺提供的共享集羣，若對隔離性、穩定性、生產消費速率有更高的需求，可對某一應用申請單獨的集羣。

從下圖右側的流程圖可以看到，用戶提出集羣申請，申請時需填寫集羣申請單，申請單裏需要填所屬應用——就是要爲哪一個應用申請單獨的集羣。

運維人員會根據申請單填寫集羣類型、峯值流量、申請原因以及應用的實際使用情況來部署、創建相應的集羣。

集羣管理 - 集羣申請單提交

Topic 申請

用戶可根據已申請的應用來創建 Topic，創建 Topic 後，應用負責人默認擁有該 Topic 的生產 / 消費權限和管理權限，也可申請其他 Topic 的生產、消費權限。

上圖右側是申請 Topic 權限的申請表單，用戶需填寫綁定的應用、申請的對應權限、原因。提交後，經由 Topic 所屬應用的負責人審批後，即可擁有相應權限。

1、進入 Topic 管理 - 我的 Topic，列表會展示出我的 Topic，其中包含我創建的和我申請的。

2、點擊右上角的按鈕，彈窗內填寫相應的配置信息、所屬集羣等申請信息。提交申請後，由運維人員根據用戶填寫的申請信息和實際情況，創建相應配置的 Topic。例如，給該 Topic 創建 3 分區、2 副本、數據保存時間是 12 小時、該 Topic 最終落在 xxx region 上。或者 xxx broker 上。

在 Topic 詳情頁中展示：

Topic 基本信息：包含 Topic 的名稱、所屬應用、負責人、所屬 region、bootstrap 地址等基礎信息，以及實時流量、實時耗時等指標監控信息。

狀態圖：展示當前 Topic 的歷史流量、歷史耗時。

連接信息：展示近期連接過當前 Topic 的應用，含 AppID、主機名、客戶端版本等。

消費組信息：展示當前 Topic 的消費組信息，含消費組 ID、所屬 AppID 等。

分區信息：展示當前 Topic 的分區信息，含分區 ID、beginningOffset、endOffset、msgNum 等。

Broker 信息：展示當前 Topic 所在 Broker 的相關信息，含 BrokerID、host、leader 個數、分區 leaderID、分區個數等。

應用信息：展示擁有當前 Topic 權限的應用，含應用名稱、權限類型、相關配額等。

三、生產 / 消費示例

當這些資源準備就緒之後，就可以進行真實的生產 / 消費了。生產 / 消費在 Kafka 中是通過客戶端來實現的，指的是對 Topic 進行生產、消費的實例，用戶需編寫客戶端代碼，來實現生產、消費動作。

可以看到上圖左側的客戶端代碼內包含 Topic 名稱、應用（AppID）、密鑰、消息詳情、消費組、壓縮格式等配置信息。

從上圖右側的流程圖可以看出，客戶端進行生產 / 消費時，是需要具有相應 Topic 的生產 / 消費權限的，而這個生產消費鑑權是通過 Topic+AppID 來實現的。但是在市場上許多同類產品中，大多無 AppID 的定義。

消費者在無身份驗證、身份鑑權環境中，進行生產消費時，只需要知道 Topic 信息就可以進行生產消費。這種情況下，會存在很大的數據泄漏、數據篡改等數據安全風險。

當把數據發送至 Topic 後，我們還可以通過數據採樣，對 Topic 裏的樣例數據進行採集。

我們還爲滴滴 Logi-KafkaManager 設計了平臺化界面，方便運維人員配置採集參數。

例如，採樣的數據量、超時時間、採樣的分區號、採樣的 offset 位置。

以上採集後的數據，均支持一鍵複製。

四、監控告警

Topic 指標監控

在滴滴 Logi-KafkaManager 中，可以對 Topic 生產消費各環節耗時進行統計，便於用戶自助排查問題，且在關鍵指標業務運行時，能夠監控不同分位數性能指標，對歷史問題回溯診斷。

在 Topic 詳情頁，用戶可以看到 Topic 的實時流量、實時耗時，實時耗時還可以切換成 75/99 分位的數據。

在狀態圖中，滴滴 Logi-KafkaManager 用圖標展示了該 Topic 各時間段、各應用的流量情況和歷史耗時的信息。這樣，用戶就可以通過豐富的監控指標，實現自助排查問題。同時，用戶亦可自助發起調整配額、增加分區的申請，交由運維人員進行審批。

安全告警

針對 Kafka 生產消費核心指標，滴滴 Logi-KafkaManager 用戶可自定義指標上報渠道。此操作支持用戶自助創建安全告警策略、設置安全響應級別、配置告警通知接收組，以此來協助用戶建立 Kafka 監控告警體系。

1、進入監控告警 - 新建告警規則，監控告警的基本信息分別是名稱和所屬應用。

2、選擇要監控的指標，集羣和 Topic。

3、選擇報警的策略（比如在最近一個週期內 1 次等於 1 條 / 秒）、報警的生效時間、配置報警時，發送的消息內容、報警週期、週期內報警次數、報警接受組。

由於滴滴 Logi-KafkaManager 默認對接滴滴夜鶯監控告警系統，用戶可以搭配滴滴夜鶯一併使用，配置方法可以參考滴滴夜鶯的配置文檔項目。

當然也可以對接企業內部的監控告警系統，但是滴滴 Logi-KafkaManager 與滴滴夜鶯監控告警系統適配度更高，還是建議使用夜鶯的哈～

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/cKymvfMdgWK5_CqbbmAOkw

猜你喜歡