Kafka 生產者與消費者效能取決於多項指標，理解這些指標才能有效調校。生產者端包含整體、單一 Broker 與主題層級的指標，例如訊息佇列時間與請求延遲，能幫助調整引數如 linger.ms 和 batch.size。消費者端則包含 Fetch 管理器、主題、Broker 和協調器等導向的指標，例如擷取延遲與群組同步時間，可用於診斷效能瓶頸。此外，監控消費者延遲和訊息處理量，搭配外部工具如 Burrow，能更全面掌握消費者狀態。
Kafka 生產者與消費者指標詳解
Kafka 的生產者和消費者客戶端提供了多種指標，用於監控和除錯應用程式的效能。這些指標可以幫助開發人員瞭解生產者和消費者的行為，並對系統進行最佳化。
生產者指標
Kafka 生產者客戶端將多個指標整合到幾個指標 Bean 中。這些指標刪除了延遲的百分位數和速率的移動平均值，這些在棄用的 Scala 生產者中存在。生產者的指標主要分為三類別：整體生產者指標、每個 Broker 的指標和每個主題的指標。
整體生產者指標
整體生產者指標提供了生產者的整體效能資料，例如 record-queue-time-avg，它表示訊息在生產者緩衝區中等待的時間平均值。這個指標對於調整生產者的 linger.ms 和 batch.size 組態以滿足應用程式的延遲需求非常有幫助。
每個 Broker 的指標
每個 Broker 的生產者指標提供了與每個 Kafka Broker 連線的效能資料。最有用的指標是 request-latency-avg，它表示向 Broker 傳送請求的平均延遲。這個指標相對穩定，可以幫助識別與特定 Broker 的連線問題。
每個主題的指標
每個主題的生產者指標提供了每個主題的效能資料，例如 record-send-rate 和 record-error-rate。這些指標可以幫助隔離特定主題的訊息丟失或錯誤問題。
消費者指標
Kafka 消費者客戶端同樣提供了多種指標，用於監控和除錯消費者的效能。消費者的指標主要分為幾類別：整體消費者指標、Fetch 管理器指標、每個主題的指標、每個 Broker 的指標和協調器指標。
Fetch 管理器指標
Fetch 管理器指標提供了消費者的主要效能資料，例如 fetch-latency-avg，它表示從 Broker 擷取訊息的平均延遲。這個指標對於監控消費者的效能非常有幫助，但需要注意的是，它受到 fetch.min.bytes 和 fetch.max.wait.ms 組態的影響。
監控消費者延遲
監控消費者延遲（Consumer Lag）是非常重要的。消費者延遲表示消費者當前處理的偏移量與 Broker 的日誌尾偏移量之間的差異。雖然 records-lag-max 屬性可以提供某個分割槽的延遲資訊，但它只反映了一個分割槽的情況，並且依賴於消費者的正常運作。因此，建議使用外部延遲監控工具來監控消費者延遲。
監控消費者的訊息處理量
監控消費者的訊息處理量，例如 bytes-consumed-rate 和 records-consumed-rate，可以幫助瞭解消費者的工作負載。然而，需要謹慎設定這些指標的警示閾值，因為消費者的處理量取決於生產者的工作狀態。
Kafka消費者客戶端效能監控與調優
Kafka消費者客戶端提供了豐富的指標（metrics）來幫助使用者監控和最佳化消費者的效能。這些指標涵蓋了從取得請求到分割槽分配的多個方面。
取得管理器指標
取得管理器（fetch manager）是消費者客戶端的一個重要元件，負責管理從Kafka broker取得訊息的過程。它提供了多個指標來幫助使用者瞭解消費者的效能。
- fetch-rate：每秒取得請求的數量，反映了消費者的活躍程度。
- fetch-size-avg：平均每次取得請求的大小（以位元組為單位），有助於瞭解消費者的資料吞吐量。
- records-per-request-avg：平均每次取得請求中的訊息數量，這個指標與
fetch-size-avg結合使用，可以推斷出訊息的平均大小。
值得注意的是，消費者客戶端沒有提供直接的 record-size-avg 來顯示訊息的平均大小，需要透過其他指標推斷。
每Broker和每主題指標
消費者客戶端還為每個broker連線和每個被消費的主題提供了指標。這些指標對於除錯消費問題非常有用。
- request-latency-avg：由每broker的指標bean提供，反映了請求的平均延遲時間。
- incoming-byte-rate 和 request-rate：將取得管理器的指標分解為每個broker的位元組每秒和請求每秒，有助於隔離與特定broker的連線問題。
- bytes-consumed-rate、records-consumed-rate 和 fetch-size-avg：對於多主題消費非常有用，分別顯示了每個主題每秒消耗的位元組數、訊息數以及每次取得請求的平均大小。
消費者協調器指標
消費者協調器（consumer coordinator）負責管理消費者群組（consumer group）的協調活動，包括組成員的管理、心跳訊息的傳送等。
- sync-time-avg：反映了群組同步操作的平均耗時（毫秒），這是消費者群組重新平衡（rebalance）時的關鍵指標。
- sync-rate：每秒發生的群組同步次數，對於穩定的消費者群組，這個值應該大部分時間為零。
- commit-latency-avg：偏移量提交（offset commit）的平均延遲時間，這是一個類別似於生產者請求延遲的指標。
- assigned-partitions：顯示了消費者客戶端被分配到的分割槽數量，有助於監控消費者群組內的負載平衡。
配額（Quotas）與限流
Kafka允許對客戶端請求進行限流，以防止單個客戶端過載整個叢集。這個功能透過設定每個客戶端ID到每個broker的位元組每秒速率來實作。
- 需要監控的指標包括
fetch-throttle-time-avg和produce-throttle-time-avg，分別對應消費者和生產者的限流情況。 - 即使目前未啟用配額，監控這些指標也是一種好的做法，因為它們可能在未來被啟用。
延遲監控（Lag Monitoring）
監控消費者的延遲情況是確保資料及時處理的關鍵。雖然本文未詳細展開，但監控延遲是Kafka維運中的一個重要方面。
內容解密：
本篇文章全面介紹了Kafka消費者客戶端的各種效能指標，包括取得管理器、每Broker和每主題、以及消費者協調器的指標。同時，也討論了Kafka的配額機制及其監控方法。這些知識對於有效地監控和最佳化Kafka叢集至關重要。
Kafka 監控的重要性與實踐方法
在管理 Apache Kafka 叢集時，監控是一項至關重要的任務。這不僅能確保資料流的連續性，還能幫助我們及時發現並解決潛在的問題。本篇文章將探討 Kafka 監控的各個方面，包括消費者延遲監控、端對端監控以及相關的最佳實踐。
消費者延遲監控
對於 Kafka 消費者來說，最重要的監控指標是消費者延遲（consumer lag）。它是指某個分割槽中最後生成的一條訊息與消費者最後處理的訊息之間的差異。雖然消費者客戶端本身提供了延遲指標，但由於它只代表具有最大延遲的單一分割槽，因此不能準確反映消費者的整體延遲狀況。此外，如果消費者出現故障或離線，這個指標將不準確或無法取得。
使用外部監控系統
為了獲得更客觀的監控結果，建議使用外部監控流程來跟蹤分割槽在代理伺服器上的狀態，以及消費者的最後提交偏移量。這種方法可以提供獨立於消費者狀態的監控視角。
Burrow：一個優秀的監控工具
Burrow 是由 LinkedIn 開源的一個應用程式，專門用於監控 Kafka 消費者的狀態。它能夠收集所有消費者群組的延遲資訊，並計算出每個群組的狀態，如是否正常運作、是否落後或完全停止。Burrow 的一大優勢是無需設定門檻值，而是透過監控消費者群組處理訊息的進度來評估其狀態。
端對端監控
除了消費者延遲監控之外，端對端監控也是評估 Kafka 叢集健康狀況的重要手段。這種監控方式能夠從客戶端的角度來評估 Kafka 叢集的可達性和效能。透過持續地向 Kafka 叢集生成和消費資料，我們可以測量每個代理伺服器的可用性，以及整體的生成到消費延遲。
Xinfra Monitor：一個實用的端對端監控工具
Xinfra Monitor（前身為 Kafka Monitor）是由 LinkedIn 的 Kafka 團隊開源的一個工具。它能夠持續地在一個跨所有代理伺服器的主題上生成和消費資料，從而測量每個代理伺服器的生成和消費請求的可用性，以及整體的延遲。
資料流處理
Kafka 最初被視為一個強大的訊息匯流排，能夠傳遞事件流但缺乏處理或轉換能力。隨著 Apache Kafka 的日益流行，許多公司擁有了一個包含許多有趣資料流的系統，這些資料流儲存時間長且順序完美，只是等待某個資料流處理框架出現並對其進行處理。
Kafka Streams：內建的資料流處理函式庫
從版本 0.10.0 開始，Kafka 不僅提供可靠的資料流來源給每個流行的資料流處理框架，還包含了一個強大的資料流處理函式庫，稱為 Kafka Streams（或有時稱為 Streams API）。這使得開發人員能夠在自己的應用程式中消費、處理和生成事件，而無需依賴外部處理框架。
資料流處理的新時代
Kafka Streams 的出現標誌著資料流處理進入了一個新的時代。開發人員現在可以利用 Kafka 強大的資料處理能力，在不依賴外部框架的情況下實作複雜的資料流處理任務。這不僅簡化了架構，還提高了資料處理的效率和可靠性。
串流處理簡介
串流處理（Stream Processing）是一個快速發展且引人入勝的領域，涵蓋了資料架構、軟體工程等多個導向。本章節旨在對串流處理和 Kafka Streams 進行初步介紹，並探討其基本概念、設計模式以及應使用案例項。
什麼是串流處理？
串流處理是一種處理無界資料集（unbounded dataset）的技術。無界資料集是指資料會持續不斷地到達，永無止境。這種定義被廣泛接受，包括 Google、Amazon 等多家知名企業。
資料串流的特性
- 無界性：資料串流是無窮無盡的，新資料會持續到達。
- 有序性：事件之間存在先後順序，這對於某些應用（如金融交易）至關重要。
- 不可變性：事件一旦發生，就不能被修改。若要取消或更正某個事件，會透過新增另一個事件來記錄。
- 可重播性：資料串流應該能夠被重播，這對於錯誤修正、稽核和嘗試新的分析方法非常重要。
這些特性使得資料串流能夠代表各種商業活動，如信用卡交易、股票交易、包裹遞送等。幾乎所有的活動都可以被視為一系列事件的序列。
為何 Kafka Streams 如此成功？
Apache Kafka 之所以能夠使串流處理在現代商業中取得成功，其中一個關鍵原因是它能夠捕捉並重播事件串流。沒有這種能力，串流處理可能只會停留在實驗室階段，無法在實際業務中發揮作用。
進一步閱讀
對於想要深入瞭解串流處理和 Kafka Streams 的讀者，可以參考以下書籍：
- Making Sense of Stream Processing by Martin Kleppmann
- Streaming Systems by Tyler Akidau, Slava Chernyak, and Reuven Lax
- Flow Architectures by James Urquhart
- Mastering Kafka Streams and ksqlDB by Mitch Seymour
- Kafka Streams in Action by William P. Bejeck Jr.
- Event Streaming with Kafka Streams and ksqlDB by William P. Bejeck Jr.
- Stream Processing with Apache Flink by Fabian Hueske and Vasiliki Kalavri
- Stream Processing with Apache Spark by Gerard Maas and Francois Garillot
這些資源將有助於讀者更全面地理解串流處理的概念、技術和實踐應用。
內容解密：
本章節首先對串流處理的概念進行了解釋，接著介紹了 Kafka Streams 的基本架構和應用，最後推薦了一些相關書籍供讀者深入學習。整體而言，本章節為讀者提供了一個關於串流處理和 Kafka Streams 的全面概述。
隨著大資料和實時分析需求的不斷增長，串流處理技術將繼續扮演重要角色。未來，我們可以期待看到更多創新性的串流處理框架和應用案例出現。
內容解密：
本段落對串流處理的未來發展進行了簡要展望，強調了其在實時分析和大資料領域的重要性，並預期將會有更多相關的創新和應用出現。
事件流與串流處理的基礎概念
事件流（Event Streams）是指由無限且連續的事件（Events）所組成的資料集合。這些事件可能來自不同的來源，例如使用者行為、日誌記錄、感測器資料等。事件流的特性在於其資料是無界的（unbounded），且可能以不同的速率抵達，例如每秒數百萬筆事件或每分鐘僅有幾筆事件。事件流中的資料型態多樣，可能包含非結構化的鍵值對、半結構化的JSON，或是結構化的Avro或Protobuf訊息。
串流處理的定義
串流處理（Stream Processing）是一種持續處理一個或多個事件流的程式設計正規化。它填補了請求-回應（Request-Response）和批次處理（Batch Processing）之間的空白。請求-回應模式著重於低延遲的互動，通常用於即時交易處理；而批次處理則適用於高延遲、高吞吐量的場景，例如每日資料倉儲更新。串流處理則提供了一種連續且非阻塞的處理方式，適合用於需要即時更新但不需要毫秒級回應的業務流程。
不同程式設計正規化的比較
請求-回應（Request-Response）：這是一種最低延遲的正規化，回應時間通常在毫秒以內，處理模式通常是阻塞式的，使用者端傳送請求並等待伺服器回應。典型的應用包括銷售點系統、信用卡處理和時間追蹤系統。
批次處理（Batch Processing）：這是一種高延遲、高吞吐量的選項，處理系統按照預定的時間排程執行，讀取所需的輸入資料，寫入輸出結果後停止，直到下一次排程執行。常見於資料倉儲和商業智慧系統，資料以大批次載入，生成報告後使用者檢視相同的報告直到下一次資料載入。
串流處理（Stream Processing）：這是一種連續且非阻塞的選項，適合於大多數業務流程，這些流程不需要即時回應，但也不能等待太久。串流處理能夠持續更新業務報告，並讓業務應用程式持續回應，而不需要等待特定的毫秒級回應。典型的應用包括即時監控可疑交易、根據供需動態調整價格，或是追蹤包裹遞送狀態。
串流處理的核心概念
串流處理應用程式涉及多個核心概念，包括：
拓撲（Topology）：串流處理應用程式包含一個或多個處理拓撲，拓撲由一個或多個源串流開始，透過一系列的事件串流連線不同的串流處理器，最終將結果寫入一個或多個接收串流。每個串流處理器都對事件流進行某種運算，例如篩選、計數、分組或連線操作。
時間（Time）：時間是串流處理中最重要的概念之一，尤其是在涉及時間視窗的操作時。串流處理系統通常涉及多種時間概念，包括：
- 事件時間（Event Time）：事件發生的時間，即記錄建立的時間。例如測量資料的時間、商品銷售的時間或使用者瀏覽網頁的時間。
內容解密：
在串流處理中，正確理解和處理時間概念至關重要，因為大多數應用程式需要根據事件的時間戳記進行聚合運算，如計算過去五分鐘的股票價格平均值。當生產者因網路問題離線並在稍後重新上線，可能會導致大量歷史資料湧入，這些資料可能已經過了原本應該被處理的時間視窗，因此需要妥善處理以確保結果的正確性。
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 內容解密：
rectangle "事件" as node1
rectangle "過濾後事件" as node2
rectangle "統計結果" as node3
node1 --> node2
node2 --> node3
@enduml
此圖示展示了一個簡單的串流處理拓撲，從源串流開始，經過篩選和計數操作，最終將結果寫入輸出串流。
時間語意在串流處理中的重要性
在串流處理中，時間是一個非常重要的概念。不同的時間語意會對串流處理的結果產生不同的影響。Kafka Streams 提供了三種主要的時間語意：事件時間（Event Time）、日誌附加時間（Log Append Time）和處理時間（Processing Time）。
事件時間（Event Time）
事件時間是指事件實際發生的時間。這通常是串流處理中最重要的時間，因為它代表了事件的實際發生順序。例如，在計算每天的裝置生產數量時，我們希望計算的是當天實際生產的裝置數量，而不是事件到達 Kafka 的時間。
在 Kafka 0.10.0 及以後版本中，Kafka 會自動為生產者記錄新增當前時間作為事件時間。如果這個時間與應用程式的事件時間概念不符，例如 Kafka 記錄是根據資料函式庫記錄建立的，那麼建議將事件時間作為欄位新增到記錄中，以便後續處理可以使用這兩個時間戳。
日誌附加時間（Log Append Time）
日誌附加時間是指事件到達 Kafka 代理（Broker）並被儲存的時間，也稱為攝取時間（Ingestion Time）。在 Kafka 0.10.0 及以後版本中，如果 Kafka 組態為這樣做，或者記錄來自舊版本的生產者且不包含時間戳，那麼 Kafka 代理會自動為收到的記錄新增這個時間。
這個時間語意通常對於串流處理的相關性較低，因為我們通常更關心事件發生的時間。然而，在沒有記錄實際事件時間的情況下，日誌附加時間仍然可以被一致地使用，因為它在記錄建立後不會改變。假設管道中沒有延遲，它可以是事件時間的合理近似值。
處理時間（Processing Time）
處理時間是指串流處理應用程式接收到事件以進行某些計算的時間。這個時間可能在事件發生後的幾毫秒、幾小時或幾天後。不同的串流處理應用程式，甚至是同一個應用程式中的不同執行緒，都可能為同一個事件分配不同的時間戳。因此，這個時間語意是高度不可靠的，最好避免使用。
時間語意的實作
Kafka Streams 根據 TimestampExtractor 介面為每個事件分配時間。開發人員可以使用這個介面的不同實作來選擇使用上述三種時間語意中的任意一種，或者完全不同的時間戳選擇，包括從事件內容中提取時間戳。
當 Kafka Streams 將輸出寫入 Kafka 主題時，它根據以下規則為每個事件分配時間戳：
- 當輸出記錄直接對映到輸入記錄時，輸出記錄將使用與輸入記錄相同的時間戳。
- 當輸出記錄是聚合的結果時，輸出記錄的時間戳將是聚合過程中使用的最大時間戳。
- 當輸出記錄是連線兩個串流的結果時，輸出記錄的時間戳是被連線的兩個記錄中較大的那個。當串流和表格被連線時，使用串流記錄的時間戳。
- 如果輸出記錄是由 Kafka Streams 函式按照特定排程生成的資料，例如
punctuate()，則輸出時間戳將取決於串流處理應用程式的當前內部時間。