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

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 beobachten, 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. Spitzen bei der Latenz.

Durchsatz

Behalten Sie die folgenden Durchsatzmesswerte im Blick und vergleichen Sie sie mit dem erwarteten Durchsatz:

  • Nachrichtenfrequenz pro Broker und Thema.
  • Byterate pro Broker und pro Thema.
  • Anforderungsraten. Ein falsch konfigurierter Client kann Broker mit einer hohen Anzahl kleiner Anfragen (0–1.000 Byte pro Anfrage) überlasten und so den Durchsatz verringern.
  • 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 zusammengefasst werden. Verwenden Sie einen aggregierten Messwert für die allgemeine Überwachung und Benachrichtigungen und sehen Sie sich Messwerte pro Thema an, wenn Sie Probleme mit dem Durchsatz beheben. Probleme auf bestimmte Broker eingrenzen

Fehlerraten bei Anfragen

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

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

  • Bei Clusterfehlern kann es sein, dass ein Broker überhaupt nicht auf Anfragen reagiert.

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

Verzögerung bei Verbrauchern

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.

Erstellen Sie einen Alert basierend auf der maximalen Verzögerung für die Teilmenge der Themen, 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 finden Sie Prometheus Query Language (PromQL)-Abfragen, 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, Clustergesamtsummen 
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 Anfragen mit Fehlern 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
Verbraucherverzögerung: Top 5 Partitionen nach Verbraucherverzö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 Servermesswerten angezeigt. Beispiel:

  • Wenn die Authentifizierung oder das Netzwerk falsch konfiguriert ist, können sich Nachrichten in den internen Warteschlangen des Clients ansammeln. Wenn es bei Anfragen zu Zeitüberschreitungen kommt, werden die Nachrichten noch einmal in die Warteschlange eingereiht und es wird ein erneuter Versuch unternommen.

  • Wenn die Flusssteuerung falsch konfiguriert ist, kann es sein, dass ein Client mehr Nachrichten erzeugt, als die zugewiesene Anzahl von Threads senden kann. Der Durchsatz ist zwar möglicherweise konstant, aber ein wachsender Rückstand an Anfragen läuft 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 blenden jedoch Ausnahmen aus, 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:

  • Fehlerraten für Anfragen (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 Folgendes tun:

  • Suchen Sie nach einer ungleichmäßigen Lastverteilung auf die Broker (Hot Brokers). Achten Sie darauf, dass automatisches Lastverteilen in Ihrem Cluster aktiviert ist.

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

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

  • Ein übermäßiger Rückstand bei allen Themen oder Partitionen in einem Cluster kann darauf hindeuten, dass der Cluster überlastet ist und skaliert werden sollte.

  • Ein übermäßiger Lag 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

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