如何用Azure Monitor/Logs监控未触发Logic Apps的入站请求？

生产环境的消耗型Logic App通过"When an HTTP Request is Received"触发器接收第三方云应用的Webhook消息，近期多次出现请求丢失情况：第三方确认消息已发送且其他服务能正常接收，但Logic App端无任何触发记录，需要排查是否可通过Azure Monitor/Logs监控那些未触发Logic App的入站请求，并获取相关实践经验。

1. 启用Logic App诊断日志 #

消耗型Logic App默认未开启诊断日志，需手动配置将日志发送到Log Analytics工作区，重点关注两类日志：

• HttpRequestLogs：记录所有到达HTTP触发器的请求明细，包括请求状态码、来源IP、请求URI等。
• WorkflowRuntimeLogs：记录触发器的评估与执行过程，包括触发失败的原因。

配置步骤：进入Logic App资源 → 「诊断设置」 → 添加新诊断设置 → 勾选HttpRequestLogs和WorkflowRuntimeLogs → 选择目标为Log Analytics工作区。

2. 用Kusto查询定位未触发的请求 #

在Log Analytics工作区中，通过以下查询语句筛选异常请求：

筛选未成功排队的入站请求 #

HttpRequestLogs
| where ResourceProvider == "Microsoft.Logic"
| where OperationName == "HttpTriggerReceived"
| where StatusCode != 202  // 202代表触发器成功接收请求并排队
| project TimeGenerated, RequestUri, StatusCode, StatusMessage, ClientIpAddress, CorrelationId

非202状态码的请求（如400格式错误、401/403权限问题、500服务端错误）都不会触发工作流，可通过StatusMessage查看具体原因。

筛选触发器评估失败的记录 #

WorkflowRuntimeLogs
| where ResourceProvider == "Microsoft.Logic"
| where OperationName == "TriggerEvaluation"
| where ResultType == "Failed"
| project TimeGenerated, TriggerName, ResultDescription, CorrelationId

这里会列出触发器评估不通过的场景，比如请求payload不符合触发器定义的schema，导致无法触发工作流。

3. 前置代理补充监控（可选） #

如果Logic App日志中完全找不到对应请求的记录，说明请求可能在到达Logic App前被Azure网络层拦截。此时可在Logic App前部署Azure Front Door或API Management作为代理，所有Webhook请求先经过代理层：

• 代理层会记录所有入站请求，将日志同步到Log Analytics。
• 通过对比代理层日志和Logic App日志的CorrelationId，即可找出那些到达代理但未到达Logic App的请求，进一步排查网络拦截原因。

• 诊断日志是核心：这是最直接的排查手段，务必确保开启，否则无法追踪请求到达触发器后的处理过程。
• 聚焦非202状态码：HTTP触发器的正常响应是202 Accepted，任何非202的请求都属于异常，优先排查这些请求的状态信息。
• 用CorrelationId关联追踪：每个请求都有唯一的CorrelationId，可通过这个ID在HttpRequestLogs和WorkflowRuntimeLogs中关联查询，还原请求的完整生命周期。
• 网络层排查兜底：如果日志无任何记录，检查Logic App所在虚拟网络的NSG、防火墙规则，确认Webhook来源IP在允许列表中；同时排查Azure区域的网络故障公告，排除平台级问题。

内容的提问来源于stack exchange，提问作者Tokioi