Kafka-Cluster auf Zuverlässigkeit überwachen

In diesem Dokument wird beschrieben, wie Sie einen Managed Service for Apache Kafka-Cluster überwachen, um die Zuverlässigkeit Ihrer Kafka-Arbeitslasten sicherzustellen.

Übersicht

Zuverlässigkeit ist die Fähigkeit eines Systems, über einen längeren Zeitraum hinweg korrekt und konsistent zu funktionieren. Bei Kafka-basierten Arbeitslasten umfasst die Zuverlässigkeit sowohl die Kafka-Cluster selbst als auch die Clientanwendungen, die Nachrichten erstellen und nutzen.

Managed Service for Apache Kafka ist so konzipiert, dass viele häufige Fehler toleriert und behoben werden können. Der Dienst platziert beispielsweise Replikate in verschiedenen Zonen, um die Fehlertoleranz zu erhöhen, und startet Broker automatisch neu, wenn sie ausfallen. Andere Faktoren, die sich auf die Zuverlässigkeit auswirken, liegen jedoch außerhalb der direkten Kontrolle des Dienstes, z. B.:

  • Clientkonfiguration
  • Last auf dem Cluster, einschließlich durchschnittlicher Last und Lastspitzen
  • Anzahl der Partitionen und Replikate
  • Themenkonfigurationen, z. B. Nachrichtenaufbewahrung

Um einen zuverlässigen Betrieb zu gewährleisten, ist es wichtig, den Cluster auf diese Betriebsparameter zu überwachen und sie innerhalb der empfohlenen Bereiche zu halten. In den folgenden Abschnitten werden einige wichtige Messwerte beschrieben, die für die Zuverlässigkeit wichtig sind.

Clusterkapazität

Um eine Überlastung eines Clusters zu vermeiden, sollten Sie die folgenden Signale überwachen. Erstellen Sie Benachrichtigungen, damit Sie informiert werden, wenn sie über einen längeren Zeitraum außerhalb des empfohlenen Bereichs liegen.

  • CPU-Auslastung : Die CPU-Auslastung sollte auf allen Brokern unter 80% liegen.

  • Broker-Laufwerksauslastung: Die Broker-Laufwerksauslastung sollte unter 80 % liegen.

  • Anzahl der Partitionen : Es sollten weniger als 4.000 Partitionen pro Broker und weniger als 100.000 Partitionen pro Cluster vorhanden sein.

Wenn die Kapazität Ihres Clusters gering ist, sollten Sie die folgenden Maßnahmen in Betracht ziehen:

  • Erhöhen Sie die Anzahl der vCPUs des Clusters. Weitere Informationen finden Sie unter Kafka-Cluster aktualisieren.

  • Skalieren Sie den Cluster, um weitere Broker hinzuzufügen. Informationen zur Bereitstellung von Brokern durch den Dienst finden Sie unter Brokerbereitstellung.

Die folgende Tabelle enthält Prometheus-Abfragesprache-Abfragen (PromQL) für diese Messwerte, die Sie einem benutzerdefinierten Cloud Monitoring-Dashboard hinzufügen können.

SignalPromQL-Abfrage
CPU-Auslastung 
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}]
)
Broker-Laufwerksauslastung 
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}]
)
Segmentgröße pro Partition 
# 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}]
)
Partitionen pro Broker 
max by (resource_container, location, cluster_id, broker_index) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Partitionen pro Cluster 
max by (resource_container, location, cluster_id) (
  max_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)

Ungleichgewicht der Partitionen

Eine ungleichmäßige Last kann verhindern, dass ein Kafka-Cluster Clientanfragen ordnungsgemäß verarbeitet. Die Anzahl der Partitionen, die einem einzelnen Broker zugewiesen sind, sollte etwa 10% der durchschnittlichen Anzahl der Partitionen pro Broker betragen. Achten Sie auf Ausreißer bei diesem Messwert.

Um ausgeglichene Partitionen zu erhalten, können Sie das automatische Rebalancing beim Hochskalieren in Ihrem Cluster aktivieren.

Die folgende Tabelle enthält PromQL-Abfragen, mit denen Sie Ungleichgewichte bei Partitionen überwachen können.

SignalPromQL-Abfrage
Anzahl der Partitionen pro Broker 
sum by (resource_container, location, cluster_id, broker_index) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/partitions",
      monitored_resource="managedkafka.googleapis.com/Cluster"
    }[${__interval}]
  )
)
Ungleichgewicht der Partitionen 
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

Partitionen replizieren

Die Datenreplikation ist entscheidend, um die Fehlertoleranz Ihrer Arbeitslasten zu gewährleisten. In einem fehlerfreien Cluster hat jede Partition in einem Thema die vollständige Anzahl von Replikaten, basierend auf dem konfigurierten Replikationsfaktordes Themas.

Verwenden Sie die folgenden Signale, um die Partitionenreplikation zu überwachen:

  • Weniger als die Mindestanzahl an synchronen Replikaten (In-Sync Replicas, ISRs) : Wenn eine Partition weniger synchrone ISRs als die konfigurierte Mindestanzahl (min.insync.replicas) hat, besteht ein ernstes Risiko für Datenverlust und Verfügbarkeit. In der Regel wird diese Situation durch eine unzureichende Kapazität auf einem oder mehreren Brokern oder durch Infrastrukturfehler verursacht.

  • Unterreplizierte Partitionen : Eine Partition ist unterrepliziert, wenn die Anzahl der synchronen Replikate unter den Replikationsfaktor fällt. Wenn eine Partition mehrere zehn Minuten lang unterrepliziert bleibt, liegt möglicherweise ein Problem mit den Brokern, der Speicherkapazität oder etwas anderem vor.

    Während eines rollierenden Neustarts sind Broker nicht verfügbar, da sie neu gestartet werden, was zu einer vorübergehenden Unterreplikation führt. Diese Situation ist normal und erfordert keine Maßnahmen.

Die folgende Tabelle enthält PromQL-Abfragen, mit denen Sie die Replikation überwachen können.

SignalPromQL-Abfrage
Weniger als die Mindestanzahl an ISRs 
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}]
  )
)
Unterreplikation 
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}]
  )
)

Nächste Schritte