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 verarbeiten.

Managed Service for Apache Kafka ist so konzipiert, dass er viele gängige Fehler toleriert und sich davon erholt. Der Dienst platziert beispielsweise Replikate in verschiedenen Zonen, um Fehlertoleranz zu gewährleisten, 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 auf dem Cluster, einschließlich durchschnittlicher Last und Spitzen
  • Die 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 beschrieben, die für die Zuverlässigkeit wichtig sind.

Clusterkapazität überwachen

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

  • CPU-Auslastung. Versuchen Sie, die CPU-Auslastung auf allen Brokern unter 80 % zu halten.

  • Broker-Laufwerksauslastung: Achten Sie darauf, dass die Broker-Laufwerksauslastung unter 80 % bleibt.

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

    Standardmäßig wird eine Segmentdatei nach 7 Tagen geschlossen und in den Remotespeicher verschoben. In der Regel werden die meisten Partitionen in diesem Zeitraum mit weniger als segment.bytes Daten belegt. Das bedeutet, dass die meisten Partitionen weniger als segment.bytes Speicherplatz belegen. Bevor Sie die Laufwerksgröße erhöhen, sollten Sie die Laufwerksauslastung 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 verwalten.

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

In der folgenden Tabelle finden Sie Prometheus Query Language (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}]
  )
)

Partitionsverteilung über Broker hinweg überwachen

Eine ungleichmäßige Last kann dazu führen, dass ein Kafka-Cluster Clientanfragen nicht ordnungsgemäß verarbeitet. Die Anzahl der Partitionen, die einem einzelnen Broker zugewiesen sind, sollte innerhalb von etwa 10 % der durchschnittlichen Partitionsanzahl pro Broker liegen. Suchen Sie nach Ausreißern in diesem Messwert.

Damit die Partitionen ausgeglichen bleiben, sollten Sie in Ihrem Cluster die automatische Neugewichtung beim Hochskalieren aktivieren.

In der folgenden Tabelle sind PromQL-Abfragen aufgeführt, mit denen Sie Partitionsungleichgewichte ü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 die Fehlertoleranz Ihrer Arbeitslasten zu gewährleisten. 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 (ISRs). Wenn eine Partition weniger synchronisierte ISRs als das konfigurierte Minimum (min.insync.replicas) hat, besteht ein erhebliches Risiko für Datenverlust und Verfügbarkeit. In der Regel wird diese Situation durch unzureichende Kapazität bei einem oder mehreren Brokern oder durch Infrastrukturfehler verursacht.

  • Unterreplizierte Partitionen. Eine Partition ist unterrepliziert, wenn die Anzahl der synchronisierten Replikate unter den Replikationsfaktor fällt. Wenn eine Partition über mehrere Minuten hinweg 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. Dies führt zu einer vorübergehenden Unterreplikation. Diese Situation 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 dem Mindest-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}]
  )
)
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}]
  )
)

Kontingent für Autorisierungsanfragen überwachen

Wenn ein Client eine Verbindung zu einem Cluster herstellt, wird die Autorisierung der Verbindung auf das Kontingent Cluster authenticate connection requests per minute per project per region angerechnet. Alle Cluster in einem Projekt und einer Region teilen sich dieses Kontingent. Wenn es überschritten wird, werden neue Clientverbindungen blockiert. Versuchen Sie, die Kontingentauslastung unter 80 % zu halten, und erstellen Sie Benachrichtigungen, um informiert zu werden, wenn die Auslastung hoch bleibt.

Wenn die Kontingentauslastung hoch ist, sollten Sie die folgenden Maßnahmen in Betracht ziehen:

  • Reduzieren Sie die Rate, mit der Clients unnötige neue Verbindungen erstellen. Konfigurieren Sie Ihre Clients beispielsweise so, dass sie bei Produktions- und Konsumfehlern einen exponentiellen Backoff verwenden, konsolidieren Sie Clientinstanzen, wo dies sinnvoll ist, und verwenden Sie vorhandene Verbindungen wieder.

  • Fordern Sie eine Kontingenterhöhung an. Weitere Informationen finden Sie unter Kontingente und Limits.

In der folgenden Tabelle finden Sie eine PromQL-Abfrage, mit der Sie die drei höchsten Kontingentauslastungen für Autorisierungsanfragen nach Projekt und Region überwachen können.

SignalPromQL-Abfrage
Die drei höchsten Kontingentauslastungen für Autorisierungsanfragen nach Projekt und Region 
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
  )
)

Nächste Schritte

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