Welche Metriken kann ich verwenden, um Probleme bei Kinesis-Datenströmen zu überwachen und zu beheben?
Ich möchte eingehende und ausgehende Daten für Amazon Kinesis Data Streams überwachen.
Behebung
Verwenden von Metriken auf Stream-Ebene
Sie können Amazon-CloudWatch-Metriken verwenden, um kontinuierlich die Leistung und den Durchsatz Ihres Amazon-Kinesis-Datenstroms zu überwachen. Die folgenden Metriken können Ihnen helfen, Probleme bei Produzenten und Konsumenten zu überwachen.
GetRecords.IteratorAgeMilliseconds
GetRecords.IteratorAgeMilliseconds misst das Alter des letzten Datensatzes im Stream für alle GetRecords-Anfragen in Millisekunden. Ein Wert von 0 für diese Metrik gibt an, dass die Datensätze innerhalb des Streams aktuell sind. Ein niedrigerer Wert wird bevorzugt. Um Leistungsprobleme zu überwachen, erhöhen Sie die Anzahl der Konsumenten für Ihren Stream, damit die Daten schneller verarbeitet werden. Um Ihren Anwendungscode zu optimieren, erhöhen Sie die Anzahl der Konsumenten, sodass sich die Verzögerung bei der Verarbeitung von Datensätzen verringert.
ReadProvisionedThroughputExceeded
ReadProvisionedThroughputExceeded misst die Anzahl der GetRecords-Aufrufe, die während eines bestimmten Zeitraums gedrosselt werden und die Service- oder Shard-Limits für Kinesis-Datenströme überschreiten. Ein Wert von 0 bedeutet, dass die Datenkonsumenten die Service Quotas nicht überschreiten. Jeder andere Wert zeigt an, dass das Durchsatzlimit überschritten wurde und zusätzliche Shards erforderlich waren. Diese Metrik bestätigt, dass der Stream nicht mehr als 5 Lesevorgänge pro Sekunde/Shard oder 2 MB/Sekunde/Shard enthält. Sie können die erweiterte Überwachung aktivieren, um sicherzustellen, dass der Stream keine Hot Shards enthält.
WriteProvisionedThroughputExceeded
WriteProvisionedThroughputExceeded misst den PUT oder den Datenproduzenten (wie z. B. ReadProvisionedThroughputExceeded), sodass festgestellt werden kann, ob der Stream gedrosselt ist. Dies überschreitet die Service Quotas für Datenströme beim Schreiben in einen Shard. Stellen Sie sicher, dass die PUT-Anfragen 1 MB/Sekunde/Shard oder 1.000 Datensätze/Shard/Sekunde nicht überschreiten. Stellen Sie sicher, dass der Partitionsschlüssel gleichmäßig verteilt und die erweiterte Überwachung aktiviert ist, um Hot Shards im Stream zu überprüfen. Aktualisieren Sie je nach Shard-Sättigung die Anzahl der Shards im Stream, um einen höheren Durchsatz zu ermöglichen.
PutRecord.Success and PutRecords.Success
PutRecord.Success und PutRecords.Success messen die Anzahl der Datensätze von erfolgreichen PutRecords-Anfragen, die Datenproduzenten über einen bestimmten Zeitraum in den Stream gesendet haben. Diese Metrik bestätigt die Effektivität der Wiederholungslogik für fehlgeschlagene Datensätze.
GetRecords.Success
GetRecords.Success misst die Anzahl erfolgreicher GetRecords-Anfragen für einen bestimmten Zeitraum im Stream. Damit wird die Effektivität der Wiederholungslogik für fehlgeschlagene Datensätze bestätigt.
GetRecords.Latency
GetRecords.Latency misst die Zeit, die in einem bestimmten Zeitraum für jede GetRecords-Operation im Stream benötigt wurde. Damit wird bestätigt, dass ausreichende physische Ressourcen oder eine ausreichende Datensatzverarbeitungslogik für einen erhöhten Stream-Durchsatz vorhanden sind. Außerdem werden so größere Datenmengen verarbeitet, um Netzwerk- und andere Downstream-Latenzen in der Anwendung zu reduzieren. Untersuchen Sie für die Kinesis Client Library (KCL) die Metrik ProcessTask.Time, um die Verarbeitungszeit der nachhinkenden Anwendung zu überwachen. Die Metrik GetRecords.Latency bestätigt, dass die Einstellung IDLE_TIME_BETWEEN_READS_IN_MILLIS so gewählt ist, dass sie mit der Stream-Verarbeitung Schritt hält.
PutRecords.Latency
PutRecords.Latency misst die Zeit, die in einem bestimmten Zeitraum für jede PutRecords-Operation im Stream benötigt wurde. Wenn der PutRecords.Latency-Wert hoch ist, aggregieren Sie Datensätze in einer größeren Datei, um Batch-Daten in den Kinesis-Datenstrom einzuspeisen. Sie können auch mehrere Threads verwenden, um Daten zu schreiben. Drosselungs und Wiederholungslogik in der PutRecords-API können sich auf die Latenz sowie auf die Zeit auswirken, die für jede PutRecords-Operation im Stream benötigt wird. Verwenden Sie dann die Statistik Durchschnitt für die aufgelisteten Metriken, um die Leistung und den Durchsatz des Streams zu überwachen.
Hinweis: Verwenden Sie für GetRecords.IteratorAgeMilliseconds die Maximum-Statistik, um das Risiko eines Datenverlusts für Konsumenten zu reduzieren, die Lesevorgängen hinterherhinken. Konfigurieren Sie einen CloudWatch-Alarm, der auf alle Datenpunkte reagiert, die für eine Metrik ausgewertet werden sollen. Weitere Informationen zu CloudWatch-Alarmen finden Sie unter Verwenden von Amazon CloudWatch-Alarmen.
Wenn Sie die Funktion für erweitertes Fan-Out verwenden, überwachen Sie Kinesis-Datenströme anhand folgender Metriken:
SubscribeToShard.RateExceeded: Misst die Anzahl der Aufrufe pro Sekunde, um die die für den Vorgang erlaubte Anzahl überschritten wurde, oder das Fehlschlagen von Abonnementversuchen, weil bereits ein aktives Abonnement besteht.
SubscribeToShard.Success: Überprüft, ob der SubscribeToShard-Vorgang erfolgreich ist.
SubscribeToShardEvent.Success: Überprüft die erfolgreiche Veröffentlichung eines Ereignisses für ein aktives Abonnement.
SubscribeToShardEvent.Bytes: Misst die Anzahl der Bytes, die über den angegebenen Zeitraum in den Shards empfangen wurden.
SubscribeToShardEvent.Records: Misst die Anzahl der Datensätze, die über den angegebenen Zeitraum in den Shards empfangen wurden.
SubscribeToShardEvent.MillisBehindLatest: Misst die Differenz zwischen der aktuellen Zeit und dem Zeitpunkt des letzten Datensatzes des SubscribeToShard-Ereignisses, der in den Stream geschrieben wurde.
Aktivieren erweiterter Metriken auf Shard-Ebene
Hinweis: Wenn bei der Ausführung von Befehlen in AWS Command Line Interface (AWS CLI) Fehler auftreten, finden Sie weitere Informationen unter Beheben von AWS CLI-Fehlern. Stellen Sie außerdem sicher, dass Sie die neueste Version von AWS CLI verwenden.
Aktivieren Sie Metriken auf Shard-Ebene in CloudWatch, um bestimmte Aufgaben zu überwachen und Probleme bei Datenproduzenten und -konsumenten zu beheben. Beispielsweise können Sie Metriken auf Shard-Ebene verwenden, um Probleme wie ungleichmäßige Workload-Verteilungen zu identifizieren. Führen Sie die folgenden Schritte aus, um die erweiterte Überwachung zu aktivieren:
Hinweis: Sie können auch die API-Anfrage EnableEnhancedMonitoring oder den AWS CLI-Befehl enable-enhanced-monitoring verwenden.
- Öffnen Sie die Kinesis-Konsole.
- Wählen Sie eine bestimmte Region aus.
- Wählen Sie im Navigationsbereich die Option Datenströme aus.
- Wählen Sie unter Name des Datenstroms Ihren Kinesis-Datenstrom aus.
- Wählen Sie Konfiguration aus.
- Wählen Sie unter Erweiterte Metriken (Shard-Ebene) die Option Bearbeiten aus.
- Wählen Sie im Dropdown-Menü Ihre Metriken für eine erweiterte Überwachung aus.
- Wählen Sie Änderungen speichern aus.
Zusätzliche Problembehandlung mit API-Aufrufen
Verwenden Sie die folgenden API-Aufrufe, um Daten aus Kinesis-Datenströmen zu lesen oder zu schreiben:
- CreateStream: Begrenzt auf 5 Transaktionen pro Sekunde pro Konto.
- DeleteStream: Begrenzt auf 5 Transaktionen pro Sekunde pro Konto.
- ListStreams: Begrenzt auf 5 Transaktionen pro Sekunde pro Konto.
- GetShardIterator: Begrenzt auf 5 Transaktionen pro Sekunde pro Konto und offenem Shard.
- MergeShards: Begrenzt auf 5 Transaktionen pro Sekunde pro Konto.
- DescribeStream: Begrenzt auf 10 Transaktionen pro Sekunde pro Konto.
- DescribeStreamSummary: Begrenzt auf 20 Transaktionen pro Sekunde pro Konto.
Wenn Sie diese API-Aufrufe verwenden, können Sie jede Drosselung in den AWS-CloudTrail-Protokollen überwachen. Weitere Informationen zu API-Aufrufen in Kinesis-Datenströmen und CloudTrail finden Sie unter Protokollieren von Amazon Kinesis Data Streams-API-Aufrufen mit AWS CloudTrail.
Verwandte Informationen
Überwachen des Amazon Kinesis Data Streams-Service mit Amazon CloudWatch
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 6 Monaten
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr