Introduzione alle metriche del client Kafka

Con Kafka, il monitoraggio in genere coinvolge diverse metriche correlate ad argomenti, partizioni, broker e gruppi di consumatori. Le metriche Kafka standard includono informazioni su velocità effettiva, latenza, replica e utilizzo del disco. Fai riferimento alla documentazioneKafka e agli strumenti di monitoraggio pertinenti per comprendere le metriche specifiche disponibili per la tua versione di Kafka e come interpretarle in modo efficace.

Perché è importante monitorare client Kafka ?

Il monitoraggio della tua istanza Event Streams è fondamentale per garantire la funzionalità ottimale e l'integrità generale della tua pipeline di dati. Il controllo dei tuoi clienti Kafka aiuta a identificare i primi segni di errore dell'applicazione, come l'elevato utilizzo delle risorse, i consumatori in ritardo e i colli di bottiglia. L'identificazione tempestiva di questi segnali di allarme consente una risposta proattiva a potenziali problemi che riducono al minimo i tempi di inattività e prevengono eventuali interruzioni delle operazioni di business.

I clienti Kafka (produttori e consumatori) hanno la propria serie di metriche per monitorare le loro prestazioni e la loro integrità. Inoltre, il servizio Event Streams supporta una serie completa di metriche prodotte dal server. Per ulteriori informazioni, vedi le metriche del servizio Monitoraggio Event Streams utilizzando IBM Cloud Monitoring.

Metriche client da monitorare

Metriche produttore

Metriche del produttore
Metrica Descrizione
tasso di errore record Questa metrica misura il numero medio al secondo di record inviati che hanno generato errori. Un valore elevato di record-error-rate o un aumento di record-error-rate potrebbe indicare una perdita di dati o di dati non elaborati come previsto. Tutti questi effetti potrebbero compromettere l'integrità dei dati che stai elaborando e archiviando in Kafka. Il monitoraggio di questa metrica ti aiuta a garantire che i dati inviati dai produttori siano registrati in modo accurato e affidabile nei tuoi argomenti Kafka.
richiesta - latenza - media Questa è la latenza media per ogni richiesta di produzione in ms. Un aumento della latenza influenza le prestazioni e potrebbe segnalare un problema. La misurazione della metrica request-latency-avg può aiutare a identificare i colli di bottiglia nella tua istanza. Per molte applicazioni, una bassa latenza è fondamentale per assicurare un'esperienza utente di alta qualità e un picco in request-latency-avg potrebbe indicare che stai raggiungendo i limiti della tua istanza di cui è stato eseguito il provisioning. Puoi risolvere il problema modificando le tue impostazioni del produttore, ad esempio, raggruppando o ridimensionando il piano per ottimizzare le prestazioni.
frequenza byte Il numero medio di byte inviati al secondo per un argomento è una misurazione della velocità di trasmissione. Se trasmetti regolarmente i dati, un calo della velocità di trasmissione può indicare un'anomalia nella tua istanza Kafka. Il piano Enterprise Event Streams inizia da 150 MB al secondo suddivisi uno a uno tra ingresso e uscita ed è importante sapere quanto di ciò si sta consumando per una pianificazione della capacità efficace. Non superare i due terzi della velocità effettiva massima, per tenere conto del possibile impatto delle azioni operative, come gli aggiornamenti interni o le modalità di errore (ad esempio, la perdita di una zona di disponibilità).

Metriche consumatore

Metriche dei consumatori
Metrica Descrizione
fetch - rate fetch - size - avg Il numero di richieste di richiamo al secondo (fetch-rate) e il numero medio di byte richiamati per richiesta (fetch-size-avg) sono indicatori chiave per la qualità delle prestazioni dei tuoi consumer Kafka. Un fetch-rate elevato potrebbe segnalare un'inefficienza soprattutto su un numero ridotto di messaggi, perché significa che i dati non sono sufficienti o che non vengono ricevuti ogni volta. fetch-rate e fetch-size-avg sono interessati da tre impostazioni: fetch.min.bytes, fetch.max.bytes e fetch.max.wait.ms. Ottimizzare queste impostazioni per ottenere la latenza complessiva desiderata, riducendo il numero di richieste di richiamo e potenzialmente il carico sulla CPU del broker. Il monitoraggio e l'ottimizzazione di entrambe le metriche garantisce l'elaborazione efficiente dei dati per i carichi di lavoro correnti e futuri.
media - latenza - commit Questa metrica misura il tempo medio tra l'invio di un record con commit e la ricezione della risposta di commit. In modo simile a request-latency-avg come metrica del produttore, un commit-latency-avg stabile significa che i commit di offset avvengono in modo tempestivo. Una latenza di commit elevata potrebbe indicare problemi nel consumer che impediscono di eseguire rapidamente il commit degli offset, il che influisce direttamente sull'affidabilità dell'elaborazione dei dati. L'elaborazione dei messaggi potrebbe essere duplicata se un utente deve riavviare ed elaborare nuovamente i messaggi da un offset precedentemente non sottoposto a commit. Una latenza di commit elevata significa anche dedicare più tempo alle operazioni amministrative rispetto all'elaborazione effettiva dei messaggi. Questo problema potrebbe portare a backlog di messaggi in attesa di essere elaborati, soprattutto in ambienti con volumi elevati.
byte - consumati - velocità Questa è una metrica consumer - fetch che misura il numero medio di byte utilizzati al secondo. Simile a byte-rate come metrica del produttore, questa dovrebbe essere una metrica stabile e prevista. Una modifica improvvisa nell'andamento previsto di bytes-consumed-rate potrebbe rappresentare un problema con le applicazioni. Una frequenza bassa potrebbe essere un segnale di efficienza nei recuperi di dati o nelle risorse con over - provisioning. Una velocità più elevata potrebbe sovraccaricare la capacità di elaborazione dei consumer e quindi richiedere la scalabilità, creando più consumer per bilanciare il carico o modificando le configurazioni dei consumer, come ad esempio le dimensioni di recupero.
ribilanciamento - velocità - per - ora Il numero di ribilanciamenti di gruppo che hanno partecipato all'ora. Il ribilanciamento si verifica ogni volta che c'è un nuovo consumatore o quando un consumatore lascia il gruppo e causa un ritardo nell'elaborazione. Ciò si verifica perché le partizioni vengono riassegnate, il che rende i consumatori Kafka meno efficienti se ci sono molti ribilanciamenti all'ora. Un tasso di ribilanciamento più elevato all'ora potrebbe essere causato da configurazioni errate che portano a un comportamento instabile del cliente. Questo ribilanciamento potrebbe causare un aumento della latenza e potrebbe causare l'arresto anomalo delle applicazioni. Assicurarsi che i gruppi di consumatori siano stabili tenendo traccia di un rebalance-rate-per-hour basso e stabile.