Monitora le applicazioni client Kafka

Questo documento descrive come monitorare l'integrità dei client che producono o consumano dati nel cluster Managed Service per Apache Kafka.

È importante monitorare le applicazioni client nell'ambito della tua strategia di affidabilità complessiva. Metriche come la velocità effettiva, i tassi di errore e il ritardo dei consumer possono indicare se le applicazioni client presentano problemi di affidabilità. I problemi potrebbero essere causati dalla configurazione del client, da una distribuzione non uniforme delle chiavi tra le partizioni o da problemi del cluster che interessano solo una partizione specifica.

Metriche lato server

Sebbene sia utile monitorare direttamente il comportamento del client, le metriche lato server non richiedono alcuna strumentazione aggiuntiva e possono aiutarti a rilevare problemi lato client che influiscono sull'affidabilità.

Le metriche lato server sono particolarmente utili per rilevare squilibri di carico tra i broker (broker caldi) e deviazioni nelle normali operazioni, come i picchi di latenza.

Throughput

Monitora le seguenti metriche di throughput e confrontale con il throughput previsto:

  • Frequenza dei messaggi, per broker e per argomento.
  • Frequenza di byte, per broker e per argomento.
  • Tassi di richieste. Un client configurato in modo errato potrebbe sovraccaricare i broker con un numero elevato di piccole richieste (0-1000 byte per richiesta), riducendo il throughput.
  • Latenza di richiesta. I picchi di latenza delle richieste del producer potrebbero indicare un carico sbilanciato o un problema con la configurazione del client.

Kafka offre metriche di throughput per argomento e per cluster. Queste metriche non hanno sempre gli stessi valori quando vengono aggregate per tutti gli argomenti. Utilizza una metrica aggregata per il monitoraggio e gli avvisi di alto livello e osserva le metriche per argomento quando risolvi i problemi di throughput. Isolare eventuali problemi in broker specifici.

Tassi di errore delle richieste

La metrica topic_error_count monitora il numero di richieste di recupero e produzione non andate a buon fine sul lato server. Tuttavia, alcune classi di errore non sono incluse in questa metrica. Ad esempio:

  • Impostazioni di autorizzazione configurate in modo errato potrebbero impedire a un client di produrre in un argomento, senza che l'errore venga visualizzato in questa metrica.

  • Gli errori del cluster potrebbero impedire a un broker di rispondere alle richieste.

Per questo motivo, devi monitorare anche gli errori lato client, inclusi gli errori di timeout della richiesta.

Ritardo del consumer

Il ritardo del consumer misura quanto un client consumer è indietro rispetto a un determinato offset. L'aggregazione di questa metrica per argomento, partizione e broker è utile per determinare se il ritardo è dovuto a broker o partizioni specifici.

Valuta la possibilità di creare un avviso in base al ritardo massimo nel sottoinsieme di argomenti critici per il tuo workload.

Query della dashboard personalizzata

Ti consigliamo di creare dashboard e avvisi personalizzati per monitorare questi indicatori. La tabella seguente mostra le query Prometheus Query Language (PromQL) che puoi utilizzare per monitorare l'integrità del client.

IndicatoreQuery PromQL
Velocità effettiva: frequenze dei messaggi per broker 
sum by (resource_container, location, cluster_id, broker_index) (
  rate(
    {
      "managedkafka.googleapis.com/message_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Velocità effettiva: frequenze dei messaggi per broker per argomento, per i 5 argomenti più grandi 
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}]
    )
  )
)
Velocità effettiva: larghezza di banda per argomento e broker 
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}]
  )
)
Tasso di richieste 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/request_count",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "request"="Produce"
    }[${__interval}]
  )
)
Tasso di richieste, totali del cluster 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_request_count",
      monitored_resource="managedkafka.googleapis.com/Topic",
      "request"="Produce"
    }[${__interval}]
  )
)
Latenza di richiesta 
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}]
  )
)
Conteggi degli errori delle richieste 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Ritardo consumer: prime 5 partizioni per ritardo offset 
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}]
    )
  )
)
Ritardo del consumer: primi 5 gruppi di consumer per ritardo dell'offset 
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}]
    )
  )
)

Metriche lato client

A volte i problemi del client non vengono visualizzati nelle metriche del server. Ad esempio:

  • Se l'autenticazione o il networking non sono configurati correttamente, i messaggi potrebbero accumularsi nelle code interne del client. Quando le richieste scadono, i messaggi vengono inseriti nuovamente in coda e viene eseguito un nuovo tentativo.

  • Se il controllo del flusso non è configurato correttamente, un client potrebbe produrre più messaggi di quelli che il numero di thread allocato può inviare. Anche se la velocità effettiva potrebbe essere costante, un backlog crescente di richieste scade prima che possano essere inviate.

Se i tuoi client vengono eseguiti su Compute Engine, Google Kubernetes Engine o Cloud Run, puoi utilizzare le metriche basate su log in Cloud Monitoring per rilevare tassi di errore elevati nei log. Tuttavia, alcuni client Kafka nascondono le eccezioni che portano a nuovi tentativi prolungati, a meno che non configuri livelli di log più elevati. Pertanto, devi anche monitorare l'aumento delle latenze delle richieste.

I client Java espongono molte metriche tramite Java Management Extensions (JMX). Per saperne di più, consulta Monitoraggio nella documentazione di Apache Kafka. Se possibile, dai la priorità alla strumentazione dei client per generare report sulle seguenti metriche:

  • Tassi di errore delle richieste (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • Latenza media delle richieste (kafka.producer:type=producer-metrics,client-id="{client-id}")

Se possibile, invia queste metriche a una soluzione di monitoraggio. Se riesci a connetterti alle porte JMX sulle macchine che eseguono le istanze client, puoi anche leggere queste metriche in modo interattivo.

Mitigazioni

Se riscontri problemi nelle tue applicazioni client, prendi in considerazione le seguenti mitigazioni:

  • Cerca un carico sbilanciato tra i broker (broker caldi). Assicurati che il bilanciamento automatico sia attivato nel cluster.

  • Se il tasso di richieste sembra insolitamente elevato, controlla se il client sta inviando un numero elevato di richieste di piccole dimensioni. Controlla le configurazioni di max.request.size e batch.size sul producer.

  • Controlla le configurazioni del client per l'autenticazione, il networking e il controllo di flusso.

  • Un ritardo eccessivo in tutti gli argomenti o le partizioni di un cluster potrebbe indicare che il cluster è sovraccarico e deve essere sottoposto a scale up.

  • Un ritardo eccessivo in tutti gli argomenti o le partizioni di un broker potrebbe indicare che il broker è sovraccarico. Prova a migliorare la distribuzione delle chiavi o a riassegnare le partizioni a broker diversi.

Passaggi successivi

Apache Kafka® è un marchio registrato di Apache Software Foundation o delle sue società affiliate negli Stati Uniti e/o in altri paesi.