Compartir a través de

在 Azure 逻辑应用中排查和诊断工作流故障

适用范围:Azure 逻辑应用(消耗型 + 标准型)

逻辑应用工作流生成的信息有助于诊断和调试应用中的问题。 可以使用 Azure 门户查看工作流中每个步骤的输入、输出和其他信息,以此诊断工作流。 或者,可以在工作流中增加一些步骤进行运行时调试。

检查触发历史记录

每个工作流运行都以触发器开头,触发器会按计划触发或等待传入的请求或事件。 触发历史记录列出工作流做出的所有触发尝试,以及有关每次触发尝试的输入和输出的信息。 如果触发器未触发,请尝试执行以下步骤。

  1. 若要在“消耗”逻辑应用中查看触发器的状态,请查看触发器历史记录。 若要查看有关触发尝试的详细信息,请选择该触发事件,例如:

    Screenshot showing Azure portal with Consumption logic app workflow trigger history.

  2. 检查触发器的输入,确认它们按预期方式显示。 在“历史记录”窗格的“输入链接”下,选择显示“输入”窗格的链接。

    触发器输入包括启动工作流时触发器预期需要的数据。 检查这些输入有助于确定触发器输入是否正确,以及是否满足条件,使工作流能够继续。

    Screenshot showing Consumption logic app workflow trigger inputs.

  3. 检查触发器的输出(如果有),确认它们按预期方式显示。 在“历史记录”窗格的“输出链接”下,选择显示“输出”窗格的链接。

    触发器输出包括触发器传递给工作流中下一步骤的数据。 查看这些输出可以帮助你确定是否将正确或预期的值传递到了工作流中的下一个步骤。

    例如,错误消息指出找不到 RSS 源:

    Screenshot showing Consumption logic app workflow trigger outputs.

    提示

    如果发现有任何无法识别的内容,请详细了解 Azure 逻辑应用中不同的内容类型

查看工作流运行历史记录

每次触发时,Azure 逻辑应用都会创建一个工作流实例并运行该实例。 如果运行失败,请尝试以下步骤,以便查看该运行过程中发生了什么。 可以查看工作流中每个步骤的状态、输入和输出。

  1. 若要在“消耗”逻辑应用中查看工作流的运行状态,请查看运行历史记录。 若要查看有关某个失败运行的详细信息(包括该运行中的步骤及其状态),请选择该运行。

    Screenshot showing Azure portal with Consumption logic app workflow runs and a failed run selected.

  2. 待运行中的所有步骤都显示后,选择每个步骤以展开其形状。

    Screenshot showing Consumption logic app workflow with failed step selected.

  3. 查看失败步骤的输入、输出和任何错误消息。

    Screenshot showing Consumption logic app workflow with failed step details.

    例如,以下屏幕截图显示了失败的 RSS 操作的输出。

    Screenshot showing Consumption logic app workflow with failed step outputs.

执行运行时调试

若要帮助进行调试,可向逻辑应用工作流添加诊断步骤,同时查看触发器和运行历史记录。 例如,可以添加使用 Webhook Tester 服务的步骤,以便可检查 HTTP 请求并确定其确切大小、形状和格式。

  1. 在浏览器中转到 Webhook Tester 站点并复制生成的唯一 URL。

  2. 在逻辑应用中,添加包含想要测试的正文内容的 HTTP POST 操作(例如,某个表达式或另一个步骤的输出)。

  3. 将 Webhook Tester 中的 URL 粘贴到该 HTTP POST 操作中。

  4. 若要查看 Azure 逻辑应用如何生成和形成请求,请运行逻辑应用工作流。 然后,可以重新访问 Webhook Tester 网站以获取详细信息。

性能 - 常见问题解答 (FAQ)

为什么工作流运行持续时间长于所有工作流操作持续时间的总和?

运行操作时存在计划开销,而由于后端系统负载,操作之间可能存在等待时间。 工作流运行持续时间包括这些计划时间和等待时间以及所有操作持续时间的总和。

通常,我的工作流会在 10 秒内完成。 但有时可能需要更长时间才会完成。 如何确保工作流始终在 10 秒内完成?

  • 不存在有关延迟的 SLA 保证。

  • 消耗型工作流在多租户 Azure 逻辑应用上运行,因此其他客户的工作负载可能会对工作流的性能产生负面影响。

  • 若要获得更可预测的性能,可以考虑创建标准工作流,这些工作流在单租户 Azure 逻辑应用中运行。 你可以更好地控制纵向扩展或横向扩展以提高性能。

我的操作在 2 分钟后超时。 如何增加超时值?

操作超时值无法更改,固定为 2 分钟。 如果使用的是 HTTP 操作,并且拥有 HTTP 操作调用的服务,则可以使用异步模式更改服务以避免 2 分钟的超时。 有关详细信息,请查看使用轮询操作模式执行长时间运行的任务

常见问题 - 标准逻辑应用

Azure 存储帐户中不可访问的项目

标准逻辑应用将所有项目存储在 Azure 存储帐户中。 如果这些项目无法访问,可能会显示以下错误。 例如,存储帐户本身可能无法访问,或者存储帐户位于防火墙后面但没有为要使用的存储服务设置专用终结点。

Azure 门户位置 错误
“概述”窗格 - System.private.corelib:对路径 'C:\home\site\wwwroot\hostj.son 的访问被拒绝

- Azure.Storage.Blobs: 此请求无权执行此操作
“工作流”窗格 - 无法访问主机运行时。错误详细信息,代码: ''BadRequest'',消息: ''在主机运行时 (InternalServerError) 遇到错误。''

- 无法访问主机运行时。错误详细信息,代码: ''BadRequest'',消息: ''在主机运行时 (ServiceUnavailable) 遇到错误。''

- 无法访问主机运行时。错误详细信息,代码: ''BadRequest'',消息: ''在主机运行时 (BadGateway) 遇到错误。''
在工作流创建和执行期间 - 未能保存工作流

- 设计器中的错误: GetCallFailed。提取操作失败

- ajaxExtended 调用失败

疑难解答选项

以下列表包括这些错误的可能原因和帮助进行故障排除的步骤。

  • 对于公共存储帐户,通过以下方式检查对存储帐户的访问权限:

    如果连接失败,检查连接字符串中的共享访问签名 (SAS) 密钥是否为最新密钥。

  • 对于位于防火墙后的存储帐户,通过以下方式检查对存储帐户的访问:

    如果发现连接问题,则执行以下步骤:

    1. 在与逻辑应用集成的同一虚拟网络中,创建可以放入其他子网中的 Azure 虚拟机。

    2. 在命令提示符下,运行 nslookup 以检查 Blob、文件、表和队列存储服务是否会解析为预期的 IP 地址。

      语法: nslookup [StorageaccountHostName] [OptionalDNSServer]

      Blob:nslookup {StorageaccountName}.blob.core.chinacloudapi.cn

      文件:nslookup {StorageaccountName}.file.core.chinacloudapi.cn

      表:nslookup {StorageaccountName}.table.core.chinacloudapi.cn

      队列:nslookup {StorageaccountName}.queue.core.chinacloudapi.cn

      • 如果存储服务具有服务终结点,该服务将解析为公共 IP 地址。

      • 如果存储服务具有专用终结点,该服务将解析为相应的网络接口控制器 (NIC) 专用 IP 地址。

    3. 如果以前的域名服务器 (DNS) 查询成功解析,则运行 psping 或 tcpping 命令以检查通过端口 443 与存储帐户的连接:

      语法: psping [StorageaccountHostName] [Port] [OptionalDNSServer]

      Blob:psping {StorageaccountName}.blob.core.chinacloudapi.cn:443

      文件:psping {StorageaccountName}.file.core.chinacloudapi.cn:443

      表:psping {StorageaccountName}.table.core.chinacloudapi.cn:443

      队列:psping {StorageaccountName}.queue.core.chinacloudapi.cn:443

    4. 如果每个存储服务都可以从 Azure 虚拟机解析,请查找虚拟机用于解析的 DNS。

      1. 将逻辑应用的 WEBSITE_DNS_SERVER 应用设置设为 DNS,并确认 DNS 是否正常工作。

      2. 确认已使用标准逻辑应用中的相应虚拟网络和子网正确设置了 VNet 集成。

    5. 如果将专用 Azure DNS 区域用于存储帐户的专用终结点服务,检查是否已将虚拟网络链接创建到逻辑应用的集成虚拟网络。

有关详细信息,请查看使用服务或专用终结点将标准逻辑应用部署到防火墙后面的存储帐户

后续步骤