Kafka-Clientanwendungen überwachen

In diesem Dokument wird beschrieben, wie Sie den Zustand von Clients überwachen, die Daten in Ihrem Managed Service for Apache Kafka-Cluster erzeugen oder verarbeiten.

Es ist wichtig, Clientanwendungen im Rahmen Ihrer allgemeinen Zuverlässigkeitsstrategie zu überwachen. Messwerte wie Durchsatz, Fehlerraten und Consumer-Verzögerung können Aufschluss darüber geben, ob bei Clientanwendungen Zuverlässigkeitsprobleme auftreten. Probleme können durch die Clientkonfiguration, eine ungleichmäßige Verteilung von Schlüsseln auf Partitionen oder Clusterprobleme verursacht werden, die nur eine bestimmte Partition betreffen.

Serverseitige Messwerte

Es ist zwar nützlich, das Clientverhalten direkt zu überwachen, aber für serverseitige Messwerte ist keine zusätzliche Instrumentierung erforderlich. Sie können Ihnen helfen, clientseitige Probleme zu erkennen, die sich auf die Zuverlässigkeit auswirken.

Serverseitige Messwerte sind besonders nützlich, um Lastungleichgewichte zwischen Brokern (Hot Broker) und Abweichungen im normalen Betrieb, z. B. Latenzspitzen, zu erkennen.

Durchsatz

Überwachen Sie die folgenden Durchsatzmesswerte und vergleichen Sie sie mit dem erwarteten Durchsatz:

  • Nachrichtenrate pro Broker und pro Thema.
  • Byterate pro Broker und pro Thema.
  • Anforderungsraten. Ein falsch konfigurierter Client kann Broker mit einer hohen Rate kleiner Anfragen (0–1.000 Byte pro Anfrage) überlasten, was den Durchsatz verringert.
  • Anfragelatenz. Spitzen bei der Latenz von Erstelleranfragen können auf eine unausgewogene Last oder ein Problem mit der Clientkonfiguration hinweisen.

Kafka bietet Durchsatzmesswerte pro Thema und für den Cluster. Diese Messwerte haben nicht immer dieselben Werte, wenn sie für alle Themen aggregiert werden. Verwenden Sie einen aggregierten Messwert für allgemeines Monitoring und Benachrichtigungen und sehen Sie sich themenspezifische Messwerte an, wenn Sie Probleme mit dem Durchsatz beheben. Isolieren Sie Probleme auf bestimmte Broker.

Fehlerraten bei Anfragen

Der Messwert topic_error_count erfasst die Anzahl der fehlgeschlagenen Abruf- und Erstellungsanfragen auf der Serverseite. Einige Fehlerklassen werden in diesem Messwert jedoch nicht berücksichtigt. Beispiel:

  • Falsch konfigurierte Autorisierungseinstellungen können verhindern, dass ein Client in einem Thema veröffentlicht, ohne dass der Fehler in diesem Messwert angezeigt wird.

  • Clusterfehler können dazu führen, dass ein Broker überhaupt nicht auf Anfragen reagiert.

Aus diesem Grund sollten Sie auch Fehler auf der Clientseite im Blick behalten, einschließlich Zeitüberschreitungsfehlern bei Anfragen.

Verzögerung bei der Verarbeitung

Die Verbraucherverzögerung gibt an, wie weit ein Verbraucherclient hinter einem bestimmten Offset liegt. Wenn Sie diesen Messwert nach Thema, Partition und Broker aggregieren, können Sie feststellen, ob die Verzögerung auf bestimmte Broker oder Partitionen zurückzuführen ist.

Sie können eine Benachrichtigung basierend auf der maximalen Verzögerung für die Teilmenge der Themen erstellen, die für Ihre Arbeitslast wichtig sind.

Benutzerdefinierte Dashboard-Abfragen

Wir empfehlen, benutzerdefinierte Dashboards und Benachrichtigungen zu erstellen, um diese Signale zu überwachen. In der folgenden Tabelle sind PromQL-Abfragen (Prometheus Query Language) aufgeführt, mit denen Sie den Clientzustand überwachen können.

SignalPromQL-Abfrage
Durchsatz: Nachrichtenraten pro Broker 
sum by (resource_container, location, cluster_id, broker_index) (
  rate(
    {
      "managedkafka.googleapis.com/message_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Durchsatz: Nachrichtenraten pro Broker und Thema für die fünf größten Themen 
topk(5,
  sum by (resource_container, location, cluster_id, broker_index, topic_id) (
    rate(
      {
        "managedkafka.googleapis.com/message_in_count",
        monitored_resource="managedkafka.googleapis.com/Topic"
      }[${__interval}]
    )
  )
)
Durchsatz: Bandbreite pro Thema und Broker 
sum by (resource_container, location, cluster_id, broker_index, topic_id) (
  rate(
    {
      "managedkafka.googleapis.com/byte_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Anforderungsrate 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/request_count",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "request"="Produce"
    }[${__interval}]
  )
)
Anforderungsrate, Cluster-Gesamtsummen 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_request_count",
      monitored_resource="managedkafka.googleapis.com/Topic",
      "request"="Produce"
    }[${__interval}]
  )
)
Anfragelatenz 
sum by (resource_container, location, cluster_id, broker_index, request) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/request_latencies",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "percentile"="95",
      "request"="Produce"
    }[${__interval}]
  )
)
Anzahl der Anfragefehler 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Consumer-Verzögerung: Top 5-Partitionen nach Offset-Verzögerung 
topk(5,
  max by (resource_container, location, cluster_id, topic_id, partition_index) (
    max_over_time(
      {
        "managedkafka.googleapis.com/offset_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup"
      }[${__interval}]
    )
  )
)
Consumer-Verzögerung: Top-5-Consumer-Gruppen nach Offset-Verzögerung 
topk(5,
  max by (resource_container, location, cluster_id, consumer_group_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/offset_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup"
      }[${__interval}]
    )
  )
)

Clientseitige Messwerte

Manchmal werden Clientprobleme nicht in den Servermesswerten angezeigt. Beispiel:

  • Wenn die Authentifizierung oder das Netzwerk falsch konfiguriert ist, können sich Nachrichten in den internen Warteschlangen des Clients ansammeln. Wenn bei Anfragen eine Zeitüberschreitung auftritt, werden die Nachrichten wieder in die Warteschlange gestellt und noch einmal gesendet.

  • Wenn die Ablaufsteuerung falsch konfiguriert ist, erzeugt ein Client möglicherweise mehr Nachrichten, als die zugewiesene Anzahl von Threads senden kann. Obwohl der Durchsatz möglicherweise konsistent ist, läuft ein wachsender Rückstand an Anfragen ab, bevor sie gesendet werden können.

Wenn Ihre Clients in Compute Engine, Google Kubernetes Engine oder Cloud Run ausgeführt werden, können Sie logbasierte Messwerte in Cloud Monitoring verwenden, um hohe Fehlerraten in Logs zu erkennen. Einige Kafka-Clients verbergen jedoch Ausnahmen, die zu längeren Wiederholungsversuchen führen, sofern Sie keine höheren Protokollebenen konfigurieren. Daher sollten Sie auch auf erhöhte Anfragelatenzen achten.

Java-Clients stellen viele Messwerte über Java Management Extensions (JMX) bereit. Weitere Informationen finden Sie in der Apache Kafka-Dokumentation unter Monitoring. Wenn möglich, sollten Sie Ihre Clients so instrumentieren, dass die folgenden Messwerte erfasst werden:

  • Anfragefehlerraten (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • Durchschnittliche Anfragelatenz (kafka.producer:type=producer-metrics,client-id="{client-id}")

Senden Sie diese Messwerte nach Möglichkeit an eine Monitoring-Lösung. Wenn Sie eine Verbindung zu den JMX-Ports auf den Computern herstellen können, auf denen die Clientinstanzen ausgeführt werden, können Sie diese Messwerte auch interaktiv lesen.

Maßnahmen zur Risikominderung

Wenn Probleme in Ihren Clientanwendungen auftreten, können Sie die folgenden Maßnahmen ergreifen:

  • Suchen Sie nach ungleichmäßiger Lastverteilung auf die Broker (Hot Broker). Achten Sie darauf, dass die automatische Neuverteilung in Ihrem Cluster aktiviert ist.

  • Wenn die Anforderungsrate ungewöhnlich hoch ist, prüfen Sie, ob der Client eine große Anzahl kleiner Anfragen sendet. Prüfen Sie die Konfigurationen max.request.size und batch.size auf dem Producer.

  • Prüfen Sie die Clientkonfigurationen für Authentifizierung, Netzwerk und Flusssteuerung.

  • Eine übermäßige Verzögerung bei allen Themen oder Partitionen in einem Cluster kann darauf hindeuten, dass der Cluster überlastet ist und hochskaliert werden sollte.

  • Eine übermäßige Verzögerung bei allen Themen oder Partitionen in einem Broker kann darauf hindeuten, dass der Broker überlastet ist. Versuchen Sie, die Schlüsselverteilung zu verbessern, oder weisen Sie Partitionen anderen Brokern zu.

Nächste Schritte

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