為什麼我的 Amazon Kinesis Data Analytics 應用程式會重新啟動？

解決方案

當任務失敗時，Apache Fink 應用程式將重新啟動失敗的任務和其他受影響的任務，以使作業處於正常狀態。

以下是這種情況的部分原因和相應的故障排除步驟：

• 代碼錯誤 (如 NullPointer 異常和 DataCast 類型) 在任務管理員中產生，並且昇至任務管理員。應用程式隨後會從最新的檢查點重新啟動。要偵測應用程式是否因應用程式中未處理的異常而重新啟動，請檢查 Amazon CloudWatch 指標 (例如 downtime)。此指標在重新啟動期間顯示非零值。要確定造成此情況的原因，請查詢應用程式日誌中的應用程式狀態是否從「運行中」變更為「失敗」。有關詳細資訊，請參閲分析錯誤：與應用程式任務相關的故障。

• 當出現記憶體不足異常時，工作管理員無法向作業管理員發送正常的活動訊號，進而導致應用程式重新啟動。在此情況下，您可能會在應用程式日誌中看到錯誤，例如 TimeoutException、FlinkException 或是 RemoteTransportException。檢查應用程式是否由於 CPU 或記憶體資源壓力而超載。

  • 請確定 CloudWatch 指標 fullRestarts 和 downtime 為非零值。
  • 檢查指標 cpuUtilization 和 heapMemoryUtilization 是否突然異常增加。
  • 檢查應用程式程式碼中是否有未處理的異常。
  • 檢查檢查點和保存點故障。監控 CloudWatch 指標 numOFFailedCheckpoints、lastCheckpointSize 和 lastCheckpointDuration 的峰值與穩定增加。
    若要解決此問題，請嘗試以下操作：
  • 如果已為應用程式啟用偵錯日誌，則應用程式資源的耗用可能會很高。透過僅在調查問題時暫時啟用偵錯日誌來減少記錄量。
  • 分析 Apache Flink 儀表板中的 TaskManager 執行緒轉儲。例如，您可以從執行緒轉儲中識別 CPU 密集型進程。
  • 查看透過堆疊追踪進行多次採樣所構建的火焰圖。您可以使用火焰圖來執行以下操作：可視化整體應用程式運作狀態，確定消耗最多 CPU 資源的方法，以及識別導致執行特定方法的堆疊上的呼叫系列。使用 off-CPU 火焰圖檢查被封鎖的呼叫。

• 如果您的應用程式未充分佈建來源或接收，則在讀取和寫入串流服務 (如 Kinesis Data Streams) 時，應用程式可能會遇到調節錯誤。這種情況最終可能導致應用程式當機。使用 CloudWatch 指標 (例如 WriteProvisionedThroughputExceeded 和 ReadProvisionedThroughputExceeded) 檢查來源和接收的輸送量。考慮透過增碎片數目的方式擴充資料串流規模以容納資料量。

• FlinkKinesisProducer 使用 Kinesis Producer Library (KPL) 將 Fink 串流中的資料放入 Kinesis 資料串流中。錯誤 (如逾時) 會導致 KPL 中的故障，最終可能導致 Fink 應用程式重新啟動。如果發生此情況，您可能會看到緩衝時間和重試次數的增加。您可以透過記錄不會過期的方式調整 KPL 的以下組態：RecordMaxBufferedTime、RecordTtl 和 RequestTimeout。同時，也可監控重要的 KPL 指標，例如 ErrorsByCode、RetriesPerRecord 和 UserRecordsPending。當這些指標指出應用程式正在重新啟動時，請使用 CloudWatch Logs Insights 中的篩選條件瞭解導致出現重新啟動錯誤的確切原因。

• 請注意，並非所有錯誤都會導致應用程式立即重新啟動。例如，應用程式程式碼中的錯誤可能會導致 DAG 工作流程錯誤。在這種情況下，不會建立應用程式的有向無環圖 (DAG)。應用程式將關閉，不會立即重新啟動。此外，當您收到「存取遭拒」錯誤時，應用程式不會立即重新啟動。

如果問題仍然存在，請聯絡 AWS Support 並提供以下資訊：

• 應用程式 ARN
• 有關應用程式來源和接收的資訊
• 適用於您的應用程式的 CloudWatch 日誌
• 以 UTC 表示的發佈時間
• Fink 儀表板中的相關執行緒轉儲

相關資訊

應用程式正在重新啟動