Procedure consigliate per i clienti Apache Kafka

Disponibilità del produttore

• Impostato retries per indicare al produttore di riprovare a inviare messaggi non riusciti durante il failover del broker. Consigliamo un valore intero max o un valore elevato simile per la maggior parte dei casi d'uso. In caso contrario, l'elevata disponibilità di Kafka verrà interrotta.

• Impostato delivery.timeout.ms per specificare il limite superiore per il tempo totale tra l'invio di un messaggio e la ricezione di una conferma dal broker. Ciò dovrebbe riflettere i requisiti aziendali relativi alla durata di validità di un messaggio. Imposta un limite di tempo sufficientemente alto da consentire un numero sufficiente di tentativi per completare l'operazione di failover. Consigliamo un valore pari o superiore a 60 secondi per la maggior parte dei casi d'uso.

• Impostato request.timeout.ms al massimo, una singola richiesta deve attendere prima di tentare un nuovo invio. Consigliamo un valore di 10 secondi o superiore per la maggior parte dei casi d'uso.

• Impostato retry.backoff.ms per configurare il ritardo tra i tentativi per evitare tempeste di tentativi e impatti sulla disponibilità. Consigliamo un valore minimo di 200 ms per la maggior parte dei casi d'uso.

• Impostato acks=all per configurare una durabilità elevata; dovrebbe essere in linea con la configurazione lato server di RF=3 e min.isr=2 per garantire che tutte le partizioni in ISR riconoscano la scrittura. Durante un singolo broker offline, questo è il, cioè. min.isr 2

Disponibilità per i consumatori

• Impostato su latest inizialmente auto.offset.reset per gruppi di consumatori nuovi o ricreati. In questo modo si evita il rischio di aumentare il carico del cluster consumando l'intero argomento.

• Impostato auto.commit.interval.ms durante l'usoenable.auto.commit. Consigliamo un valore minimo di 5 secondi per la maggior parte dei casi d'uso per evitare il rischio di un carico aggiuntivo.

• Implementa la gestione delle eccezioni all'interno del codice di elaborazione dei messaggi del consumatore per gestire gli errori transitori, ad esempio un interruttore automatico o una sospensione con back-off esponenziale. In caso contrario, possono verificarsi arresti anomali dell'applicazione, che possono causare un ribilanciamento eccessivo.

• Imposta isolation.level per controllare come leggere i messaggi transazionali:

  Si consiglia di impostare sempre in read_uncommitted modo implicito per impostazione predefinita. Questo non è presente in alcune implementazioni dei client.

  Si consiglia di impostare il valore di read_uncommitted quando si utilizza lo storage su più livelli.

• Impostato client.rack per utilizzare la replica letta più vicina. Si consiglia di impostare su per ridurre az id al minimo i costi e la latenza del traffico di rete. Consulta Riduci i costi del traffico di rete dei tuoi utenti Amazon MSK con il riconoscimento dei rack.

Ribilanciamento dei consumatori

• Impostato su session.timeout.ms un valore maggiore del tempo di avvio di un'applicazione, incluso qualsiasi jitter di avvio implementato. Consigliamo un valore di 60 secondi per la maggior parte dei casi d'uso.

• Impostato heartbeat.interval.ms per ottimizzare il modo in cui il coordinatore del gruppo considera un consumatore sano. Consigliamo un valore di 10 secondi per la maggior parte dei casi d'uso.

• Imposta un hook di spegnimento nell'applicazione per chiudere in modo corretto il consumatore su SIGTERM, anziché affidarti ai timeout della sessione per identificare quando un consumatore lascia un gruppo. Le applicazioni Kstream possono essere impostate su un valore di. internal.leave.group.on.close true

• Impostato group.instance.id su un valore distinto all'interno del gruppo di consumatori. Idealmente un nome host, task-id o pod-id. Consigliamo di impostarlo sempre per comportamenti più deterministici e una migliore client/server correlazione dei log durante la risoluzione dei problemi.

• Impostato group.initial.rebalance.delay.ms su un valore in linea con il tempo medio di implementazione. Ciò interrompe i ribilanciamenti continui durante l'implementazione.

• Impostato per utilizzare assegnatori partition.assignment.strategy permanenti. Consigliamo uno o. StickyAssignor CooperativeStickyAssignor

Performance del produttore

• Impostato linger.ms per controllare la quantità di tempo che un produttore attende per il riempimento di un batch. I batch più piccoli sono computazionalmente costosi per Kafka in quanto si traducono in più thread e operazioni contemporaneamente. I/O Consigliamo i seguenti valori.

  Un valore minimo di 5 ms per tutti i casi d'uso, inclusa una bassa latenza.

  Consigliamo un valore più alto di 25 ms, per la maggior parte dei casi d'uso.

  Si consiglia di non utilizzare mai un valore pari a zero nei casi d'uso a bassa latenza. (Un valore pari a zero in genere causa latenza indipendentemente dal sovraccarico di I/O).

• Impostato batch.size per controllare la dimensione del batch inviato al cluster. Si consiglia di aumentarlo fino a un valore di 64 KB o 128 KB.

• Impostato buffer.memory quando si utilizzano lotti di dimensioni maggiori. Consigliamo un valore di 64 MB per la maggior parte dei casi d'uso.

• Impostato send.buffer.bytes per controllare il buffer TCP utilizzato per ricevere i byte. Consigliamo un valore di -1 per consentire al sistema operativo di gestire questo buffer quando si esegue un produttore su una rete ad alta latenza.

• Impostate compression.type per controllare la compressione dei batch. Consigliamo lz4 o zstd di far funzionare un producer su una rete ad alta latenza.

Prestazioni dei consumatori

• Impostato fetch.min.bytes per controllare la dimensione minima di recupero da validare per ridurre il numero di recuperi e il carico del cluster.

  Consigliamo un valore minimo di 32 byte per tutti i casi d'uso.

  Consigliamo un valore più alto di 128 byte per la maggior parte dei casi d'uso.

• Impostate fetch.max.wait.ms per determinare quanto tempo il consumatore dovrà attendere prima che fetch.min.bytes venga ignorato. Consigliamo un valore di 1000 ms per la maggior parte dei casi d'uso.

• Consigliamo che il numero di utenti sia almeno uguale al numero di partizioni per migliorare il parallelismo e la resilienza. In alcune situazioni, è possibile scegliere di avere un numero inferiore di utenti rispetto al numero di partizioni per argomenti a bassa velocità effettiva.

• Impostato receive.buffer.bytes per controllare il buffer TCP utilizzato per ricevere i byte. Consigliamo un valore di -1 per consentire al sistema operativo di gestire questo buffer quando si esegue un consumer su una rete ad alta latenza.

Connessioni client

Il ciclo di vita delle connessioni ha un costo di calcolo e di memoria su un cluster Kafka. Troppe connessioni create contemporaneamente causano un carico che può influire sulla disponibilità di un cluster Kafka. Questo impatto sulla disponibilità può spesso portare le applicazioni a creare ancora più connessioni, provocando così un errore a cascata, con conseguente interruzione completa. È possibile ottenere un numero elevato di connessioni se create a una velocità ragionevole.

Consigliamo le seguenti mitigazioni per gestire tassi elevati di creazione di connessioni:

• Assicurati che il meccanismo di distribuzione delle applicazioni non si riavvii producers/consumers contemporaneamente, ma preferibilmente in batch più piccoli.

• A livello di applicazione, lo sviluppatore deve assicurarsi che venga eseguito un jitter casuale (sospensione casuale) prima di creare un client di amministrazione, un client di produzione o un client consumer.

• A SIGTERM, alla chiusura della connessione, dovrebbe essere eseguito uno sleep casuale per garantire che non tutti i client Kafka vengano chiusi contemporaneamente. Il sonno casuale deve avvenire entro il timeout prima che si verifichi SIGKILL.

  Esempio Esempio A (Java)

  sleepInSeconds(randomNumberBetweenOneAndX);
                          this.kafkaProducer = new KafkaProducer<>(this.props);

  Esempio Esempio B (Java)

  Runtime.getRuntime().addShutdownHook(new Thread(() -> {
      sleepInSeconds(randomNumberBetweenOneAndTwentyFive);
      kafkaProducer.close(Duration.ofSeconds(5));
  });

• A livello di applicazione, lo sviluppatore deve assicurarsi che i client vengano creati una sola volta per applicazione secondo uno schema singleton. Ad esempio, quando si utilizza lambda, il client deve essere creato in ambito globale e non nel gestore del metodo.

• Consigliamo di monitorare il conteggio delle connessioni con l'obiettivo di essere stabili. La creation/close connessione/spostamento è normale durante le implementazioni e il failover del broker.

Metriche del produttore

• velocità in byte

• frequenza di invio dei record

• media dei record per richiesta

• acks-latenza-avg

• latenza-richiesta-avg

• latenza massima della richiesta

• tasso di errore da record

• frequenza di ripetizione dei record

• tasso di errore

Metriche relative ai consumatori

• tasso di consumo record

• frequenza di byte consumata

• velocità di recupero

• record-la-max

• tasso di errore da record

• tasso di errore di recupero

• tasso di sondaggio

• ribilanciamento della latenza media

• tasso di impegno

Metriche comuni

• tasso di chiusura della connessione

• velocità di creazione della connessione

• conteggio delle connessioni