Monitorare l'affidabilità dei cluster Kafka

Questo documento descrive come monitorare un cluster Managed Service per Apache Kafka per garantire l'affidabilità dei 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 recuperare da molti errori comuni. Ad esempio, il servizio posiziona le repliche in zone diverse per la tolleranza di errore 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à.

Monitora 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 di tempo prolungato.

  • Utilizzo della 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 quel 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 nel cluster.

  • 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, prendi in considerazione 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}]
  )
)

Monitora 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 circa il 10% del numero medio di partizioni per broker. Cerca outlier in questa metrica.

Per mantenere le partizioni bilanciate, valuta la possibilità di attivare il bilanciamento automatico in caso di scale up nel cluster.

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

IndicatoreQuery PromQL
Conteggi 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

Monitora la replica delle partizioni

La replica dei dati è fondamentale per garantire che i workload siano a tolleranza di errore. In un cluster integro, ogni partizione di un argomento ha il numero completo di repliche, in base al fattore di replica configurato per l'argomento.

Utilizza i seguenti indicatori per monitorare la replica delle partizioni:

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

  • Partizioni con replica insufficiente. Una partizione è sottoreplicata quando il numero di repliche sincronizzate 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 sotto-replica 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}]
  )
)

Monitora la quota di richieste di autorizzazione

Quando un client si connette a un cluster, l'autorizzazione della connessione viene conteggiata ai fini della quota Richieste di connessione di autenticazione del cluster al minuto per progetto per regione. Tutti i cluster di un progetto e di una regione condividono questa quota e il suo superamento blocca le nuove connessioni client. Cerca di mantenere l'utilizzo della quota al di sotto dell'80% e crea avvisi per ricevere una notifica se l'utilizzo rimane elevato.

Se l'utilizzo della quota è elevato, prendi in considerazione le seguenti mitigazioni:

  • Riduci la frequenza con cui i client creano nuove connessioni non necessarie. Ad esempio, configura i client in modo che utilizzino il backoff esponenziale per gli errori di produzione e consumo, consolida le istanze client ove opportuno e riutilizza le connessioni esistenti.

  • Richiedi un aumento della quota. Per saperne di più, consulta Quote e limiti.

La tabella seguente mostra una query PromQL che puoi utilizzare per monitorare i primi tre utilizzi della quota di richieste di autorizzazione per progetto e regione.

IndicatoreQuery PromQL
Utilizzo della quota di richieste di autorizzazione dei primi 3 progetti e regioni 
topk(3,
  sum by (project_id, location) (
    rate(
      {
        "serviceruntime.googleapis.com/quota/rate/net_usage",
        monitored_resource="consumer_quota",
        service="managedkafka.googleapis.com",
        quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests"
      }[${__interval}]
    )
  )
  / (
    min by (project_id, location) (
      min_over_time(
        {
          "serviceruntime.googleapis.com/quota/limit",
          monitored_resource="consumer_quota",
          service="managedkafka.googleapis.com",
          quota_metric="managedkafka.googleapis.com/cluster_authenticate_requests",
          limit_name="ClusterAuthPerMinutePerProjectPerRegion"
        }[${__interval}]
      )
    )
    / 60
  )
)

Passaggi successivi

Apache Kafka® è un marchio registrato di Apache Software Foundation o delle sue società affiliate negli Stati Uniti e/o in altri paesi.