使用运行状况检查监视 Azure 逻辑应用标准工作流的状态

适用于：Azure 逻辑应用（标准）

为了帮助标准逻辑应用工作流以高可用性和性能运行，请在逻辑应用上设置运行状况检查功能以监视工作流运行状况。通过提供以下优势，此功能可确保应用保持复原能力：

主动监视，以便在问题影响客户之前找到并解决它们。
从 Azure 的负载均衡器中删除不正常的实例以提高可用性。
通过替换不正常的实例自动恢复。

运行状况检查在 Azure 逻辑应用中如何工作？

运行状况检查是一项 Azure 应用服务平台功能，可将请求从不正常的实例重定向，并在这些实例保持不正常时替换它们。对于标准逻辑应用，可以指定为此目的和应用服务平台创建的“运行状况”工作流的路径，以定期执行 ping 操作。例如，以下示例显示了基本最低工作流：

启用运行状况检查后，应用服务平台会按 1 分钟间隔对所有逻辑应用实例的指定工作流路径执行 ping 操作。如果逻辑应用需要横向扩展，则 Azure 会立即新建实例。应用服务平台再次对工作流路径执行 ping 操作，以确保新实例准备就绪。

如果实例上运行的工作流在 10 个请求后未响应 ping，则应用服务平台会确定该实例不正常，并从 Azure 的负载均衡器中删除该特定逻辑应用的实例。您可以指定失败请求的数量以确定实例是否不健康，最低需要两个请求。有关替代默认行为的详细信息，请参阅配置：使用运行状况检查监视应用服务实例。

运行状况检查删除不正常的实例后，该功能会继续对实例执行 ping 操作。如果实例使用正常状态代码（包括 200 到 299）做出响应，则运行状况检查会将实例返回到负载均衡器。但是，如果实例在一小时内保持不正常，则运行状况检查会将实例替换为新的实例。有关详细信息，请参阅应用服务利用运行状况检查进行哪些方面的监视。

先决条件

Azure 帐户和订阅。如果没有订阅，可以注册 Azure 帐户。
具有以下属性的标准逻辑应用资源：
- 已扩展到两个或更多实例的应用服务计划。
- 专门执行健康检查以及以下元素的“健康”工作流：
  - 以名为收到 HTTP 请求时的请求触发器开始。
  - 包括名为响应的请求操作。将此操作设置为返回包含在200到299之间的状态代码。
  还可以选择让此工作流运行其他检查，以确保依赖服务可用且按预期工作。最佳做法是确保运行状况检查路径监视工作流中的关键组件。例如，如果应用依赖于数据库和消息传送系统，请确保健康检查能够访问这些组件。

限制

指定的路径长度必须少于 65 个字符。
指定路径中的更改在运行状况检查时会导致逻辑应用程序重启。为了减少对生产应用的影响，请设置和使用部署槽位。
运行状况检查不遵循 302 状态代码的重定向。因此，请避免重定向，并确保选择应用中存在的路径。

设置运行状况检查

在Azure 门户中，转到标准逻辑应用资源。
在逻辑应用菜单上的 “监视”下，选择“ 运行状况检查”。在 “运行状况检查 ”页上的“ 运行状况检查 ”选项卡上，选择“ 启用”。
在“运行状况探测路径”的“路径”框中，输入工作流的有效 URL 路径，例如：

/api/<workflow-name>/triggers/<request-trigger-name>/invoke?api-version=2022-05-01
保存所做更改。在工具栏上选择“保存”。
在逻辑应用资源中，按照以下步骤更新host.json文件：
1. 在逻辑应用菜单的“开发工具”下，选择“高级工具”，然后点击>。
2. 在“KuduPlus”工具栏上，打开“调试控制台”菜单，然后选择“CMD”。
3. 浏览到site/wwwroot文件夹，然后在host.json文件旁边选择“编辑” 。
4. 在host.json文件编辑器中，添加Workflows.HealthCheckWorkflowName属性和运行状况工作流名称以启用运行状况检查身份验证和授权，例如：
```
"extensions": {
    "workflow": {
        "settings": {
            "Workflows.HealthCheckWorkflowName" : "<workflow-name>"
        }
    }
}
```
5. 完成后，选择“保存”。

故障排查

设置健康路径后，我的健康工作流不会触发。

在逻辑应用菜单上，选择“诊断并解决问题”。
在“故障排除类别”下，选择“可用性和性能”。
查找并查看状态代码部分。

如果状态代码为401，请检查以下项：
- 确认Workflows.HealthCheckWorkflowName属性和您的运行状况工作流名称是否正确出现。
- 确认指定的路径与工作流和请求触发器名称匹配。

常见健康状况问题

我的逻辑应用资源没有任何工作流，但资源仍横向扩展到多个实例，这会产生成本。

如果逻辑应用资源不正常，或者当资源无法访问关联的存储帐户时，可能会发生此行为。尝试检查存储帐户是否有阻止访问的网络设置，或者你是否有阻止访问的网络防火墙策略。

我的逻辑应用资源具有工作流，但未运行或运行频率不高。但是，资源仍会横向扩展到多个实例，这会带来成本。

检查资源是否可以访问关联的存储帐户。

例如，存储帐户是否有阻止访问的网络设置？你是否有阻止访问的网络防火墙策略？
如果工作流以基于服务提供程序的触发器开头，请确保触发器按预期成功工作。
- 基于服务提供商的失败触发机制可能会导致不必要的扩展，从而显著增加成本。
  
  例如，一个常见的失误是设置触发器而不向逻辑应用授予对目标（例如服务总线队列、存储 blob 容器等）的权限或访问权限。
- 请确保随时监视此类触发器，以便可以及时检测和修复任何问题。

我的工作流间歇性地停止处理消息几个小时，但其他大多数时间运行良好。

如果标准逻辑应用使用名为 “工作流服务计划”的托管选项，请确保启用 运行时缩放监视 ，并将 Always Ready 实例 设置为至少 1。

在 Azure 门户中，打开逻辑应用。
在逻辑应用边栏的 “设置”下，选择“ 配置”。
在 “工作流运行时设置 ”选项卡上的 “运行时缩放监视”旁边，选择“ 打开”，然后选择“ 应用”。
在逻辑应用边栏上的 “应用服务计划”下，选择“ 横向扩展”。
在“应用横向扩展”下，确保“始终就绪实例数”值未设置为 0。

如果标准逻辑应用托管在应用服务环境中，请确保 已启用 Always on 。

在 Azure 门户中，找到并打开逻辑应用。
在逻辑应用边栏的 “设置”下，选择“ 配置”。
在 “常规设置 ”选项卡上，选择 “始终 打开”以启用，然后选择“ 应用”。

Last updated on 2026-03-17