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 er viele häufige Fehler toleriert und sich davon erholt. Der Dienst platziert Replikate beispielsweise in verschiedenen Zonen, um die Fehlertoleranz zu erhöhen, und startet ausgefallene Broker automatisch neu. Andere Faktoren, die sich auf die Zuverlässigkeit auswirken, liegen jedoch außerhalb der direkten Kontrolle des Dienstes, z. B.:

  • Clientkonfiguration
  • Last im Cluster, einschließlich durchschnittlicher Last und Spitzen
  • Anzahl der Partitionen und Replikate
  • Themenkonfigurationen, z. B. Nachrichtenspeicherung

Für einen zuverlässigen Betrieb 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 für die Zuverlässigkeit beschrieben.

Clusterkapazität überwachen

Um eine Überlastung eines Clusters zu vermeiden, sollten Sie die folgenden Signale im Blick behalten. Benachrichtigungen können Sie erstellen, um informiert zu werden, wenn die Werte über einen längeren Zeitraum außerhalb des empfohlenen Bereichs liegen.

  • CPU-Auslastung. Versuchen Sie, die CPU-Auslastung aller Broker unter 80% zu halten.

  • Laufwerksauslastung des Brokers: Die Laufwerksauslastung des Brokers sollte unter 80 % bleiben.

  • Laufwerksgröße. Als sicheren Ausgangspunkt empfehlen wir mindestens 2*(segment.bytes) pro Partition und Broker. In der Praxis ist der tatsächliche Speicherplatzbedarf 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 Festplattengröße erhöhen, sollten Sie die Festplattenauslastung beobachten, während Sie weitere Partitionen im Cluster erstellen.

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

Wenn in Ihrem Cluster die Kapazität knapp ist, können Sie Folgendes tun:

In der folgenden Tabelle finden Sie Prometheus-Abfragesprache (PromQL)-Abfragen 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}]
  )
)

Partitionsausgleich zwischen Brokern ü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 innerhalb von etwa 10% der durchschnittlichen Anzahl von Partitionen pro Broker liegen. Suchen Sie nach Ausreißern bei diesem Messwert.

Um ausgeglichene Partitionen zu erhalten, sollten Sie in Ihrem Cluster automatisches Neuausgleichen beim Hochskalieren aktivieren.

In der folgenden Tabelle finden Sie PromQL-Abfragen, mit denen Sie Partitionenungleichgewichte ü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}]
  )
)
Partitionsungleichgewicht 
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 sicherzustellen, dass Ihre Arbeitslasten fehlertolerant sind. In einem fehlerfreien Cluster hat jede Partition in einem Thema die volle Anzahl von Replikaten, basierend auf dem konfigurierten Replikationsfaktor des Themas.

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

  • Unter der Mindestanzahl von synchronisierten Replikaten (In-Sync Replicas, ISRs). Wenn eine Partition weniger synchronisierte ISRs als das konfigurierte Minimum (min.insync.replicas) hat, besteht ein hohes Risiko für Datenverlust und Verfügbarkeit. Normalerweise wird diese Situation durch 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 über mehrere zehn Minuten hinweg unterrepliziert bleibt, liegt möglicherweise ein Problem mit den Brokern, der Speicherkapazität oder etwas anderem vor.

    Während eines fortlaufenden Neustarts sind Broker nicht verfügbar, da sie neu gestartet werden. Dies führt zu einer vorübergehenden Unterreplizierung. Das ist normal und erfordert kein Eingreifen.

In der folgenden Tabelle finden Sie PromQL-Abfragen, mit denen Sie die Replikation überwachen können.

SignalPromQL-Abfrage
Unter der Mindestanzahl von 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}]
  )
)
Unter Replikation 
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

Apache Kafka® ist eine eingetragene Marke der Apache Software Foundation oder ihrer verbundenen Unternehmen in den USA und/oder anderen Ländern.