本文說明如何監控 Managed Service for Apache Kafka 叢集中，產生或使用資料的用戶端健康狀態。
監控用戶端應用程式是整體可靠性策略的重要一環。處理量、錯誤率和消費者延遲等指標，可讓您瞭解用戶端應用程式是否發生可靠性問題。問題可能是由用戶端設定、分區間金鑰分布不均，或僅影響特定分區的叢集問題所造成。
伺服器端指標
雖然直接監控用戶端行為很有用，但伺服器端指標不需要任何額外的檢測，而且可以協助您偵測影響可靠性的用戶端問題。
伺服器端指標特別適合用來偵測代理程式之間的負載不平衡 (熱門代理程式)，以及正常作業中的偏差，例如延遲時間激增。
處理量
監控下列處理量指標，並與預期處理量比較：
- 訊息速率：每個代理和主題的訊息速率。
- 位元組速率：每個代理程式和主題。
- 要求比率。如果用戶端設定錯誤，可能會以高頻率向代理程式傳送大量小型要求 (每個要求 0 到 1000 個位元組)，導致處理量降低。
- 要求延遲時間。如果生產者要求延遲時間激增，可能代表負載不平衡或用戶端設定有問題。
Kafka 提供各主題和叢集的處理量指標。匯總所有主題時，這些指標的值不一定相同。使用匯總指標進行高階監控和快訊，並在排解處理量問題時查看各主題指標。找出特定代理程式的問題。
要求錯誤率
topic_error_count 指標會追蹤伺服器端擷取和產生要求失敗的次數。不過，這項指標不會反映某些類型的錯誤。例如：
如果授權設定錯誤，用戶端可能無法產生主題，且這項指標不會顯示錯誤。
叢集故障可能會導致代理程式完全無法回應要求。
因此，您也應該監控用戶端錯誤，包括要求逾時錯誤。
消費者落後
消費者延遲時間會評估消費者用戶端與特定偏移量的差距。依主題、分區和代理程式匯總這項指標，有助於判斷延遲是否由特定代理程式或分區造成。
建議您根據對工作負載至關重要的主題子集，依據最大延遲時間建立快訊。
自訂資訊主頁查詢
建議您建立自訂資訊主頁和快訊，監控這些信號。下表列出可用於監控用戶端健康狀態的 Prometheus 查詢語言 (PromQL) 查詢。
| 信號 | PromQL 查詢 |
|---|---|
| 處理量：每個代理的訊息速率 | sum by (resource_container, location, cluster_id, broker_index) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 處理量：每個主題中各個代理程式的訊息速率 (前 5 大主題) | topk(5, sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/message_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) ) |
| 處理量：每個主題和代理程式的頻寬 | sum by (resource_container, location, cluster_id, broker_index, topic_id) ( rate( { "managedkafka.googleapis.com/byte_in_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 要求比率 | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/request_count", monitored_resource="managedkafka.googleapis.com/Cluster", "request"="Produce" }[${__interval}] ) ) |
| 要求比率，叢集總計 | sum by (resource_container, location, cluster_id, request) ( rate( { "managedkafka.googleapis.com/topic_request_count", monitored_resource="managedkafka.googleapis.com/Topic", "request"="Produce" }[${__interval}] ) ) |
| 要求延遲時間 | sum by (resource_container, location, cluster_id, broker_index, request) ( avg_over_time( { "managedkafka.googleapis.com/request_latencies", monitored_resource="managedkafka.googleapis.com/Cluster", "percentile"="95", "request"="Produce" }[${__interval}] ) ) |
| 要求錯誤次數 | sum by (resource_container, location, cluster_id, broker_index, request) ( rate( { "managedkafka.googleapis.com/topic_error_count", monitored_resource="managedkafka.googleapis.com/Topic" }[${__interval}] ) ) |
| 消費者延遲：偏移延遲最高的前 5 個分區 | topk(5, max by (resource_container, location, cluster_id, topic_id, partition_index) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
| 消費者延遲：偏移落後程度最高的前 5 個消費者群組 | topk(5, max by (resource_container, location, cluster_id, consumer_group_id) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
用戶端指標
有時用戶端問題不會顯示在伺服器指標中。例如：
如果驗證或網路設定錯誤，訊息可能會在用戶端的內部佇列中累積。要求逾時後，訊息會重新排入佇列並重試。
如果流量控制設定不正確，用戶端產生的訊息數量可能會超過分配的執行緒可傳送的數量。雖然處理量可能保持穩定，但越來越多待處理的要求會在傳送前過期。
如果用戶端在 Compute Engine、Google Kubernetes Engine 或 Cloud Run 上執行，您可以使用 Cloud Monitoring 中的記錄指標，偵測記錄中的高錯誤率。不過，除非您設定較高的記錄層級，否則某些 Kafka 用戶端會隱藏導致重試時間延長的例外狀況。因此，您也應監控要求延遲時間是否增加。
Java 用戶端會透過 Java Management Extensions (JMX) 公開許多指標。詳情請參閱 Apache Kafka 說明文件的「監控」一節。如果可以，請優先檢測用戶端，回報下列指標：
- 要求錯誤率 (
kafka.producer:type=producer-metrics,client-id="{client-id}") - 要求平均延遲時間 (
kafka.producer:type=producer-metrics,client-id="{client-id}")
如果可以，請將這些指標傳送至監控解決方案。如果您可以連線至執行用戶端執行個體的機器上的 JMX 連接埠，也可以互動方式讀取這些指標。
因應措施
如果用戶端應用程式發生問題，請考慮採取下列緩解措施：
查看代理程式之間的負載是否不平衡 (熱門代理程式)。確認叢集已啟用自動重新平衡功能。
如果要求比率異常偏高，請檢查用戶端是否傳送大量小型要求。請檢查生產者的
max.request.size和batch.size設定。檢查用戶端的驗證、網路和流量控制設定。
如果叢集內所有主題或分區的延遲時間過長，可能代表叢集超載，應向上擴充。
如果代理程式中所有主題或分區的延遲時間過長，可能表示代理程式超載。請嘗試改善金鑰分配，或將分區重新指派給其他代理。