Monitorare l'affidabilità dei cluster Kafka

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

Panoramica

L'affidabilità è la capacità di un sistema di funzionare correttamente e in modo coerente nel tempo. Per i workload 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 ripristinare molti errori comuni. Ad esempio, il servizio inserisce 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 sono sotto il 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à.

Capacità del cluster

Per evitare di sovraccaricare un cluster, monitora i seguenti indicatori. Crea avvisi per ricevere una notifica se questi indicatori escono dall'intervallo consigliato per un periodo di tempo 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%.

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

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

  • Aumenta il numero di vCPU del cluster. Per ulteriori informazioni, consulta Aggiornare un cluster Kafka.

  • Esegui lo scale up del cluster per aggiungere altri broker. Per informazioni su come il servizio esegue il provisioning dei broker, consulta Provisioning dei broker.

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

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 del 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}]
)
Dimensioni 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}]
  )
)

Squilibrio delle partizioni

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 conteggio medio delle partizioni per broker. Cerca i valori anomali in questa metrica.

Per mantenere le 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
Conteggio 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 delle partizioni 
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

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:

  • Al di sotto del numero minimo di repliche in-sync (ISR). Se una partizione ha meno ISR in-sync del minimo configurato (min.insync.replicas), esiste un grave rischio di perdita di dati e disponibilità. In genere, questa situazione è causata da una capacità insufficiente su uno o più broker o da errori dell'infrastruttura.

  • Partizioni con replica insufficiente. Una partizione ha una replica insufficiente quando il numero di repliche in-sync scende al di sotto del fattore di replica. Se una partizione rimane con replica insufficiente 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 replica insufficiente temporanea. Questa situazione è prevista e non richiede alcun intervento.

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

IndicatoreQuery PromQL
Al di sotto del numero minimo di ISR 
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}]
  )
)
Replica insufficiente 
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