Erste Schritte mit Kafka-Clientmetriken

Bei Kafkaumfasst die Überwachung normalerweise verschiedene Metriken, die sich auf Topics, Partitionen, Broker und Konsumentengruppen beziehen. Die Kafka-Standardmetriken enthalten Informationen zum Durchsatz, zur Latenz, zur Replikation und zur Plattenbelegung. Lesen Sie die Kafka-Dokumentation und die relevanten Überwachungstools, um sich mit den spezifischen Metriken vertraut zu machen, die für Ihre Version von Kafka verfügbar sind, und wie sie effektiv interpretiert werden.

Warum ist es wichtig, Kafka-Clients zu überwachen?

Die Überwachung Ihrer Event Streams-Instanz ist entscheidend, um eine optimale Funktionalität und den Gesamtzustand Ihrer Datenpipeline sicherzustellen. Durch die Überwachung Ihrer Kafka-Clients können frühe Anzeichen von Anwendungsfehlern, wie z. B. hohe Ressourcennutzung, verzögernde Konsumenten und Engpässe, erkannt werden. Die frühzeitige Erkennung dieser Warnzeichen ermöglicht eine proaktive Reaktion auf potenzielle Probleme, die Ausfallzeiten minimieren und Unterbrechungen der Betriebsabläufe verhindern.

Kafka-Clients (Produzenten und Konsumenten) verfügen über eine eigene Gruppe von Metriken zur Überwachung ihrer Leistung und ihres Zustands. Darüber hinaus unterstützt der Service Event Streams eine Vielzahl von Metriken, die vom Server generiert werden. Weitere Informationen finden Sie unter Event Streams-Servicemetriken mit IBM Cloud Monitoring.

Zu überwachende Clientmetriken

Producermetriken

Metriken der Produzenten
Metrik Beschreibung
Satzfehlerrate Diese Metrik misst die durchschnittliche Anzahl pro Sekunde gesendeter Datensätze, die zu Fehlern geführt haben. Ein hoher record-error-rate oder ein Anstieg der record-error-rate kann auf einen Verlust von Daten oder Daten hinweisen, die nicht wie erwartet verarbeitet werden. All diese Auswirkungen können die Integrität der Daten beeinträchtigen, die Sie in Kafkaverarbeiten und speichern. Durch die Überwachung dieser Metrik können Sie sicherstellen, dass Daten, die von Produzenten gesendet werden, präzise und zuverlässig in Ihren Kafka-Topics aufgezeichnet werden.
Anforderungslatenzzeit-Durchschnitt Dies ist die durchschnittliche Latenzzeit für jede Erzeugnisanforderung in Millisekunden. Eine Erhöhung der Latenzzeit wirkt sich auf die Leistung aus und kann ein Problem signalisieren. Die Messung der Metrik request-latency-avg kann Ihnen helfen, Engpässe in Ihrer Instanz zu erkennen. Für viele Anwendungen ist eine niedrige Latenzzeit von entscheidender Bedeutung, um eine qualitativ hochwertige Benutzererfahrung sicherzustellen und eine Spitze in request-latency-avg kann darauf hinweisen, dass Sie die Grenzwerte Ihrer bereitgestellten Instanz erreichen. You can fix the issue by changing your producer settings, for example, by batching or scaling your plan to optimize performance.
Byterate Die durchschnittliche Anzahl der pro Sekunde gesendeten Byte für ein Thema ist ein Maß für Ihren Durchsatz. Wenn Sie Daten regelmäßig streamen, kann ein Rückgang des Durchsatzes auf eine Anomalie in Ihrer Kafka-Instanz hinweisen. Der Enterprise-Plan Event Streams beginnt bei 150 MB pro Sekunde, die 1: 1 zwischen Ingress und Egress aufgeteilt werden. Es ist wichtig zu wissen, wie viel davon Sie für eine effektive Kapazitätsplanung verwenden. Gehen Sie nicht über zwei Drittel des maximalen Durchsatzes, um die möglichen Auswirkungen von Betriebsaktionen zu berücksichtigen, wie z. B. interne Aktualisierungen oder Fehlermodi (z. B. Verlust einer Verfügbarkeitszone).

Konsumentenmetriken

Verbrauchermetriken
Metrik Beschreibung
fetch-rate fetch-size-avg Die Anzahl der Abrufanforderungen pro Sekunde (fetch-rate) und die durchschnittliche Anzahl der pro Anforderung abgerufenen Byte (fetch-size-avg) sind Schlüsselindikatoren für die Leistung Ihrer Kafka-Konsumenten. Ein hoher Wert für fetch-rate kann die Ineffizienz signalisieren, insbesondere bei einer kleinen Anzahl von Nachrichten, da dies bedeutet, dass nicht genügend Daten empfangen werden oder dass jedes Mal keine Daten empfangen werden. fetch-rate und fetch-size-avg sind von drei Einstellungen betroffen: fetch.min.bytes, fetch.max.bytes und fetch.max.wait.ms. Optimieren Sie diese Einstellungen, um die gewünschte Gesamtlatenz zu erreichen und gleichzeitig die Anzahl der Abrufanforderungen und möglicherweise die Auslastung der Broker-CPU zu minimieren. Die Überwachung und Optimierung beider Metriken stellt sicher, dass Sie Daten effizient für aktuelle und zukünftige Workloads verarbeiten.
Commit-Latenzzeit-Durchschnitt Dieser Messwert gibt die durchschnittliche Zeit zwischen dem Senden eines festgeschriebenen Datensatzes und dem Empfang der Commitantwort an. Ähnlich wie request-latency-avg als Produzentenmetrik bedeutet ein stabiler commit-latency-avg, dass Ihre Offset-Festschreibungen zeitnah erfolgen. Eine hohe Commitlatenz kann auf Probleme im Konsumenten hinweisen, die verhindern, dass er Offsets schnell festschreibt, was sich direkt auf die Zuverlässigkeit der Datenverarbeitung auswirkt. Dies kann zu einer doppelten Verarbeitung von Nachrichten führen, wenn ein Konsument Nachrichten von einem zuvor nicht festgeschriebenen Offset erneut starten und verarbeiten muss. Eine hohe Commitlatenz bedeutet auch, dass mehr Zeit für Verwaltungsoperationen aufgewendet wird als für die eigentliche Nachrichtenverarbeitung. Dieses Problem kann zu Rückständen von Nachrichten führen, die auf die Verarbeitung warten, insbesondere in Umgebungen mit hohem Volumen.
verbrauchte-byte-rate Dies ist ein Consumer-Abrufmesswert, der die durchschnittliche Anzahl der pro Sekunde konsumierten Byte misst. Ähnlich wie bei byte-rate als Produzentenmetrik sollte dies eine stabile und erwartete Metrik sein. Eine plötzliche Änderung des erwarteten Trends von bytes-consumed-rate kann ein Problem mit Ihren Anwendungen darstellen. Eine niedrige Rate kann ein Signal der Effizienz beim Datenabruf oder bei Ressourcen mit Überkapazitäten sein. Eine höhere Rate kann die Verarbeitungskapazität der Konsumenten überlasten und erfordert daher eine Skalierung, wodurch mehr Konsumenten erstellt werden, um die Last auszugleichen, oder die Konsumentenkonfigurationen, wie z. B. Abrufgrößen, ändern.
Neuausgleichsrate pro Stunde Die Anzahl der Gruppenneuausgleich, an denen pro Stunde teilgenommen wurde. Die Neuverteilung erfolgt jedes Mal, wenn ein neuer Konsument vorhanden ist oder wenn ein Konsument die Gruppe verlässt und eine Verzögerung bei der Verarbeitung verursacht. Dies liegt daran, dass Partitionen neu zugewiesen werden, was Kafka-Konsumenten weniger effizient macht, wenn es viele Neuausgleichungen pro Stunde gibt. Eine höhere Neuausgleichsrate pro Stunde könnte durch fehlerhafte Konfigurationen verursacht werden, die zu instabilem Verbraucherverhalten führen. Diese Neuverteilung kann zu einer Erhöhung der Latenzzeit und zum Absturz von Anwendungen führen. Stellen Sie sicher, dass Ihre Consumergruppen stabil sind, indem Sie eine niedrige und stabile rebalance-rate-per-hour verfolgen.