對 Step Functions 中的問題進行故障診斷

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

如果您在使用 Step Functions 時遇到困難，請使用下列疑難排解資源。

下列主題提供與 Step Functions 狀態機器、服務整合、活動和工作流程相關的錯誤和問題的疑難排解建議。如果您發現未列在此處的問題，您可以使用此頁面上的 Feedback (意見回饋) 按鈕來報告。

如需更多故障診段建議和常見支援問題的解答，請瀏覽 AWS 知識中心。

一般性問題的故障診斷

我無法建立狀態機器。

與狀態機器相關聯的 IAM 角色可能沒有足夠的許可。檢查 IAM 角色的許可，包括 AWS 服務整合任務、X-Ray 和 CloudWatch 記錄。.sync 任務狀態需要其他許可。

我無法使用 JsonPath 來參考上一個任務的輸出。

對於 JsonPath，JSON 金鑰必須以 結尾.$。這表示 JsonPath 只能用於鍵值對。如果您想要使用 JsonPath 其他地方，例如陣列，您可以使用內部函數。例如，您可以使用類似下列內容：

任務 A 輸出：

{
    "sample": "test"
}

任務 B：

{
    "JsonPathSample.$": "$.sample"
}

狀態轉換發生延遲。

對於標準工作流程，狀態轉換的數量有限制。當您超過狀態轉換限制時，Step Functions 會延遲狀態轉換，直到配額的儲存貯體填滿為止。檢閱 CloudWatch ExecutionThrottled 指標頁面的 執行指標區段中的指標，即可監控狀態轉換限制限流。

當我啟動新的標準工作流程執行時，它們會失敗並出現ExecutionLimitExceeded錯誤。

Step Functions 對每個 AWS 帳戶 中的每個 都有 1，000，000 個開放執行的限制 AWS 區域。如果您超過此限制，Step Functions 會擲出ExecutionLimitExceeded錯誤。此限制不適用於 Express Workflows。您可以使用 OpenExecutionCount來追蹤何時接近 ，OpenExecutionLimit並建立警示，以便在該事件中主動通知您。 OpenExecutionCount是開啟的工作流程的大約數量。如需詳細資訊，請參閱執行指標。

一個分支在平行狀態下失敗會導致整個執行失敗。

這是預期的行為。為了避免在使用平行狀態時遇到失敗，請設定 Step Functions 以擷取從每個分支擲出的錯誤。

對服務整合進行故障診斷

我的任務在下游服務中完成，但在 Step Functions 中，任務狀態會保持「進行中」或延遲完成。

對於.sync服務整合模式，Step Functions 使用 EventBridge 規則、下游 APIs 或兩者的組合來偵測下游任務狀態。對於某些服務，Step Functions 不會建立 EventBridge 規則來監控。例如，對於 AWS Glue 服務整合， Step Functions 會glue:GetJobRun呼叫 ，而不是使用 EventBridge 規則。由於 API 呼叫的頻率，下游任務完成與 Step Functions 任務完成時間之間存在差異。Step Functions 需要 IAM 許可來管理 EventBridge 規則，以及呼叫下游服務。如需執行角色的許可不足如何影響任務完成的詳細資訊，請參閱 使用 .sync 的任務的其他許可。

我想要從巢狀狀態機器執行傳回 JSON 輸出。

Step Functions 有兩個 Step Functions 同步服務整合： startExecution.sync和 startExecution.sync:2。兩者都等待巢狀狀態機器完成，但會傳回不同的Output格式。您可以使用 startExecution.sync:2 來傳回 下的 JSON 輸出Output。

我無法從另一個帳戶叫用 Lambda 函數。

使用跨帳戶支援存取 Lambda 函數

如果您的 區域可以使用跨帳戶存取 AWS 資源，請使用下列方法從另一個帳戶叫用 Lambda 函數。

若要在工作流程中叫用跨帳戶資源，請執行下列動作：

如需範例，請參閱教學在 Step Functions 中存取跨帳戶 AWS 資源課程中的 。

如需指定跨帳戶資源Task的狀態定義範例，請參閱任務狀態的登入資料欄位範例。

在沒有跨帳戶支援的情況下存取 Lambda 函數

如果您的區域無法使用跨帳戶存取 AWS 資源，請使用下列方法從另一個帳戶叫用 Lambda 函數。

在 Task 狀態的 Resource欄位中，使用 arn:aws:states:::lambda:invoke並在 參數FunctionArn中傳遞 。與狀態機器相關聯的 IAM 角色必須具有適當的許可，才能叫用跨帳戶 Lambda 函數：lambda:invokeFunction。

{  
   "StartAt":"CallLambda",
   "States":{  
      "CallLambda":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:us-west-2:123456789012:function:my-function"
         },
         "End":true
      }
   }
}

我看不到從.waitForTaskToken狀態傳遞的任務權杖。

在 Task 狀態的 Parameters欄位中，您必須傳遞任務字符。例如，您可以使用類似下列程式碼的內容。

{  
   "StartAt":"taskToken",
   "States":{  
      "taskToken":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
         "Parameters":{  
            "FunctionName":"get-model-review-decision",
            "Payload":{  
               "token.$":"$$.Task.Token"
            },
         },
         "End":true
      }
   }
}

對活動進行故障診斷

我的狀態機器執行卡在活動狀態。

在您使用 GetActivityTask API 動作輪詢任務權杖之前，活動任務狀態不會啟動。最佳實務是新增任務層級逾時，以避免執行卡住。如需詳細資訊，請參閱使用逾時以避免停滯的 Step Functions 工作流程執行。

如果您的狀態機器卡在 ActivityScheduled 事件中，則表示您的活動工作者機群有問題或規模不足。您應該監控 ActivityScheduleTime CloudWatch 指標，並在該時間增加時設定警示。不過，若要逾時Activity狀態未轉換為 ActivityStarted 狀態的任何停滯狀態機器執行，請在狀態機器層級定義逾時。若要執行此操作，請在TimeoutSeconds欄位外的狀態機器定義開頭指定States欄位。

我的活動工作者在等待任務字符時逾時。

工作者使用 GetActivityTask API 動作來擷取由執行中狀態機器排程執行之指定活動 ARN 的任務。 會GetActivityTask啟動長輪詢，因此服務會保持 HTTP 連線開啟，並在任務可用時立即回應。服務在回應前保留請求的時間上限為 60 秒。如果 60 秒內沒有可用的任務，輪詢會傳回taskToken具有 null 字串的 。若要避免此逾時，請在 AWS SDK 或用來進行 API 呼叫的用戶端中，設定逾時至少為 65 秒的用戶端端通訊端。

快速工作流程疑難排解

我的應用程式在收到 StartSyncExecution API 呼叫的回應之前逾時。

在 AWS SDK 中設定用戶端通訊端逾時，或設定用於進行 API 呼叫的用戶端。若要接收回應，逾時的值必須高於快速工作流程執行的持續時間。

我看不到執行歷史記錄，無法對快速工作流程失敗進行故障診斷。

Express Workflows 不會記錄其中的執行歷史記錄 AWS Step Functions。反之，您必須開啟 CloudWatch 記錄。開啟記錄後，您可以使用 CloudWatch Logs Insights 查詢來檢閱您的 Express Workflow 執行。如果您在執行標籤中選擇啟用按鈕，您也可以在 Step Functions 主控台上檢視快速工作流程執行的執行歷史記錄。如需詳細資訊，請參閱在 Step Functions 主控台中檢視執行詳細資訊。

若要根據持續時間列出執行：

fields ispresent(execution_arn) as exec_arn
| filter exec_arn 
| filter type in ["ExecutionStarted", "ExecutionSucceeded", "ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]
| stats latest(type) as status, 
  tomillis(earliest(event_timestamp)) as UTC_starttime, 
  tomillis(latest(event_timestamp)) as UTC_endtime, 
  latest(event_timestamp) - earliest(event_timestamp) as duration_in_ms  by execution_arn
| sort duration_in_ms desc

若要列出失敗和已取消的執行：

fields ispresent(execution_arn) as isRes | filter type in ["ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]