專案地址: didi/Logi-KafkaManager: 一站式Apache Kafka集群指標監控與運維管控平臺

運維管控

運維管控這個選單欄目下面主要是供運維人員來管理所有集群的;

集群串列

Kafka的靈魂伴侶Logi-KafkaManger三之運維管控–集群串列

集群運維

遷移任務

kafka的遷移場景, 一般有同集群資料遷移、跨集群資料遷移; 我們這里主要講 同集群資料遷移;
同集群之間資料遷移，比如在已有的集群中新增了一個Broker節點，此時需要將原來集群中已有的Topic的資料遷移部分到新的集群中，緩解集群壓力，

在了解KM的遷移功能之前,我們先了解一下正常情況下是怎么做遷移的;

手動遷移程序實作

磁區重新分配工具可用于將一些Topic從當前的Broker節點中遷移到新添加的Broker中，這在擴展現有集群時通常很有用，因為將整個Topic移動到新的Broker變得更容易，而不是一次移動一個磁區，當執行此操作時，用戶需要提供已有的Broker節點的Topic串列，以及到新節點的Broker串列（源Broker到新Broker的映射關系），然后，該工具在新的Broker中均勻分配給指定Topic串列的所有磁區，在遷移程序中，Topic的復制因子保持不變，

現有如下實體，將Topic為ke01，ke02的所有磁區從Broker1中移動到新增的Broker2和Broker3中，由于該工具接受Topic的輸入串列作為JSON檔案，因此需要明確遷移的Topic并創建json檔案，如下所示：

> cat topic-to-move.json
{"topics": [{"topic": "ke01"},
            {"topic": "ke02"}],
"version":1
}

1 . 準備好JSON檔案，然后使用磁區重新分配工具生成候選分配，命令如下：

> bin/kafka-reassign-partitions.sh --zookeeper dn1:2181 --topics-to-move-json-file topics-to-move.json --broker-list "1,2" --generate

執行完成命令之后，控制臺出現如下資訊：

該工具生成一個候選分配，將所有磁區從Topic ke01，ke02移動到Broker1和Broker2，需求注意的是，此時磁區移動尚未開始，它只是告訴你當前的分配和建議，保存當前分配，以防你想要回滾它，新的賦值應保存在JSON檔案（例如expand-cluster-reassignment.json）中，以使用–execute選項執行，JSON檔案如下：

{"version":1,"partitions":[{"topic":"ke02","partition":0,"replicas":[2]},{"topic":"ke02","partition":1,"replicas":[1]},{"topic":"ke02","partition":2,"replicas":[2]},{"topic":"ke01","partition":0,"replicas":[2]},{"topic":"ke01","partition":1,"replicas":[1]},{"topic":"ke01","partition":2,"replicas":[2]}]}

2. 執行命令如下所示：

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --execute

3. 最后，–verify選項可與該工具一起使用，以檢查磁區重新分配的狀態，需要注意的是，相同的expand-cluster-reassignment.json（與–execute選項一起使用）應與–verify選項一起使用，執行命令如下：

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --verify

執行結果如下圖所示：

Kafka資料遷移 - 哥不是小蘿莉

資料遷移的幾個注意點

減少遷移的資料量: 如果要遷移的Topic 有大量資料（Topic 默認保留7天的資料），可以在遷移之前臨時動態地調整retention.ms 來減少資料量，比如下面命令改成1小時; Kafka 會主動purge 掉1小時之前的資料;

> bin/kafka-topics --zookeeper localhost:2181 --alter --topic sdk_counters --config retention.ms=3600000

不要要注意遷移完成后,恢復原先的設定

遷移程序注意流量陡增對集群的影響
Kafka提供一個broker之間復制傳輸的流量限制，限制了副本從機器到另一臺機器的帶寬上限，當重新平衡集群，引導新broker，添加或移除broker時候，這是很有用的，因為它限制了這些密集型的資料操作從而保障了對用戶的影響、
例如我們上面的遷移操作

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --execute  

在后面加上一個—throttle 50000000 引數, 那么執行移動磁區的時候,會被限制流量在50000000 B/s
加上引數后你可以看到

The throttle limit was set to 50000000 B/s
Successfully started reassignment of partitions.

遷移程序限流不能過小,導致遷移失敗
-throttle 是broker之間復制傳輸的流量限制,限制了副本從機器到另一臺機器的帶寬上限; 但是你應該了解到正常情況下,副本直接也是有副本同步的流量的; 如果限制的低于正常副本同步的流量值,那么會導致副本同步例外,跟不上Leader的速率很快就被踢出ISR了;

遷移完成,注意要移除流量的限制：
如果我們加上了遷移這個操作, 需要使用引數--verify 來驗證執行狀態,同時流量限制也會被移除掉; 否則可能會導致定期復制操作的流量也受到限制，

> ./kafka-reassign-partitions.sh --zookeeper dn1:2181 --reassignment-json-file expand-cluster-reassignment.json --verify  

詳情請參考
kafka在資料遷移期間限制帶寬的使用 - OrcHome

KM實作資料遷移

了解完了手動遷移的流程后,那我們再來了解一下KM的遷移動作,那么你會愛上這個操作;因為極大的簡化了遷移操作;

上圖中是創建一個 遷移任務的操作; 解釋一下里面的幾個引數;

上面我主要講解幾個引數

遷移后Topic的保存時間:
我們上面講解遷移注意事項的時候有講解到,需要 減少遷移的資料量 ; 假如你默認保存了7天的資料量, 那么這個遷移的資料量可能非常的大,并且很多都是已經消費過得過期資料; 所以我們需要在先把這么多過期資料給清理掉之后再開始遷移; 這個引數填的就是保存最近多久的資料;刪掉過期的資料; 并且遷移結束之后會把時間改回成原來的時間;

初始限流:
限流上線:
限流下線:
可能你看到這幾個引數會很奇怪, 限流不就是一個確定的值么,填一個限流值就行了,搞這么多是要干啥;

其實是 KM想做成的是動態調整限流, 根據不同時間和集群狀態去動態調整, 比如空閑時候我最大可以允許你流量達到100M/s(限流上線); 但是如果你在遷移的時候可能壓力比較大,我不想讓你一開始就用這個100M/s限流; 遷移開始時候使用初始限流,但是限流不能過小，因為要考慮正常情況下副本同步時候的流量,所以有了限流下線 ;
然后KM每隔一段時間(1分鐘)就會去檢查遷移狀態,然后動態調整限流值;

當然,現在KM中其實用的還是初始限流這個值來作為限流; 并沒有動態的來調整流速; 這個是將來需要改造的點;

創建完遷移任務之后,KM定時器檢測到達到開始時間之后,就會開始正式遷移;
執行的程序跟我們上面講到的遷移流程一樣,只是程式自動幫我們去實作了;

如果資料量大,遷移任務建議放在空閑時間段

集群任務

這個模塊是用于自動化kafka集群升級用的,但是需要配合夜鶯系統來使用(主要是在KM上將升級包發送到服務器上);
這個功能對應大集群來說非常好用,自動在線升級; 不需要手動去操作;

簡單看一下使用圖

如何對接夜鶯系統, 等我有空再補充 對接夜鶯系統,TODO

版本管理

創建集群任務的時候, 需要上傳 kafka升級包,和組態檔集

平臺管理

應用管理

管理 所有使用Kafka的應用, Topic的創建需要管理到對應的系統(哪個系統); 這里展示的是所有的應用；如果想看自己負責的應用;查看路徑是 Topic管理 -> 應用管理

應用申請

具有應用申請權限的用戶可以申請新的應用 ; 然后由運維人員審批;
申請的地方在 Topic管理 -> 應用管理 -> 應用申請

應用負責人至少是兩個

應用詳情

展示一些應用基本資訊, 其中AppId和 密鑰 在Topic鑒權的時候會使用到;

運維人員和應用責任人可以編輯資訊,比如可以添加新的責任人;

申請下線

如果應用已經廢棄不使用了,可以申請下線; 除了在這里運維管理人員可以申請下線; 應用負責人可以在 Topic管理->應用管理 那里申請下線;

這里的展示的 連接資訊 是需要配置滴滴的kafka-gateway組件才會展示的; 否則是拿不到相應的資訊的; kafka-gateway并未開源,如果需要請聯系官方;

連接資訊展示Demo TODO…

在申請應用下線之前, 需要先確認該應用下面創建的所有topic都下線,否則運維人員下線的時候會提示：先下線topic,才能下線應用~
還需要注意就是如果申請了其他topic的使用權限,需要先取消權限

應用負責人需要申請Topic下線地方在 Topic管理->我的Topic->更多->申請下線
注意只有 你是應用負責人才能申請下線; 如果只是有部分使用權限是不能申請下線的;

同樣的,這里的展示的 連接資訊 是需要配置滴滴的kafka-gateway組件才會展示的; 否則是拿不到相應的資訊的; kafka-gateway并未開源,如果需要請聯系官方;

用戶管理

運維人員 管理用戶

用戶角色

KafkaManager的用戶角色分了3種:

運維人員： 擁有平臺所有權限
研發人員： 除了專家服務等權限,其他都有
普通用戶： 普通開發者, 只有Topic管理,集群管理,監控告警等等權限

其實這里的角色權限取名理解起來比較費解,一開始我也以為研發人員就是我們所理解的普通開發者;
但是實際上
普通用戶: 這個角色才是我們寫代碼使用kafak的開發者; 只需要關心自己的Topic模塊就行;
研發人員： 包含普通用戶的權限,但是它又具備運維管控的權限,使用場景就是 可能該角色是一個小組的TeamLeader;或者技術專家,他在普通用戶的基礎上需要去了解一下整個物理集群的監控狀態,和找一些問題;

KM的用戶角色和權限這一塊還比較粗糙,跟社區反饋過,社區回應的是 將來會大改這一塊,做一套統一的權限資源管理;

平臺配置

一些系統的內部配置

配置鍵: ADMIN_ORDER_HANDLER_CONFIG 指定賬戶擁有審批權限
配置值Demo: [ "shirc_10", "shirc1" ]
描述: 很多審批需要運維人員進行審批; 如果運維人員太忙,不想花費時間在審批上,則可以指定部分賬戶擁有 審批權限; 代替審批; 這時候運維人員就沒有權限審批了,審批按鈕被隱藏了

申請人通過詳情這里可以看到哪些人可以審批; 就可以找到對應的人幫忙審批一下了;

配置鍵: REGION_CAPACITY_CONFIG 設定集群Broker的默認最大支持流量
具體詳情: 在 Kafka的靈魂伴侶Logi-KafkaManger三之運維管控–集群串列 有詳細描述

系統每隔2分鐘就去嘗試將未落盤(比如剛接入KM,已經存在的Topic都未落盤)的Topic重繪到DB中; 當前前提是配置打開了 task.op.sync-topic-enabled: true
但是默認情況下,topic這個時候雖然刷到DB中了,但是屬于無主Topic.沒有系結到對應的應用中
如果你想在刷到DB中的時候讓它默認就系結到某個默認的應用上就可以用到下面的配置了;

SYNC_TOPIC_2_DB_CONFIG_KEY 定期將未落盤的Topic重繪到DB中的時候,是否系結到具體的應用和權限;
[ { "clusterId": 4, "defaultAppId": "dkm_admin", "addAuthority": true }, { "clusterId": 5, "defaultAppId": "dkm_admin", "addAuthority": true } ]

clusterId: 物理集群id
defaultAppId：默認系結到的應用id
addAuthority: 是否同時增加應用對該topic的讀寫權限;

使用場景: 感覺沒啥大用,就算這個時候沒有系結到應用上,后面我們還是可以針對Topic一個個去系結對應的應用的;

其他一些不是很重要的配置就不列舉了,有興趣可以直接看原始碼

網關配置

配合 滴滴的kafka-gateway 組件使用的; 開源版本不需要關注

網關配置詳細TODO

專欄文章串列

Kafka的靈魂伴侶Logi-KafkaManger一之集群的接入及相關概念講解

Kafka的靈魂伴侶Logi-KafkaManger二之kafka針對Topic粒度的配額管理(限流)

Kafka的靈魂伴侶Logi-KafkaManger三之運維管控–集群串列

如果文章對你有幫助的話, 麻煩給博主一鍵三連呀, 原創不易 你的支持是我輸出的動力 ?🏻