Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas de Step Functions

Si surgen problemas a la hora de trabajar con Step Functions, utilice los siguientes recursos.

Los temas siguientes proporcionan consejos para solucionar problemas de errores y problemas que puedan surgir relacionados con las máquinas de estado de Step Functions, las integraciones de servicios, las actividades y los flujos de trabajo. Si se encuentra con un problema que no aparezca en esta lista, puede utilizar el botón Comentarios de esta página para notificarlo.

Para obtener más consejos sobre la resolución de problemas y respuestas a preguntas comunes de soporte, visite el Centro de conocimientos de AWS.

Solución de problemas generales

No puedo crear una máquina de estado.

Es posible que el rol de IAM asociado a la máquina de estado no tenga permisos suficientes. Compruebe los permisos del rol de IAM, incluso para las tareas AWS de integración de servicios y el CloudWatch registro. X-Ray Se requieren permisos adicionales para los estados de las tareas de estado de .sync.

No puedo usar a para JsonPath hacer referencia al resultado de la tarea anterior.

En el caso de a JsonPath, una clave JSON debe terminar en.$. Esto significa que a solo se JsonPath puede usar en un par clave-valor. Si desea utilizar JsonPath otros lugares, como una matriz, puede utilizar funciones intrínsecas. Por ejemplo, puede utilizar algo similar a lo siguiente:

Salida de tarea A:

{
    "sample": "test"
}

Tarea B:

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

Se produjo un retraso en las transiciones de estado.

Para los flujos de trabajo estándar hay un límite en el número de transiciones de estado. Cuando supera el límite de transiciones de estado, Step Functions retrasa las transiciones de estado hasta que se llene el bucket de la cuota. La regulación de los límites de transición de estado se puede monitorear revisando la ExecutionThrottled métrica en la Métricas de ejecución sección de la página de CloudWatch métricas.

Cuando inicio nuevas ejecuciones de flujos de trabajo estándar se produce un error de ExecutionLimitExceeded.

Step Functions tiene un límite de 1 000 000 de ejecuciones abiertas para cada una Cuenta de AWS de ellas. Región de AWS Si supera este límite, Step Functions lanza un error de ExecutionLimitExceeded. Este límite no se aplica a los flujos de trabajo rápidos. Puede utilizar OpenExecutionCount para hacer un seguimiento de cuándo se acerca al OpenExecutionLimit y crear alarmas que le notifiquen de forma proactiva en ese caso. OpenExecutionCount es un número aproximado de flujos de trabajo abiertos. Para obtener más información, consulte Métricas de ejecución.

Un error en una rama en estado paralelo provoca un error en toda la ejecución.

Este es el comportamiento esperado. Para evitar errores al utilizar un estado paralelo, configure Step Functions para detectar los errores lanzados desde cada rama.

Solución de problemas de integración de servicios

Mi trabajo está finalizado en el servicio descendente, pero en Step Functions el estado de la tarea sigue siendo "En curso" o su finalización se retrasa.

Para los patrones de integración de .sync servicios, Step Functions utiliza EventBridge reglas, API descendentes o una combinación de ambas para detectar el estado del trabajo posterior. Para algunos servicios, Step Functions no crea EventBridge reglas de supervisión. Por ejemplo, para la integración AWS Glue de servicios, en lugar de utilizar EventBridge reglas, Step Functions realiza una glue:GetJobRun llamada. Dada la frecuencia de las llamadas a la API, hay una diferencia entre la finalización de tareas descendentes y el tiempo de finalización de tareas de Step Functions. Step Functions requiere permisos de IAM para gestionar las EventBridge reglas y realizar llamadas al servicio descendente. Para obtener más información sobre cómo la falta de permisos en su rol de ejecución puede afectar a la finalización de las tareas, consulte Permisos adicionales para las tareas que utilizan .sync.

Quiero devolver una salida de JSON desde una ejecución de máquina de estado anidada.

Hay dos integraciones de servicios síncronos de Step Functions para Step Functions: startExecution.sync y startExecution.sync:2. Ambos esperan a que se complete la máquina de estado anidada, pero devuelven diferentes formatos Output. Puede utilizar startExecution.sync:2 para devolver una salida de JSON en Output.

No puedo invocar una función de Lambda desde otra cuenta.

Acceder a la función de Lambda con compatibilidad entre cuentas

Si el acceso a los AWS recursos entre cuentas está disponible en su región, utilice el siguiente método para invocar una función Lambda desde otra cuenta.

Para invocar un recurso entre cuentas en los flujos de trabajo, haga lo siguiente:

Consulte Acceso a AWS recursos multicuenta en Step Functions en los tutoriales para ver un ejemplo.

Para ver un ejemplo de una definición de estado de Task que especifica un recurso multicuenta, consulte Ejemplos del campo Credentials de estado de tarea.

Acceder a la función de Lambda sin compatibilidad entre cuentas

Si el acceso a los AWS recursos entre cuentas no está disponible en su región, utilice el siguiente método para invocar una función Lambda desde otra cuenta.

En el campo Resource del estado de Task, utilice arn:aws:states:::lambda:invoke y pase el FunctionArn en parámetros. El rol de IAM asociado a la máquina de estado debe tener los permisos adecuados para invocar funciones de Lambda entre cuentas: lambda:invokeFunction.

{  
   "StartAt":"CallLambda",
   "States":{  
      "CallLambda":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:region:account-id:function:my-function"
         },
         "End":true
      }
   }
}

No puedo ver los tokens de tareas transferidos desde los estados de .wait. ForTaskToken

En el campo Parameters del estado de Task, debes pasar un token de tarea. Por ejemplo, puede utilizar algo similar al código siguiente.

{  
   "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
      }
   }
}

Solución de problemas de actividades

La ejecución de mi máquina de estado está bloqueada en un estado de actividad.

El estado de una tarea de actividad no comienza hasta que se sondea un token de tarea mediante la acción de la GetActivityTaskAPI. Se recomienda añadir un tiempo de espera de nivel de tarea para evitar que la ejecución se bloquee. Para obtener más información, consulte Uso de tiempos de espera para evitar las ejecuciones bloqueadas del flujo de trabajo de Step Functions.

Si tu máquina de estados se bloquea durante el ActivityScheduledevento, esto indica que tu flota de trabajadores en actividad tiene problemas o está infradimensionada. Deberías monitorear la ActivityScheduleTime CloudWatch métrica y configurar una alarma cuando ese tiempo aumente. Sin embargo, para agotar el tiempo de espera de ejecuciones de máquina de estado bloqueadas en las que el estado Activity no pase al estado ActivityStarted, defina un tiempo de espera de nivel de máquina de estado. Para ello, especifique un campo TimeoutSeconds al principio de la definición de máquina de estado, fuera del campo States.

Mi proceso de trabajo de actividad agota el tiempo de espera mientras espera un token de tarea.

Los trabajadores utilizan la acción de la GetActivityTaskAPI para recuperar una tarea con el ARN de actividad especificado cuya ejecución está programada para ser ejecutada por una máquina de estado en ejecución. GetActivityTaskinicia un sondeo largo para que el servicio mantenga abierta la conexión HTTP y responda en cuanto haya una tarea disponible. El tiempo máximo que el servicio retiene la solicitud antes de responder es de 60 segundos. Si no hay ninguna tarea disponible en 60 segundos, el sondeo devuelve un taskToken con una cadena nula. Para evitar este tiempo de espera, configura un socket del lado del cliente con un tiempo de espera de al menos 65 segundos en el AWS SDK o en el cliente que utilices para realizar la llamada a la API.

Solución de problemas de flujos de trabajo rápidos

Se agota el tiempo de espera de mi aplicación antes de recibir una respuesta de un StartSyncExecutionLlamada a la API.

Configura un tiempo de espera del socket del lado del cliente en el AWS SDK o en el cliente que utilices para realizar la llamada a la API. Para recibir una respuesta, el tiempo de espera debe tener un valor superior a la duración de las ejecuciones de flujos de trabajo rápidos.

No puedo ver el historial de ejecuciones para solucionar los errores de flujos de trabajo rápidos.

Los flujos de trabajo rápidos no registran el historial de ejecuciones en AWS Step Functions. En su lugar, debes activar el CloudWatch registro. Una vez activado el registro, puede utilizar las consultas de CloudWatch Logs Insights para revisar las ejecuciones de Express Workflow. También puede ver el historial de ejecuciones de flujos de trabajo rápidos en la consola de Step Functions si selecciona el botón Habilitar de la pestaña Ejecuciones. Para obtener más información, consulte Visualización de los detalles de ejecución en la consola de Step Functions.

Para mostrar las ejecuciones en función de su duración:

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

Para mostrar ejecuciones con error y canceladas:

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

Solución de problemas de mapas distribuidos

La ejecución de mi mapa está bloqueada.

Hay una cuota de servicio para el número máximo de ejecuciones de mapas abiertos. Una vez agotada esta cuota, las ejecuciones de mapas adicionales esperan a que haya más cuotas disponibles a medida que se completen otras ejecuciones de mapas. Las partidas de mapa pendientes esperan al momento del MapRunStarted evento antes de leer las entradas. De este modo, verás que el recuento de elementos pendientes de la tirada sigue siendo 0. Una vez que una ejecución de mapa pendiente consiga alcanzar una cuota, empezará a leer los datos introducidos. A continuación, verás cómo aumenta el número de elementos pendientes y la ejecución del mapa continuará con normalidad durante el resto de su ciclo de vida. A medida que la cuota esté disponible, no habrá un orden concreto en cuanto a cómo se distribuirá entre las tiradas de mapas pendientes.

Existe el riesgo de que se produzca un punto muerto cuando se utilizan secuencias de mapas anidadas. En esta situación, tiene una ejecución de flujo de trabajo principal que contiene una ejecución de mapa «principal», que a su vez inicia una ejecución de flujo de trabajo secundaria que contiene una ejecución de mapa «secundaria», que a su vez inicia una ejecución de flujo de trabajo secundaria. Si no queda ninguna cuota máxima de ejecuciones de mapa abiertas cuando la ejecución del flujo de trabajo secundario inicie la ejecución del mapa secundario, la ejecución de ese mapa secundario quedará pendiente. Si las ejecuciones del mapa principal consumen toda la cuota y todas las ejecuciones del mapa secundario están pendientes, ninguno de los grupos podrá avanzar y permanecerán bloqueados hasta que la cuota vuelva a estar disponible. La ejecución de un mapa se abortará y su cuota volverá a estar disponible cuando finalice la ejecución principal, por ejemplo, si se agota el tiempo de espera, si se produce un error no detectado o debido a una llamada a la API. StopExecution

Al considerar la posibilidad de utilizar corridas de mapas anidadas en el diseño de su flujo de trabajo, calcule si el número previsto de ejecuciones de mapas abiertos podría superar la cuota máxima de ejecuciones de mapas abiertos y correr el riesgo de sufrir retrasos o bloqueos. Si es así, puede considerar diseños alternativos. Por ejemplo, en lugar de utilizar una ejecución de mapa principal para recorrer en iteración una lista de objetos de Amazon S3 y una ejecución de mapa secundaria para leer su contenido, podría utilizar la LOAD_AND_FLATTENtransformación de la ejecución de su mapa ReaderConfig para realizar ambas operaciones en una sola ejecución de mapa. Otro patrón común consiste en incluir un paso de preprocesamiento, como una función Lambda, que itera sobre los datos anidados y produce un archivo que se puede utilizar como entrada de la ejecución del mapa.

Puede supervisar el uso que hace de la cuota máxima de ejecuciones de mapas abiertos utilizando las métricas ApproximateOpenMapRunCountOpenMapRunLimit, y. ApproximateMapRunBacklogSize CloudWatch