告警解釋
系統按60秒周期檢測Kafka磁盤空間使用率，并把實際磁盤使用率和閾值相比較。磁盤使用率默認提供一個閾值范圍。當檢測到磁盤使用率高于閾值時產生該告警。
用戶可通過“運維 > 告警 > 閾值設置”，在服務列表下面，選擇“Kafka > 磁盤 > Broker磁盤使用率 (Broker)”修改閾值。
平滑次數為1，Kafka磁盤使用率小于或等于閾值時，告警恢復；平滑次數大于1，Kafka磁盤使用率小于或等于閾值的90%時，告警恢復。
告警屬性
| 告警ID | 告警級別 | 是否自動清除 |
|---|---|---|
| 38001 | 重要 | 是 |
告警參數
| 參數名稱 | 參數含義 |
|---|---|
| 來源 | 產生告警的集群名稱。 |
| 服務名 | 產生告警的服務名稱。 |
| 角色名 | 產生告警的角色名稱。 |
| 主機名 | 產生告警的主機名。 |
| 設備分區名 | 產生告警的磁盤分區。 |
| Trigger Condition | 系統當前指標取值滿足自定義的告警設置條件。 |
對系統的影響
磁盤容量不足會導致Kafka寫入數據失敗。
可能原因
- 用于存儲Kafka數據的磁盤配置（如磁盤數目、磁盤大小等），無法滿足當前業務數據流量，導致磁盤使用率達到上限。
- 數據保存時間配置過長，數據累積達到磁盤使用率上限。
- 業務規劃不合理，導致數據分配不均，使部分磁盤達到使用率上限。
處理步驟
檢查Kafka數據的磁盤配置。
- 在FusionInsight Manager管理界面，選擇“運維 > 告警 > 告警”。
- 在告警列表中單擊該告警，從“定位信息”中獲得主機名。
- 選擇“集群 > 待操作集群的名稱 > 主機”。
- 在“主機”頁面單擊步驟2中獲取的主機名稱。
- 檢查“磁盤”區域中是否包含該告警中的磁盤分區名稱。
- 是，執行步驟6。
- 否，手動清除該告警，操作結束。
- 檢查“磁盤”區域中包含該告警中的磁盤分區使用率是否達到百分之百。
- 是，參考參考信息進行處理。
- 否，執行步驟7
檢查Kafka數據保存時間配置。
- 選擇“集群 > 待操作集群的名稱 > 服務 > Kafka > 配置 > 全部配置”。
- 查看“disk.adapter.enable”參數是否配置為“true”。
- 是，執行步驟10。
- 否，執行步驟9。
- 將“disk.adapter.enable”配置為“true”，開啟該功能。然后查看“adapter.topic.min.retention.hours”所配置的數據最短保存周期是否合理。
- 是，執行步驟10。
- 否，根據業務需求合理調整數據保存周期。
須知 ：啟用磁盤自適應功能可能導致Topic的歷史數據被清除，如果有個別Topic不能做保存周期調整，單擊“全部配置”，將Topic配置在“disk.adapter.topic.blacklist”參數中。
- 等待10分鐘，查看故障磁盤的使用率是否有減少。
- 是，繼續等待直到告警消除。
- 否，執行步驟11。
檢查Kafka數據規劃。
- 選擇上報告警實例主機名對應的角色“Broker”。單擊圖表區域右上角的下拉菜單，選擇“定制”，來自定義監控項。
- 在彈出的“定制”對話框中，選擇“磁盤 > Broker磁盤使用率”，并單擊“確定”。
關于Kafka磁盤使用情況信息會被顯示。
- 根據步驟12的顯示信息，查看是否只有步驟2中上報告警的磁盤分區。
- 是，執行步驟14。
- 否，執行步驟15。
- 重新進行磁盤規劃，掛載新的磁盤，進入當前問題節點“實例配置”頁面，重新配置“log.dirs”，增加其他磁盤相應路徑，重啟當前Kafka實例。
- 查看Kafka配置的數據保存時間配置，根據業務需求和業務量權衡，考慮是否需要調小數據保存時間。
- 是，執行步驟16。
- 否，執行步驟17。
- 在FusionInsight Manager界面，選擇“集群 > 待操作集群的名稱 > 服務 > Kafka > 配置 > 全部配置”，在右側搜索框中填寫配置項名稱“log.retention.hours”，然后會顯示該配置的當前值，此處的值為Topic默認的數據保存時間，可以適當調小該值。
說明
- 對于單獨配置數據保存時間的Topic，修改Kafka服務配置頁面上配置的數據保存時間不生效。
- 如果需要對某個Topic單獨配置的話，可以使用Kafka客戶端命令行，來單獨配置該Topic。
例如： kafka-topics.sh --zookeeper “ ZooKeeper 地址: 2181/kafka ”--alter --topic “ Topic 名稱 ” --config retention.ms= “ 保存時間 ”
- 查看是否由于某些Topic的Partition配置不合理導致部分磁盤使用率達到上限（例如：數據量非常大的Topic的Partition數目小于配置的磁盤個數，導致各磁盤上數據分配無法均勻，進而部分磁盤達到使用率上限）。
說明
對于單獨配置數據保存時間的Topic，修改Kafka服務配置頁面上配置的數據保存時間不生效。
如果需要對某個Topic單獨配置的話，可以使用Kafka客戶端命令行，來單獨配置該Topic。
例如： kafka-topics.sh --zookeeper “ ZooKeeper 地址: 2181/kafka ”--alter --topic “ Topic 名稱 ” --config retention.ms= “ 保存時間 ”
- 通過Kafka客戶端對Topic的Partition進行擴展，命令行操作命令如下：
kafka-topics.sh --zookeeper“ ZooKeeper 地址 :2181/kafka ” --alter --topic “ Topic 名稱 ” --partitions= “ 新Partition 數目 ”
說明
新Partition數目建議配置為Kafka數據磁盤數量的倍數。
當前步驟修改可能不會很快解決當前告警，需要結合步驟11中的數據保存時間逐漸均衡數據。
- 考慮是否需要擴容。
說明建議當前Kafka磁盤使用率超過80%時，則需要擴容。
是，執行步驟20。
否，執行步驟21。
- 擴展磁盤容量，擴展后檢查告警是否消失。
- 是，操作結束。
- 否，執行步驟22。
- 檢查告警是否清除。
- 是，操作結束。
- 否，執行步驟22。
收集故障信息。
- 在FusionInsight Manager界面，選擇“運維 > 日志 > 下載”。
- 在“服務”中勾選待操作集群的“Kafka”。
- 單擊右上角的
設置日志收集的“開始時間”和“結束時間”分別為告警產生時間的前后10分鐘，單擊“下載”。 - 請聯系運維人員，并發送已收集的故障日志信息。
告警清除
此告警修復后，系統會自動清除此告警，無需手工清除。
參考信息
- 登錄FusionInsight Manager，選擇“集群 > 待操作集群的名稱 > 服務 > Kafka > 實例”，將運行狀態為“正在恢復”的Broker實例停止并記錄實例所在節點的管理IP地址以及對應的“broker.id”，該值可通過單擊角色名稱，在“實例配置”頁面中選擇“全部配置”，搜索“broker.id”參數獲取。
- 以root用戶登錄記錄的管理IP地址，并執行df -lh命令，查看磁盤占用率為100%的掛載目錄，例如“${BIGDATA_DATA_HOME}/kafka/data1”。
- 進入該目錄，執行 du -sh 命令，查看該目錄下各文件夾的大小。查看是否存在除“kafka-logs”目錄外的其他文件，并判斷是否可以刪除或者遷移。
- 是，刪除或者遷移相關數據，然后執行步驟8。
- 否，執行步驟4。
- 進入“kafka-logs”目錄，執行 du -sh 命令，選擇一個待移動的Partition文件夾，其名稱命名規則為“Topic名稱-Partition標識”，記錄Topic及Partition。
- 修改“kafka-logs”目錄下的“recovery-point-offset-checkpoint”和“replication-offset-checkpoint”文件（兩個文件做同樣的修改）。
- 減少文件中第二行的數字（若移出多個目錄，則減少的數字為移出的目錄個數）。
- 刪除待移出的Partition所在的行（行結構為“Topic名稱 Partition標識 Offset”，刪除前先將該行數據保存，后續此內容還要添加到目的目錄下的同名文件中）。
- 修改目的數據目錄下（例如：“${BIGDATA_DATA_HOME}/kafka/data2/kafka-logs”）的“recovery-point-offset-checkpoint”和“replication-offset-checkpoint”文件（兩個文件做同樣的修改）。
- 增加文件中第二行的數字（若移入多個Partition目錄，則增加的數字為移入的Partition目錄個數）。
- 添加待移入的Partition行到文件末尾（行結構為“Topic名稱 Partition標識 Offset”，直接復制步驟5中保存的行數據即可）。
- 移動數據，將待移動的Partition文件夾移動到目的目錄下，移動完成后執行chown omm:wheel -R Partition目錄命令修改Partition目錄屬組。
- 登錄FusionInsight Manager，選擇“集群 > 待操作集群的名稱 > 服務 > Kafka > 實例”，啟動停止的Broker實例。
- 等待5至10分鐘后查看Broker實例的運行狀態是否為“良好”。
- 是，修復完成后按照“ALM-38001 Kafka磁盤容量不足”告警指導徹底解決磁盤容量不足問題。
- 否，聯系運維人員。
