Monitora le applicazioni client Kafka

Questo documento descrive come monitorare lo stato dei client che producono o utilizzano i dati nel tuo cluster Managed Service per Apache Kafka.

È importante monitorare le applicazioni client nell'ambito della strategia di affidabilità complessiva. Metriche come throughput, tassi di errore e ritardo del consumatore possono indicare se le applicazioni client riscontrano problemi di affidabilità. I problemi potrebbero essere causati dalla configurazione del client, dalla 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 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 attivi) e deviazioni dalle normali operazioni, come picchi di latenza.

Throughput

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

  • Frequenza dei messaggi, per broker e per argomento.
  • Tasso di byte, per broker e per argomento.
  • Tassi di richieste. Un client configurato in modo errato potrebbe inondare i broker con una frequenza elevata di piccole richieste (0-1000 byte per richiesta), riducendo la velocità effettiva.
  • Latenza di richiesta. I picchi di latenza delle richieste del produttore potrebbero segnalare un carico sbilanciato o un problema con la configurazione del client.

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

Tassi di errore delle richieste

La metrica topic_error_count monitora il numero di richieste di recupero e produzione non riuscite sul lato server. Tuttavia, alcune classi di errori non vengono riflesse in questa metrica. Ad esempio:

  • Impostazioni di autorizzazione configurate in modo errato potrebbero impedire a un client di produrre 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 dei consumatori

Il ritardo del consumer misura il ritardo di un client consumer 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 personalizzate

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 lo stato 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}]
  )
)
Throughput: 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}]
    )
  )
)
Throughput: 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 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 nelle 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 del consumer: prime 5 partizioni per ritardo del consumer 
topk(5,
  max by (resource_container, location, cluster_id, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__interval}]
    )
  )
)

Metriche lato client

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

  • Se l'autenticazione o la rete non sono configurate correttamente, i messaggi potrebbero accumularsi nelle code interne del client. Quando le richieste scadono, i messaggi vengono rimessi in coda e ritentati.

  • Se il controllo del flusso è configurato in modo errato, un client potrebbe produrre più messaggi di quanti ne possa inviare il numero allocato di thread. Sebbene il throughput possa essere coerente, un backlog crescente di richieste scade prima di poter essere inviato.

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

I client Java espongono molte metriche tramite Java Management Extensions (JMX). Per saperne di più, consulta la sezione Monitoraggio nella documentazione di Apache Kafka. Se possibile, dai la priorità all'instrumentazione 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 applicazioni client, valuta le seguenti mitigazioni:

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

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

  • Controlla le configurazioni del client per autenticazione, networking e controllo del flusso.

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

  • 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 riassegna le partizioni a broker diversi.

Passaggi successivi