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 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, come 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 escono dall' 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%.

  • Dimensioni del disco. Come punto di partenza sicuro, 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 mentre crei altre partizioni nel cluster.

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

Se la capacità del cluster è insufficiente, 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 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 del 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 gli outlier 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 delle 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

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:

  • Sotto il 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
Sotto il 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