Solución de problemas y diagnóstico de errores de flujo de trabajo en Azure Logic Apps

  • Artículo

Se aplica a: Azure Logic Apps (consumo + estándar)

El flujo de trabajo de la aplicación lógica genera información que puede ayudarle a diagnosticar y depurar los problemas de la aplicación. Puede diagnosticar el flujo de trabajo revisando las entradas, salidas y otra información de cada paso del flujo de trabajo mediante el Azure Portal. O bien, puede agregar algunos pasos a un flujo de trabajo para la depuración en tiempo de ejecución.

Comprobación del historial de desencadenadores

Cada ejecución de flujo de trabajo comienza con un desencadenador, que se activa según una programación o espera una solicitud o evento entrantes. En el historial de desencadenadores se muestran todos los intentos de desencadenamiento realizados por el flujo de trabajo y la información sobre las entradas y salidas de cada intento. Si el desencadenador no se activa, pruebe los pasos siguientes.

  1. Para comprobar el estado del desencadenador en la aplicación lógica Consumo, revise el historial del desencadenador. Para ver más información sobre el intento del desencadenador, seleccione ese evento de desencadenador, por ejemplo:

    Captura de pantalla en la que se muestra Azure Portal con el historial del desencadenador de flujos de trabajo de la aplicación lógica de consumo.

  2. Compruebe las entradas del desencadenador para confirmar que aparecen según lo esperado. En el panel Historial, bajo Vínculo de entradas, seleccione el vínculo que muestra el panel Entradas.

    Las entradas del desencadenador incluyen los datos que el desencadenador espera y necesita para iniciar el flujo de trabajo. Revisar estas entradas puede ayudarle a determinar si son correctas y si se ha cumplido la condición para que el flujo de trabajo pueda continuar.

    Captura de pantalla en la que se muestran las entradas del desencadenador de flujos de trabajo de la aplicación lógica de consumo.

  3. Compruebe las salidas del desencadenador, si las hay, para confirmar que aparecen según lo esperado. En el panel Historial, en Vínculo de salidas, seleccione el vínculo que muestra el panel Salidas.

    Entre las salidas del desencadenador se incluyen los datos que el desencadenador pasa al siguiente paso del flujo de trabajo. Revisar estas salidas puede ayudarle a determinar si los valores correctos o esperados han pasado al siguiente paso del flujo de trabajo.

    Por ejemplo, un mensaje de error indica que no se encontró la fuente RSS:

    Captura de pantalla en la que se muestran las salidas del desencadenador de flujos de trabajo de la aplicación lógica de consumo.

    Sugerencia

    Si encuentra algún contenido que no reconozca, aprenda más sobre los diferentes tipos de contenido en Azure Logic Apps.

Comprobación del historial de ejecución del flujo de trabajo

Cada vez que el desencadenador se activa, Azure Logic Apps crea una instancia de flujo de trabajo y ejecuta esa instancia. Si se produce un error en una ejecución, pruebe los pasos siguientes para poder revisar lo que ha ocurrido durante esa ejecución. Puede revisar el estado, entradas y salidas de cada etapa del flujo de trabajo.

  1. Para comprobar el estado de ejecución del flujo de trabajo en la aplicación lógica Consumo, revise el historial de ejecuciones. Para ver más información sobre una ejecución con errores, incluidos todos los pasos de esa ejecución y su estado, selecciónela.

    Captura de pantalla en la que se muestra Azure Portal con ejecuciones de flujo de trabajo de la aplicación lógica de consumo y una ejecución con errores seleccionada.

  2. Una vez que aparezcan todos los pasos de la ejecución, seleccione cada paso para expandir sus formas.

    Captura de pantalla en la que se muestra el flujo de trabajo de la aplicación lógica de consumo con un paso con errores seleccionado.

  3. Revise las entradas, salidas y cualquier mensaje de error para el paso con error.

    Captura de pantalla en la que se muestra el flujo de trabajo de la aplicación lógica de consumo con los detalles del paso con errores.

    Por ejemplo, en la captura de pantalla siguiente se muestran las salidas de la acción RSS con error.

    Captura de pantalla en la que se muestra el flujo de trabajo de la aplicación lógica de consumo con las salidas del paso con errores.

Ejecución de la depuración en tiempo de ejecución

Para ayudar con la depuración, puede agregar pasos de diagnóstico a un flujo de trabajo de aplicación lógica, además de revisar el historial de desencadenadores y ejecuciones. Por ejemplo, puede agregar pasos que utilicen el servicio Webhook Tester para poder inspeccionar las solicitudes HTTP y determinar su tamaño, forma y formato exactos.

  1. En un navegador, vaya al sitio de Webhook Tester y copie la dirección URL única generada.

  2. En la aplicación lógica, añada una acción HTTP POST junto con el contenido del cuerpo que desee probar, como una expresión, la salida de otro paso.

  3. Pegue la dirección URL que se ha generado en este sitio en la acción HTTP POST.

  4. Para revisar cómo Azure Logic Apps genera y forma una solicitud, ejecute el flujo de trabajo de la aplicación lógica. A continuación, puede volver a visitar el sitio de Webhook Tester para obtener más información.

Rendimiento: preguntas frecuentes

¿Por qué la duración de la ejecución del flujo de trabajo es mayor que la suma de las duraciones de todas sus acciones?

Se produce una sobrecarga de la programación al ejecutar acciones, pero es posible que haya un tiempo de espera entre las acciones puede producirse debido a la carga del sistema back-end. La duración de la ejecución de un flujo de trabajo incluye estos tiempos de programación y tiempos de espera, junto con la suma de la duración de todas las acciones.

Normalmente, mi flujo de trabajo se completa en 10 segundos. Pero, a veces, tarda mucho más. ¿Cómo puedo asegurarme de que el flujo de trabajo siempre finaliza en 10 segundos?

  • En el Acuerdo de Nivel de Servicio no se ofrece ninguna garantía sobre la latencia.

  • Los flujos de trabajo de consumo se ejecutan en Azure Logic Apps multiinquilino, por lo que las cargas de trabajo de otros clientes podrían afectar negativamente al rendimiento del flujo de trabajo.

  • Para obtener un rendimiento más predecible, puede considerar la posibilidad de crear flujos de trabajo estándar, que se ejecutan en Azure Logic Apps de un solo inquilino. Tendrá más control para realizar el escalado horizontal o verticalmente para mejorar el rendimiento.

Una acción agota el tiempo de espera después de 2 minutos. ¿Cómo se puede aumentar el valor del tiempo de espera?

El valor de tiempo de espera de la acción no se puede cambiar y está fijo en 2 minutos. Si usa la acción HTTP y es el propietario del servicio al que llama la acción HTTP, puede cambiarlo para evitar el tiempo de espera de 2 minutos mediante el patrón asincrónico. Para más información, consulte Realización de tareas de larga duración con el patrón de acción de sondeo.

Problemas comunes: aplicaciones lógicas estándar

Artefactos inaccesibles en la cuenta de almacenamiento de Azure

Las aplicaciones lógicas estándar almacenan todos los artefactos en una cuenta de almacenamiento de Azure. Es posible que encuentre los siguientes errores si estos artefactos no son accesibles. Por ejemplo, la propia cuenta de almacenamiento podría no ser accesible, o la cuenta de almacenamiento está detrás de un firewall pero no hay ningún punto de conexión privado configurado para que los servicios de almacenamiento puedan usarlo.

Ubicación en Azure Portal Error
Panel de información general - System.private.corelib: Acceso a la ruta de acceso 'C:\home\site\wwwroot\hostj.son denegado

- Azure.Storage.Blobs: Esta solicitud no está autorizada para realizar esta operación
Panel Flujos de trabajo - No se puede acceder al runtime del host. Detalles del error, Código: "BadRequest", Mensaje: "Se encontró un error (InternalServerError) desde el runtime del host".

- No se puede acceder al runtime del host. Detalles del error, Código: "BadRequest", Mensaje: "Se encontró un error (ServiceUnavailable) desde el runtime del host".

- No se puede acceder al runtime del host. Detalles del error, Código: "BadRequest", Mensaje: "Se encontró un error (BadGateway) desde el runtime del host".
Durante la creación y ejecución del flujo de trabajo - No se pudo guardar el flujo de trabajo

- Error en el diseñador: GetCallFailed. Operaciones de captura erróneas

- Error en la llamada ajaxExtended

Opciones para la solución de problemas

En la lista siguiente se incluyen posibles causas de estos errores y pasos para ayudar a solucionar problemas.

  • En el caso de una cuenta de almacenamiento pública, compruebe el acceso a la cuenta de almacenamiento de las siguientes maneras:

    Si se produce un error en la conectividad, compruebe si la clave firma de acceso compartido (SAS) de la cadena de conexión es la más reciente.

  • En el caso de una cuenta de almacenamiento que está detrás de un firewall, compruebe el acceso a la cuenta de almacenamiento de las siguientes maneras:

    • Si las restricciones de firewall están habilitadas en la cuenta de almacenamiento, compruebe si los puntos de conexión privados están configurados para los servicios de almacenamiento Blob, File, Table y Queue.

    • Compruebe la conectividad de la cuenta de almacenamiento mediante Explorador de Azure Storage.

    Si se encuentra con problemas de conectividad, siga los siguientes pasos:

    1. En la misma red virtual que está integrada con la aplicación lógica, cree una máquina virtual de Azure, que puede colocar en una subred diferente.

    2. Desde un símbolo del sistema, ejecute nslookup para comprobar que los servicios de almacenamiento Blob, File, Table y Queue Storage se resuelven en las direcciones IP esperadas.

      Sintaxis: nslookup [StorageaccountHostName] [OptionalDNSServer]

      Blob: nslookup {StorageaccountName}.blob.core.windows.net

      File: nslookup {StorageaccountName}.file.core.windows.net

      Table: nslookup {StorageaccountName}.table.core.windows.net

      Queue: nslookup {StorageaccountName}.queue.core.windows.net

      • Si el servicio de almacenamiento tiene un punto de conexión de servicio, el servicio se resuelve en una dirección IP pública.

      • Si el servicio de almacenamiento tiene un punto de conexión privado, el servicio se resuelve en las direcciones IP privadas correspondientes del controlador de interfaz de red (NIC).

    3. Si las consultas anteriores del servidor de nombres de dominio (DNS) se resuelven correctamente, ejecute los comandos psping o tcpping para comprobar la conectividad con la cuenta de almacenamiento a través del puerto 443:

      Sintaxis: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

      Blob: psping {StorageaccountName}.blob.core.windows.net:443

      File: psping {StorageaccountName}.file.core.windows.net:443

      Table: psping {StorageaccountName}.table.core.windows.net:443

      Queue: psping {StorageaccountName}.queue.core.windows.net:443

    4. Si cada servicio de almacenamiento se puede resolver desde la máquina virtual de Azure, busque el DNS que usa la máquina virtual para la resolución.

      1. Establezca el valor de aplicación WEBSITE_DNS_SERVER de la aplicación lógica en el DNS y confirme que el DNS funciona correctamente.

      2. Compruebe que la integración de VNET está configurada correctamente con la red virtual y la subred adecuadas en la aplicación lógica Estándar.

    5. Si usa zonas DNS privadas de Azure para los servicios de punto de conexión privado de la cuenta de almacenamiento, compruebe que se ha creado un vínculo de red virtual a la red virtual integrada de la aplicación lógica.

Para más información, consulte Implementación de una aplicación lógica Estándar en una cuenta de almacenamiento detrás de un firewall mediante puntos de conexión privados o de servicio.

Pasos siguientes