Kafka-Clientanwendungen überwachen

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

Es ist wichtig, Clientanwendungen im Rahmen Ihrer allgemeinen Zuverlässigkeitsstrategie zu überwachen. Anhand von Messwerten wie Durchsatz, Fehlerraten und Consumer-Verzögerung können Sie feststellen, 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 sich nur auf eine bestimmte Partition auswirken.

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 Brokers) und Abweichungen im normalen Betrieb zu erkennen, z. B. Latenzspitzen.

Durchsatz

Beobachten 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) überfluten und so den Durchsatz reduzieren.
  • Anfragelatenz. Spitzen bei der Latenz von Producer-Anfragen können auf eine unausgeglichene 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 die allgemeine Überwachung und Benachrichtigung und sehen Sie sich die Messwerte pro Thema an, wenn Sie Probleme mit dem Durchsatz beheben. Isolieren Sie alle Probleme auf bestimmte Broker.

Fehlerraten bei Anfragen

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

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

  • Clusterfehler können verhindern, dass ein Broker überhaupt auf Anfragen antwortet.

Aus diesem Grund sollten Sie auch Fehler auf der Clientseite beobachten, einschließlich Fehlern aufgrund von Zeitüberschreitungen bei Anfragen.

Consumer-Verzögerung

Die Consumer-Verzögerung gibt an, wie weit ein Consumer-Client hinter einem bestimmten Offset zurückliegt. 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.

Erwägen Sie, eine Benachrichtigung basierend auf der maximalen Verzögerung für die Teilmenge der Themen zu erstellen, die für Ihre Arbeitslast entscheidend sind.

Benutzerdefinierte Dashboard-Abfragen

Wir empfehlen, benutzerdefinierte Dashboards und Benachrichtigungen zu erstellen, um diese Signale zu beobachten. In der folgenden Tabelle sind Prometheus Query Language-Abfragen (PromQL) aufgeführt, mit denen Sie den Clientstatus ü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 5 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, Clustergesamtwerte 
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 Anforderungsfehler 
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 der Partitionen nach Consumer-Verzögerung 
topk(5,
  max by (resource_container, location, cluster_id, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__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 Anfragen eine Zeitüberschreitung verursachen, werden die Nachrichten wieder in die Warteschlange gestellt und noch einmal gesendet.

  • Wenn die Ablaufsteuerung falsch konfiguriert ist, kann ein Client mehr Nachrichten erzeugen, als die zugewiesene Anzahl von Threads senden kann. Obwohl der Durchsatz möglicherweise konstant ist, läuft eine wachsende Anzahl von Anfragen ab, bevor sie gesendet werden können.

Wenn Ihre Clients auf 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 blenden jedoch Ausnahmen aus, die zu längeren Wiederholungen führen, es sei denn, Sie konfigurieren höhere Logebenen. 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. Instrumentieren Sie Ihre Clients nach Möglichkeit so, dass die folgenden Messwerte gemeldet werden:

  • Fehlerraten bei Anfragen (kafka.producer:type=producer-metrics,client-id="{client-id}")
  • Durchschnittliche Latenz bei Anfragen (kafka.producer:type=producer-metrics,client-id="{client-id}")

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

Abhilfemaßnahmen

Wenn in Ihren Clientanwendungen Probleme auftreten, sollten Sie die folgenden Abhilfemaßnahmen in Betracht ziehen:

  • Suchen Sie nach unausgeglichener Last zwischen Brokern (Hot Brokers). Achten Sie darauf, dass die automatische Lastverteilung 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 für den 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 skaliert 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 Partitionen anderen Brokern zuzuweisen.

Nächste Schritte