Monitorare l'affidabilità dei cluster Kafka

Questo documento descrive come monitorare un cluster Managed Service per Apache Kafka per garantire l'affidabilità dei tuoi carichi di lavoro Kafka.

Panoramica

L'affidabilità è la capacità di un sistema di funzionare correttamente e in modo coerente nel tempo. Per i carichi di lavoro basati su Kafka, l'affidabilità comprende sia i cluster Kafka stessi sia le applicazioni client che producono e consumano messaggi.

Managed Service per Apache Kafka è progettato per tollerare e recuperare da molti errori comuni. Ad esempio, il servizio posiziona le repliche in zone diverse per la tolleranza agli errori e riavvia automaticamente i broker che non funzionano. Tuttavia, altri fattori che influiscono sull'affidabilità non rientrano nel controllo diretto del servizio, ad esempio:

  • Configurazione client
  • Carico sul cluster, inclusi carico medio e picchi
  • Il numero di partizioni e repliche
  • Configurazioni degli argomenti, ad esempio la conservazione dei messaggi

Per ottenere operazioni affidabili, è importante monitorare il cluster per questi parametri operativi e mantenerli entro gli intervalli consigliati. Le sezioni seguenti descrivono alcune metriche chiave importanti per l'affidabilità.

Monitorare la capacità del cluster

Per evitare di sovraccaricare un cluster, monitora i seguenti indicatori. Crea avvisi per ricevere una notifica se i valori non rientrano nell'intervallo consigliato per un periodo prolungato.

  • Utilizzo CPU. Cerca di mantenere l'utilizzo della CPU al di sotto dell'80% su tutti i broker.

  • Utilizzo del disco del broker: assicurati che l'utilizzo del disco del broker rimanga inferiore all'80%.

  • Dimensione disco. Come punto di partenza sicuro, ti consigliamo di avere almeno 2*(segment.bytes) per partizione per broker. In pratica, i requisiti effettivi del disco sono spesso notevolmente inferiori.

    Per impostazione predefinita, un file di segmento viene chiuso e spostato nello spazio di archiviazione remoto dopo 7 giorni. È normale che la maggior parte delle partizioni riceva meno di segment.bytes di dati in questo periodo, il che significa che la maggior parte delle partizioni utilizza meno di segment.bytes di spazio su disco. Prima di aumentare le dimensioni del disco, monitora l'utilizzo del disco man mano che crei più partizioni sul cluster.

  • Conteggio partizioni. Cerca di mantenere meno di 4000 partizioni per broker e meno di 100.000 partizioni per cluster.

Se il tuo cluster ha una capacità ridotta, valuta le seguenti mitigazioni:

La tabella seguente mostra le query Prometheus Query Language (PromQL) per queste metriche che puoi aggiungere a una dashboard di Cloud Monitoring personalizzata.

IndicatoreQuery PromQL
Utilizzo CPU 
rate(
  {
    "managedkafka.googleapis.com/cpu/core_usage_time",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/cpu/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Utilizzo disco del broker 
max_over_time(
  {
    "managedkafka.googleapis.com/disk/used_bytes",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Dimensione segmento per partizione 
# Assumes that segment files are 225 MiB. Check your cluster configuration.
2*225*(1024*1024) * max_over_time(
  {
    "managedkafka.googleapis.com/partitions",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
/ min_over_time(
  {
    "managedkafka.googleapis.com/disk/limit",
    monitored_resource="managedkafka.googleapis.com/Cluster"
  }[${__interval}]
)
Partizioni per broker 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Partizioni per cluster 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

Monitorare il bilanciamento delle partizioni tra i broker

Un carico non uniforme può impedire a un cluster Kafka di gestire correttamente le richieste dei client. Il numero di partizioni assegnate a un singolo broker deve rimanere entro il 10% circa del numero medio di partizioni per broker. Cerca outlier in questa metrica.

Per mantenere partizioni bilanciate, valuta la possibilità di attivare il ribilanciamento automatico durante lo scale up nel cluster.

La tabella seguente mostra le query PromQL che puoi utilizzare per monitorare gli squilibri delle partizioni.

IndicatoreQuery PromQL
Conteggi partizioni per broker 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Squilibrio della partizione 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
/ on (resource_container, location, cluster_id)
  group_left avg by (resource_container, location, cluster_id) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
) - 1

Monitorare la replica delle partizioni

La replica dei dati è fondamentale per garantire la tolleranza agli errori dei tuoi workload. In un cluster integro, ogni partizione di un argomento ha il numero completo di repliche, in base al fattore di replica configurato dell'argomento.

Utilizza i seguenti indicatori per monitorare la replica delle partizioni:

  • Numero minimo di repliche sincronizzate (ISR). Se una partizione ha meno ISR sincronizzati rispetto al minimo configurato (min.insync.replicas), esiste un serio rischio di perdita di dati e disponibilità. In genere, questa situazione è causata da una capacità insufficiente su uno o più broker o da guasti dell'infrastruttura.

  • Partizioni con repliche insufficienti. Una partizione è sottoreplicata quando il numero di repliche sincronizzate scende al di sotto del fattore di replica. Se una partizione rimane sottoreplicata per decine di minuti, potrebbe esserci un problema con i broker, la capacità di archiviazione o altro.

    Durante un riavvio in sequenza, i broker diventano non disponibili durante il riavvio, causando una sottoreplicazione temporanea. Questa situazione è prevista e non richiede un intervento.

La tabella seguente mostra le query PromQL che puoi utilizzare per monitorare la replica.

IndicatoreQuery PromQL
Al di sotto degli ISR minimi 
max by (
  resource_container,
  location,
  cluster_id
) (
  max_over_time(
    {
      "managedkafka.googleapis.com/broker/under_min_isr_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
In fase di replica 
max by (
  resource_container,
  location,
  cluster_id
) (
  min_over_time(
    {
      "managedkafka.googleapis.com/broker/under_replicated_partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[10m:${__interval}]
  )
)

Passaggi successivi

Apache Kafka® è un marchio registrato di Apache Software Foundation o dei suoi affiliati negli Stati Uniti e/o in altri paesi.