開始使用 Kafka 用戶端度量值

使用 Kafka，監視通常涉及與主題、分割區、分配管理系統及消費者群組相關的各種度量值。 標準 Kafka 度量值包括傳輸量、延遲時間、抄寫及磁碟使用情形的相關資訊。 請參閱 Kafka 說明文件 及相關監視工具，以瞭解 Kafka 版本可用的特定度量值，以及如何有效地解譯它們。

為何監視 Kafka 用戶端很重要?

監視 Event Streams 實例對於確保資料管線的最佳功能及整體性能至關重要。 監視 Kafka 用戶端有助於識別應用程式失敗的早期跡象，例如高資源用量、落後消費者及瓶頸。 及早識別這些警告跡象可讓您主動回應潛在問題，將停機時間減至最少，並防止業務運作中斷。

Kafka 用戶端 (生產者及消費者) 具有自己的一組度量值，可監視其效能及性能。 此外，Event Streams 服務還支援由伺服器產生的一組豐富的度量值。 如需相關資訊，請參閱 使用 IBM Cloud Monitoring監視 Event Streams 服務度量值。

要監視的用戶端度量值

生產者度量值

生產者指標
度量 說明
記錄錯誤率 此度量測量每秒傳送導致錯誤的平均記錄數。 高 record-error-rate 或 record-error-rate 增加可能表示遺失資料或未如預期般處理資料。 所有這些影響可能會危及您正在 Kafka中處理及儲存之資料的完整性。 監視此度量值有助於確保生產者所傳送的資料準確且可靠地記錄在 Kafka 主題中。
request-latency-avg 這是每一個產生要求的平均延遲 (毫秒)。延遲增加會影響效能，並可能表示有問題。 測量 request-latency-avg 度量值有助於識別實例中的瓶頸。 對於許多應用程式而言，低延遲是確保高品質使用者體驗的關鍵，而 request-latency-avg 中的尖峰可能表示您已達到所佈建實例的限制。 您可以透過變更生產者設定 (例如，透過批次處理或調整計劃以最佳化效能) 來修正問題。
位元組速率 主題的每秒平均傳送位元組數是用來測量傳輸量。 如果您定期串流資料，傳輸量下降可能表示 Kafka 實例中發生異常。 Event Streams 企業方案從每秒 150 MB 的入口與出口一對一分割開始，瞭解您為有效產能規劃所耗用的數量非常重要。 請勿超出傳輸量上限的三分之二，以考量作業動作的可能影響，例如內部更新或失敗模式 (例如，失去可用性區域)。

消費者度量值

消費者指標
度量 說明
fetch-rate fetch-size-avg 每秒提取要求數 (fetch-rate) 及每個要求提取的平均位元組數 (fetch-size-avg) 是您的 Kafka 消費者效能表現的關鍵指標。 高 fetch-rate 可能表示效率低下，尤其是在少數訊息上，因為它表示資料不足，或可能每次都沒有收到任何資料。 fetch-rate 和 fetch-size-avg 受三個設定影響: fetch.min.bytes、fetch.max.bytes 和 fetch.max.wait.ms。 調整這些設定以達到所需的整體延遲，同時將提取要求數目及分配管理系統 CPU 上的可能負載降到最低。 監視及最佳化這兩個度量可確保您有效地處理現行及未來工作量的資料。
commit-latency-avg 此度量測量所傳送的已確定記錄與所接收的確定回應之間的平均時間。 類似於 request-latency-avg 作為生產者度量，穩定 commit-latency-avg 表示您的偏移確定及時發生。 高確定延遲可能指出消費者中的問題，使其無法快速確定偏移，這會直接影響資料處理的可靠性。 如果消費者必須重新啟動及重新處理來自先前未確定的偏移的訊息，則可能會導致重複處理訊息。 高確定延遲也表示在管理作業中花費比實際訊息處理更多的時間。 此問題可能會導致等待處理的訊息待辦事項，特別是在大量環境中。
bytes-consumed-rate 這是消費者提取度量值，用來測量每秒所耗用的平均位元組數。 類似於 byte-rate 作為生產者度量，這應該是穩定且預期的度量。 bytes-consumed-rate 的預期趨勢突然變更可能代表您的應用程式有問題。 低速率可能是資料提取或過度供應資源的效率信號。 較高的速率可能會壓倒消費者的處理能力，因此需要調整大小、建立更多消費者以平衡負載，或變更消費者配置 (例如提取大小)。
每小時重新平衡率 每小時參與的群組重新平衡數。 每次有新的消費者時，或當消費者離開群組並導致處理延遲時，就會進行重新平衡。 這是因為已重新指派分割區，如果每小時有大量重新平衡，則會使 Kafka 消費者降低效率。 每小時重新平衡比率較高的原因可能是配置錯誤導致消費者行為不穩定。 此重新平衡動作可能導致延遲增加，並可能導致應用程式當機。 透過追蹤低且穩定的 rebalance-rate-per-hour，確保消費者群組穩定。