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 zu gewährleisten.

Ü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, bei denen Fehler auftreten, automatisch neu. 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 anhand dieser 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 relevant sind.

Clusterkapazität überwachen

Um eine Überlastung des 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.

  • Laufwerkgröße : Als sicherer Ausgangspunkt empfehlen wir mindestens 2*(segment.bytes) pro Partition und Broker. In der Praxis sind die tatsächlichen Laufwerksanforderungen oft deutlich geringer.

    Standardmäßig wird eine Segmentdatei nach 7 Tagen geschlossen und in den Remote-Speicher verschoben. In den meisten Partitionen werden in diesem Zeitraum weniger als segment.bytes Daten empfangen, sodass die meisten Partitionen weniger als segment.bytes Speicherplatz belegen. Bevor Sie die Laufwerkgröße erhöhen, sollten Sie die Laufwerksauslastung beobachten, während Sie weitere Partitionen im Cluster erstellen.

  • Anzahl der Partitionen : Sie sollten weniger als 4.000 Partitionen pro Broker und weniger als 100.000 Partitionen pro Cluster verwenden.

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

Die folgende Tabelle enthält PromQL-Abfragen (Prometheus Query Language) 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}]
  )
)

Partitionsverteilung auf Broker überwachen

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. Suchen Sie nach Ausreißern 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 bei 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

Partitionsreplikation überwachen

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 Partitionsreplikation zu überwachen:

  • Weniger als die Mindestanzahl an synchronen Replikaten (In-Sync Replicas, ISRs) : Wenn eine Partition weniger synchrone ISRs hat als das konfigurierte Minimum (min.insync.replicas), besteht ein erhebliches 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 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