Warum wird meine Anwendung für Amazon Kinesis Data Analytics neu gestartet?

Auflösung

Wenn eine Aufgabe fehlschlägt, startet die Apache-Flink-Anwendung die fehlgeschlagene Aufgabe und andere betroffene Aufgaben neu, um den Auftrag wieder auf den normalen Stand zu bringen.

Im Folgenden sind einige der Ursachen und die entsprechenden Schritte zur Fehlerbehebung für diesen Situation aufgeführt:

• Codefehler wie NullPointer Exception und DataCast-Typ werden im Task-Manager generiert und an den Auftragsverwalter weitergeleitet. Die Anwendung wird dann vom letzten Checkpoint aus neu gestartet. Um Neustarts der Anwendung aufgrund von unbehandelten Ausnahmen zu erkennen, überprüfen Sie Amazon-CloudWatch-Metriken wie die Ausfallzeiten. Diese Metrik gibt während dem Neustart einen Wert der nicht gleich Null ist an. Um die Ursachen für diese Situation zu ermitteln, fragen Sie Ihre Anwendungsprotokolle nach Änderungen vom Anwendungsstatus von RUNNING zu FAILED ab. Weitere Informationen finden Sie unter Analyze errors: Application task-related failures (Fehler analysieren: Fehler im Zusammenhang mit Anwendungsaufgaben).

• Bei Ausnahmen wegen Speichermangel, kann der Task-Manager keine gesunden Herzklopf-Signale an den Auftragsverwalter senden, was zu einem Neustart der Anwendung führt. In diesem Fall scheinen möglicherweise Fehler wie TimeoutException, FlinkException oder RemoteTransportException in den Anwendungsprotokollen auf. Prüfen Sie, ob die Anwendung aufgrund von CPU- oder Speicherressourcen-Druck überlastet ist.

  • Stellen Sie sicher, dass die CloudWatch-Metriken fullRestarts und Ausfallzeiten Werte, die nicht gleich Null sind, aufzeigen.
  • Überprüfen Sie die Metriken cpuUtilization und heapMemoryUtilization auf ungewöhnliche Spitzenwerte.
  • Suchen Sie in Ihrem Anwendungscode nach unbehandelten Ausnahmen.
  • Prüfen Sie, ob Checkpoint- und Savepoint-Fehler vorliegen. Überwachen Sie die CloudWatch-Metriken numOFFailedCheckpoints, lastCheckpointSize und lastCheckpointDuration auf Spitzenwerte und stetige Steigerungen.
    Versuchen Sie Folgendes, um dieses Problem zu beheben:
  • Wenn Sie Debug-Protokolle für die Anwendung aktiviert haben, ist der Verbrauch an Anwendungsressourcen möglicherweise hoch. Reduzieren Sie die Protokollierung, indem Sie die Debug-Protokolle vorübergehend nur bei der Untersuchung von Problemen aktivieren.
  • Analysieren Sie den TaskManager-Thread-Dump im Dashboard von Apache Flink. Es ist zum Beispiel möglich, die CPU-intensiven Prozesse anhand des Thread-Dumps zu identifizieren.
  • Überprüfen Sie die Flammen-Diagramme, die durch mehrmaliges Abtasten der Stack-Spuren erstellt wurden Mit den Flammen-Diagrammen können Sie Folgendes tun: Den allgemeinen Anwendungszustand anzeigen, die Methoden identifizieren, die die meisten CPU-Ressourcen verbauchen, und die Reihe von Aufrufen auf dem Stack identifizieren, die zur Ausführung einer bestimmten Methode geführt haben. Suchen Sie mithilfe der Flammen-Diagramme außerhalb der CPU nach blockierten Aufrufen.

• Wenn Ihre Anwendung eine Quelle oder eine Senke unterversorgt, kann es bei Ihrer Anwendung zu Drosselungsfehlern kommen, wenn Sie Streaming-Services wie Kinesis Data Streams lesen und schreiben. Dieser Zustand kann mit der Zeit zum Absturz der Anwendung führen. Überprüfen Sie den Durchsatz für Quelle und Senke mithilfe von CloudWatch-Metriken wie WriteProvisionedThroughputExceeded und ReadProvisionedThroughputExceeded. Ziehen Sie es in Erwägung, Ihre Datenströme zu vergrößern um dem Datenvolumen gerecht zu werden, indem Sie die Anzahl der Shards erhöhen.

• Der FlinkKinesisProducer verwendet die Kinesis Producer Library (KPL), um Daten aus einem Flink-Strom in einen Kinesis-Datenstrom zu übertragen. Fehler wie Timeouts führen zu Fehlern in KPL, die möglicherweise zum Neustart der Flink-Anwendung führen können. In solchen Fällen kann es zu einer höheren Pufferzeit und zu mehr Wiederholungsversuchen kommen. Sie können die folgenden Konfigurationen für KPL so einstellen, dass der Datensatz nicht abläuft: RecordMaxBufferedTime, RecordTtl und RequestTimeout. Überwachen Sie außerdem wichtige KPL-Metriken wie ErrorsByCode, RetriesPerRecord und UserRecordsPending. Wenn diese Metriken darauf hinweisen, dass die Anwendung neu gestartet wird, verwenden Sie die Filter in CloudWatch Logs Insights, um die genauen Gründe für die Fehler zu ermitteln, die zum Neustart geführt haben.

• Beachten Sie, dass nicht alle Fehler zu einem sofortigen Neustart der Anwendung führen. Fehler im Anwendungscode können beispielsweise zu einem DAG-Workflow-Fehler führen. In diesem Fall wird der gerichtete azyklische Graph (DAG) für Ihre Anwendung nicht erstellt. Die Anwendung wird heruntergefahren und nicht sofort neu gestartet. Die Anwendung wird außerdem nicht sofort neu gestartet, wenn Sie einen „access denied“ (Zugriff verweigert)-Fehler erhalten.

Wenn das Problem weiterhin besteht, wenden Sie sich an den AWS Support und geben Sie die folgenden Informationen an:

• Anwendungs-ARN
• Informationen über die Quelle und Senke Ihrer Anwendung
• CloudWatch-Protokolle für Ihre Anwendung
• Zeitpunkt der Ausgabe in UTC
• Relevante Thread-Dumps aus dem Flink-Dashboard

Relevante Informationen

Die Anwendung wird neu gestartet