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

上次更新日期:2022 年 3 月 2 日

我的 Amazon Kinesis Data Analytics for Apache Flink 應用程式正在重新啟動。

解決方案

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

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

  • 代碼錯誤 (如 NullPointer 異常和 DataCast 類型) 在任務管理員中產生,並且昇至任務管理員。應用程式隨後會從最新的檢查點重新啟動。要偵測應用程式是否因應用程式中未處理的異常而重新啟動,請檢查 Amazon CloudWatch 指標 (例如 downtime)。此指標在重新啟動期間顯示非零值。要確定造成此情況的原因,請查詢應用程式日誌中的應用程式狀態是否從「運行中」變更為「失敗」。有關詳細資訊,請參閲分析錯誤:與應用程式任務相關的故障
  • 當出現記憶體不足異常時,工作管理員無法向作業管理員發送正常的活動訊號,進而導致應用程式重新啟動。在此情況下,您可能會在應用程式日誌中看到錯誤,例如 TimeoutException、FlinkException 或是 RemoteTransportException。檢查應用程式是否由於 CPU 或記憶體資源壓力而超載。
    • 請確定 CloudWatch 指標 fullRestartsdowntime 為非零值。
    • 檢查指標 cpuUtilizationheapMemoryUtilization 是否突然異常增加。
    • 檢查應用程式程式碼中是否有未處理的異常。
    • 檢查檢查點和保存點故障。監控 CloudWatch 指標 numOFFailedCheckpointslastCheckpointSizelastCheckpointDuration 的峰值與穩定增加。
      若要解決此問題,請嘗試以下操作:
    • 如果已為應用程式啟用偵錯日誌,則應用程式資源的耗用可能會很高。透過僅在調查問題時暫時啟用偵錯日誌來減少記錄量。
    • 分析 Apache Flink 儀表板中的 TaskManager 執行緒轉儲。例如,您可以從執行緒轉儲中識別 CPU 密集型進程。
    • 查看透過堆疊追踪進行多次採樣所構建的火焰圖。您可以使用火焰圖來執行以下操作:可視化整體應用程式運作狀態,確定消耗最多 CPU 資源的方法,以及識別導致執行特定方法的堆疊上的呼叫系列。使用 off-CPU 火焰圖檢查被封鎖的呼叫。
  • 如果您的應用程式未充分佈建來源或接收,則在讀取和寫入串流服務 (如 Kinesis Data Streams) 時,應用程式可能會遇到調節錯誤。這種情況最終可能導致應用程式當機。使用 CloudWatch 指標 (例如 WriteProvisionedThroughputExceededReadProvisionedThroughputExceeded) 檢查來源和接收的輸送量。考慮透過增碎片數目的方式擴充資料串流規模以容納資料量。
  • FlinkKinesisProducer 使用 Kinesis Producer Library (KPL) 將 Fink 串流中的資料放入 Kinesis 資料串流中。錯誤 (如逾時) 會導致 KPL 中的故障,最終可能導致 Fink 應用程式重新啟動。如果發生此情況,您可能會看到緩衝時間和重試次數的增加。您可以透過記錄不會過期的方式調整 KPL 的以下組態RecordMaxBufferedTimeRecordTtlRequestTimeout。同時,也可監控重要的 KPL 指標,例如 ErrorsByCodeRetriesPerRecordUserRecordsPending。當這些指標指出應用程式正在重新啟動時,請使用 CloudWatch Logs Insights 中的篩選條件瞭解導致出現重新啟動錯誤的確切原因。
  • 請注意,並非所有錯誤都會導致應用程式立即重新啟動。例如,應用程式程式碼中的錯誤可能會導致 DAG 工作流程錯誤。在這種情況下,不會建立應用程式的有向無環圖 (DAG)。應用程式將關閉,不會立即重新啟動。此外,當您收到「存取遭拒」錯誤時,應用程式不會立即重新啟動。

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

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

此文章是否有幫助?


您是否需要帳單或技術支援?