Kafka指標監控與叢集問題診斷

Kafka 提供的指標能透過 JMX 介面存取，並可使用外部監控代理程式或直接在 Kafka 程式中執行的 JMX 代理程式收集。設定監控代理程式需考量組織的監控經驗，並可選擇監控即服務方案。Kafka 將 JMX 連線埠資訊儲存在 ZooKeeper 中，但根據安全考量，預設停用遠端 JMX。監控 Kafka 需考量應用程式指標、日誌、基礎設施指標、合成客戶端和客戶端指標。指標的用途區分為警示和除錯，並需考量歷史資料以進行容量管理。自動化工具能有效處理監控資料，但仍需人工判斷和干預。監控 Kafka 時，需考慮指標的消費者、應用程式健康檢查和服務水平目標（SLO）。指標應根據消費者型別調整呈現方式，並建立健康檢查機制以確保應用程式和監控系統正常運作。SLO 協助向客戶傳達服務水平，包含服務水平指標（SLI）、服務水平目標（SLO）和服務水平協定（SLA）。選擇 SLI 時，建議使用 Kafka brokers 外部收集的指標，例如基礎設施指標、合成客戶端指標和客戶端指標。

指標哪裡找？

Kafka 所提供的所有指標都能夠透過 Java Management Extensions（JMX）介面來存取。若要在外部監控系統中使用這些指標，最簡單的方式是使用監控系統提供的收集代理程式（collection agent），並將其附加到 Kafka 程式。這可以是一個單獨的程式，執行在系統上並連線到 JMX 介面，例如使用 Nagios XI 的 check_jmx 外掛或 jmxtrans。您也可以使用直接在 Kafka 程式中執行的 JMX 代理程式，例如 Jolokia 或 MX4J，透過 HTTP 連線存取指標。

設定監控代理程式

深入討論如何設定監控代理程式超出了本章的範圍，而且由於選擇太多，很難對所有選擇做出公正的評價。如果您的組織目前沒有監控 Java 應用程式的經驗，那麼考慮將監控作為一種服務可能是值得的。許多公司提供監控代理程式、指標收集點、儲存、圖表和警示服務。他們可以進一步幫助您設定所需的監控代理程式。

找到 JMX 連線埠

為了幫助設定直接連線到 Kafka broker 上的 JMX 的應用程式（例如監控系統），broker 將組態的 JMX 連線埠儲存在 ZooKeeper 中的 broker 資訊中。/brokers/ids/<ID> 節點包含 broker 的 JSON 格式資料，包括主機名稱和 jmx_port 鍵。然而，應該注意的是，出於安全原因，Kafka 預設停用遠端 JMX。如果您打算啟用它，則必須正確組態連線埠的安全性。這是因為 JMX 不僅允許檢視應用程式的狀態，還允許執行程式碼。強烈建議您使用載入到應用程式中的 JMX 指標代理程式。

非應用程式指標

並非所有指標都來自 Kafka 本身。在監控 Kafka broker 時，有五個主要的指標來源類別。表 13-1 描述了這些類別。

表 13-1. 指標來源

Kafka 生成的日誌將在本章後面討論，客戶端指標也是如此。我們還將簡要討論合成指標。然而，基礎設施指標取決於您的特定環境，因此超出了此處的討論範圍。在您的 Kafka 之旅中，您越深入，這些指標來源對於全面瞭解您的應用程式執行情況就越重要。例如，依賴 broker 的指標就足夠了，但稍後您將需要更客觀地瞭解它們的效能。

我需要哪些指標？

哪些指標對您重要是一個問題，就像選擇最好的編輯器一樣。這將在很大程度上取決於您打算用它們做什麼，您有哪些工具可用於收集資料，您在使用 Kafka 的過程中走了多遠，以及您有多少時間可花在圍繞 Kafka 建立基礎設施上。一個 broker 內部開發人員的需求將與執行 Kafka 佈署的網站可靠性工程師大不相同。

警示還是除錯？

您應該首先問自己的問題是，您的主要目標是當 Kafka 出現問題時發出警示，還是除錯發生的問題。答案通常會同時涉及兩者，但知道一個指標是用於其中之一，將允許您在收集後對其進行不同的處理。

用於警示的指標

用於警示的指標在很短的時間內很有用——通常不超過回應問題所需的時間。您可以按小時或幾天來衡量這些指標。這些指標將被自動化系統消費，以回應已知問題，以及在自動化不存在的情況下的人工操作員。通常，這些指標更客觀，因為對客戶端沒有影響的問題遠不如有影響的問題那麼重要。

用於除錯的資料

主要用於除錯的資料具有更長的時間範圍，因為您經常診斷已經存在一段時間的問題，或者更深入地研究更複雜的問題。這些資料需要在收集後幾天或幾週內保持可用。它通常也是更主觀的測量結果，或者是來自 Kafka 應用程式本身的資料。請記住，並不總是需要將這些資料收集到監控系統中。如果指標用於現場除錯問題，那麼在需要時有指標可用就足夠了。您不需要透過持續收集數萬個值來壓倒監控系統。

歷史指標

您最終還需要第三種型別的資料，即應用程式的歷史資料。歷史資料最常見的用途是進行容量管理，因此它包括有關使用的資源的資訊，包括計算資源、儲存和網路。這些指標需要儲存很長一段時間，以年為單位。您還可能需要收集額外的後設資料，以便將指標置於上下文中，例如何時將 broker 新增到叢集或從叢集中刪除。

自動化還是人工處理？

這取決於您的需求和可用的資源。如果有自動化工具能夠有效地處理和回應監控資料，那麼優先考慮自動化。然而，在某些情況下，人為判斷和干預是不可或缺的。因此，瞭解何時採用自動化，何時需要人工干預是非常重要的。

監控 Kafka 的關鍵指標與服務水平目標

在監控 Kafka 時，需要考慮多個層面，包括指標的收集、應用程式的健康檢查以及服務水平目標（SLO）的定義。這些元素共同構成了對 Kafka 叢集全面監控的基礎。

指標的消費者與呈現方式

首先，需要考慮的是誰將消費這些指標。如果指標將被自動化系統消費，那麼它們應該非常具體。電腦處理大量資料的能力使得擁有大量描述細節的指標變得可行和必要。具體的資料使得自動化系統能夠更容易地根據資料採取行動，因為資料的含義沒有太多的解釋空間。另一方面，如果指標將被人消費，那麼呈現大量的指標將會令人不知所措。

針對自動化與人工消費的不同策略

對於自動化系統，指標的具體性和詳細程度至關重要。這是因為自動化系統需要明確的資料來執行相應的操作。然而，對於人類使用者來說，過多的指標會導致資訊過載，難以快速抓住關鍵問題。

以汽車運作為例，汽車電腦需要多項測量資料來調整空燃比，但對於人類駕駛員來說，「檢查引擎」燈就足夠提示存在問題，並且可以透過進一步檢查獲得詳細資訊。

應用程式健康檢查

無論如何收集 Kafka 的指標，都應該確保有一種方法可以透過簡單的健康檢查來監控應用程式程式的整體健康狀況。這可以透過兩種方式實作：

1. 外部程式報告：檢查 Kafka broker 是否正在執行。
2. 警示缺乏指標：如果 Kafka broker 沒有報告指標，可能意味著 broker 或監控系統本身出現故障。

對於 Kafka broker，健康檢查可以簡單地透過連線到外部埠來完成。對於客戶端應用程式，健康檢查可能更複雜，從簡單的程式執行檢查到內部方法來確定應用程式健康狀況。

服務水平目標（SLO）

對於像 Kafka 這樣的基礎設施服務，SLO 尤其重要。SLO 用於向客戶傳達他們可以期待的服務水平。客戶希望將服務視為一個不透明的系統，只關心介面和服務是否滿足他們的需求。

服務水平定義

在討論 Kafka 的 SLO 之前，需要對術語達成一致：

• 服務水平指標（SLI）：描述服務可靠性的某個方面的指標。它應該與客戶的體驗密切相關，通常以客觀測量為佳。在像 Kafka 這樣的請求處理系統中，SLI 通常以良好事件與總事件的比例來表示。
• 服務水平目標（SLO）：結合 SLI 和目標值。例如，在 7 天內，99% 的請求必須傳回有效的回應。
• 服務水平協定（SLA）：服務提供者和客戶之間的契約，包括 SLO、測量和報告方式、支援請求處理方式以及未達標的處罰。

操作水平協定（OLA）

OLA 描述了多個內部服務或支援提供者之間的協定，以確保 SLA 的達成。它們在日常營運中確保了達成 SLA 所需的多項活動被正確描述和記錄。

什麼指標適合作為 SLI？

通常，用於 SLI 的指標應該透過 Kafka brokers 外部的手段收集。這是因為 SLO 應該描述典型使用者是否滿意，而這是主觀的。客戶不關心服務提供者是否認為服務執行正常，他們關心的是自己的體驗。因此，基礎設施指標、合成客戶端指標和客戶端指標通常是 SLI 的良好選擇。

在Kafka中實施服務水平目標（SLO）與監控

在管理Kafka叢集時，定義和監控服務水平指標（SLIs）和服務水平目標（SLOs）至關重要，以確保系統的可靠性和效能。本文將探討如何在Kafka中實施SLOs，以及如何利用這些指標進行警示和故障診斷。

常見的服務水平指標（SLIs）

在請求/回應和資料儲存系統中，常見的SLIs包括：

• 可用性：客戶端是否能夠發出請求並獲得回應？
• 延遲：回應傳回的速度有多快？
• 品質：回應是否包含正確的內容？
• 安全性：請求和回應是否得到適當的保護，例如授權或加密？
• 吞吐量：客戶端是否能夠快速獲得足夠的資料？

使用SLOs進行警示

SLOs應該用於指導主要的警示機制，因為它們描述了客戶端視角下的問題。利用SLO燃燒率（burn rate）可以提供早期預警，幫助團隊在違規之前採取行動。

示例

假設您的Kafka叢集每週接收一百萬個請求，並且您定義了一個SLO，要求99.9%的請求必須在10毫秒內發送出第一個位元組的回應。這意味著在整個星期內，您最多可以有一千個請求回應慢於此閾值。

如果燃燒率從0.1%上升到0.4%，然後進一步躍升至2%，您的警示就會觸發。透過監控燃燒率，您可以在違規發生之前診斷和解決問題。

Kafka代理指標

Kafka提供了眾多的代理指標，用於監控系統的健康狀態和效能。這些指標對於日常維運至關重要。

監控Kafka的挑戰

許多組織使用Kafka收集應用程式指標、系統指標和日誌，供中央監控系統使用。然而，這種方法可能會導致監控系統依賴於Kafka，從而在Kafka本身出現問題時無法及時發現。

為瞭解決這個問題，可以使用獨立的監控系統，或者在多個資料中心之間交叉監控對方的Kafka叢集。

診斷叢集問題

叢集問題主要分為三類別：

1. 單一代理問題：最容易診斷和回應，通常表現為異常值。
2. 過載叢集：需要檢查吞吐量和資源利用率。
3. 控制器問題：影響叢集的穩定性和可用性。

透過監控關鍵的代理指標，可以及時發現和解決叢集問題。

Kafka 叢集問題診斷與監控

在維護 Kafka 叢集的過程中，監控系統的健康狀態是至關重要的。許多問題的根源在於硬體故障、資源耗盡或叢集負載不均衡。瞭解如何診斷這些問題並採取適當的措施，可以有效提升叢集的穩定性和效能。

硬體與資源問題的檢測

Kafka 叢集的問題往往與硬體或資源限制有關，例如儲存裝置故障或運算資源被其他應用程式佔用。要檢測這些問題，首先需要監控個別伺服器和儲存裝置的可用性，並利用作業系統（OS）指標來進行監控。

叢集負載不均衡的問題

即使 Kafka 會嘗試將資料均勻分佈在所有代理（broker）上，但客戶端對資料的存取並不一定是均勻分佈的。此外，Kafka 也無法檢測到像是熱區分割（hot partitions）等問題。因此，建議使用外部工具來持續保持叢集的平衡，例如 Cruise Control。這個工具能夠持續監控叢集並重新平衡分割區，同時提供其他管理功能，如新增和移除代理。

首選副本選舉（Preferred Replica Elections）

在進一步診斷問題之前，第一步是確保最近有執行過 首選副本選舉。Kafka 代理不會自動還原分割區長官權，除非啟用了自動長官者重新平衡功能。這意味著長官者副本很容易在叢集中變得不平衡。執行首選副本選舉是安全且簡單的操作，因此建議先執行此操作，看看問題是否能夠解決。

過載叢集的檢測與解決

過載的叢集是另一個容易檢測到的問題。如果叢集已經達到平衡，但許多代理顯示出較高的請求延遲或請求處理程式池空閒率較低，那麼就意味著代理已經達到處理能力的極限。進一步檢查可能會發現某些客戶端的請求模式發生了變化，並導致了問題。即使如此，改變客戶端的行為可能並不可行，解決方案通常是減少叢集的負載或增加代理數量。

Controller 相關問題的診斷

Kafka 叢集中的 Controller 相關問題通常比較難以診斷，並且往往與 Kafka 本身的 Bug 有關。這些問題可能表現為代理後設資料不同步、副本離線，或者主題控制操作（如建立）無法正常進行。如果遇到看似非常奇怪的問題，很可能是因為 Controller 出現了不可預測的錯誤。監控活躍的 Controller 數量以及 Controller 佇列大小，可以提供高層次的指標來判斷是否存在問題。

未同步分割區（Under-Replicated Partitions）的藝術

在監控 Kafka 時，未同步分割區（URP） 是一個非常重要的指標。每個代理上的這個指標提供了該代理作為長官者副本的分割區數量，其中追隨者副本尚未同步。這個指標能夠反映出叢集中的多種問題，從代理宕機到資源耗盡。由於 URP 能夠指示多種不同的問題，因此深入瞭解如何應對非零的 URP 值是非常重要的。

URP 警示的陷阱

過去，我們曾建議將 URP 指標作為主要的警示指標，因為它能夠描述多種問題。然而，這種做法存在許多問題，其中最主要的是 URP 指標經常會因為一些無害的原因而變為非零值。這會導致頻繁的誤報，使得警示被忽略。此外，要理解 URP 指標所代表的含義需要相當的知識。因此，我們不再建議使用 URP 進行警示，而是建議依賴根據 SLO（Service Level Objective） 的警示來檢測未知問題。

穩定的 URP 值

如果叢集中許多代理報告的 URP 值保持穩定（不變），通常意味著其中一個代理處於離線狀態。整個叢集中的 URP 總數將等於分配給該離線代理的分割區數量，而該離線代理本身不會報告任何指標。此時，需要調查該代理發生了什麼問題並解決它，通常是硬體故障，但也可能是作業系統或 Java 相關的問題。

如何處理 URP

要處理 URP，首先需要檢查是否有代理離線，並調查原因。如果是硬體故障，需要修復或更換硬體。如果是其他原因導致的問題，需要根據具體情況進行處理。同時，監控 URP 指標可以幫助及時發現叢集中的潛在問題，從而提高叢集的穩定性和可靠性。

// 範例程式碼：監控 URP 指標
public class KafkaMonitor {
    public static void main(String[] args) {
        // 初始化 Kafka 管理客戶端
        AdminClient adminClient = AdminClient.create(KafkaProperties.config);

        // 取得所有主題的分割槽資訊
        Map<String, TopicDescription> topics = adminClient.describeTopics(Arrays.asList("topic1", "topic2")).all().get();

        // 遍歷每個主題的分割槽
        for (TopicDescription topic : topics.values()) {
            for (TopicPartitionInfo partition : topic.partitions()) {
                // 檢查每個分割槽的副本是否同步
                if (!isPartitionReplicated(adminClient, topic.name(), partition.partition())) {
                    System.out.println("發現未同步分割區：" + topic.name() + "-" + partition.partition());
                }
            }
        }
    }

    // 檢查指定主題和分割槽是否已同步
    private static boolean isPartitionReplicated(AdminClient adminClient, String topic, int partition) {
        // 取得分割槽的詳細資訊，包括副本狀態
        DescribeLogDirsResult logDirsResult = adminClient.describeLogDirs(Arrays.asList(0)); // 假設 brokerId 為 0
        // 省略具體實作細節...
        return true; // 如果已同步傳回 true，否則傳回 false
    }
}

內容解密：

1. 初始化 Kafka 管理客戶端：使用 AdminClient.create() 方法建立與 Kafka 叢集的管理客戶端連線。
2. 取得主題分割槽資訊：透過 describeTopics() 方法取得指定主題的分割槽描述資訊。
3. 遍歷分割槽並檢查同步狀態：對每個分割槽呼叫 isPartitionReplicated() 方法檢查其副本是否已同步。
4. 檢查分割槽同步狀態：在 isPartitionReplicated() 方法中，透過 describeLogDirs() 方法取得分割槽的日誌目錄資訊，以判斷副本是否已同步。
5. 輸出未同步分割區資訊：如果發現未同步分割區，則輸出相應的主題和分割槽資訊，以便進一步處理。