在Log Analytics中分组失败运行的Logic Apps操作/连接器并查询聚合记录

当然可以！我之前帮不少团队搭建过这类基于Logic Apps和Log Analytics的聚合日志视图，下面直接给你可复用的查询语句，拆解关键逻辑，再分享一个实际落地的案例。

下面的KQL查询可以将指定RunID下的所有操作数据与Compose自定义跟踪属性聚合为单条有效记录，你只需要替换开头的targetRunId和logicAppName参数即可：

// 替换为你的目标RunID和Logic Apps资源名称
let targetRunId = "your-specific-run-id";
let logicAppName = "your-logic-app-resource-name";

// 提取所有操作的核心运行数据（状态、时间、错误信息等）
let operationLogs = AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where Resource == logicAppName
| where RunId == targetRunId
| where Category == "WorkflowRuntime"
| extend OperationName = tostring(Properties_d["operationName"])
| extend OperationStatus = tostring(Properties_d["status"])
| extend OperationStartTime = todatetime(Properties_d["startTime"])
| extend OperationEndTime = todatetime(Properties_d["endTime"])
| extend ErrorDetails = iff(OperationStatus == "Failed", tostring(Properties_d["error"]), "")
| project RunId, OperationName, OperationStatus, OperationStartTime, OperationEndTime, ErrorDetails;

// 提取Compose步骤中的自定义跟踪属性
let composeTraceLogs = AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where Resource == logicAppName
| where RunId == targetRunId
| where Category == "WorkflowRuntime"
| where OperationName startswith "Compose_" // 根据你的Compose步骤命名调整匹配规则
| extend CustomTraceProps = parse_json(tostring(Properties_d["inputs"])) // 若属性在outputs则替换为Properties_d["outputs"]
| project RunId, CustomTraceProps;

// 聚合为单条完整记录
operationLogs
| summarize AllOperations = make_list(pack_all()) by RunId
| join kind=leftouter (composeTraceLogs) on RunId
| summarize FinalAggregatedRecord = pack(
    "RunID", RunId,
    "OperationSummary", AllOperations,
    "CustomTrackingProperties", any(CustomTraceProps) // 若有多个Compose步骤可改为make_list(CustomTraceProps)
) by RunId
| project FinalAggregatedRecord

• Compose步骤匹配：如果你的Compose步骤没有统一前缀，直接替换startswith "Compose_"为== "YourExactComposeStepName"即可。
• 自定义属性位置：如果你的跟踪属性是在Compose的输出而非输入里，把Properties_d["inputs"]改成Properties_d["outputs"]。
• 过滤操作状态：如果只需要关注失败/成功的操作，在operationLogs子查询末尾添加| where OperationStatus in ("Failed", "Succeeded")。

我之前帮一个电商团队做过类似的日志体系：他们的Logic Apps负责处理订单支付回调，工作流包含「验证签名→查询订单→更新库存→Compose跟踪订单ID/用户ID→发送通知」五个步骤。

当某次支付回调处理失败时，运维人员只需输入RunID执行上面的查询，就能直接得到一条聚合记录：

1. 所有操作的时间线与状态（比如「更新库存」步骤在14:35:22失败）
2. 「更新库存」的具体错误详情（比如库存不足的报错信息）
3. Compose里的订单ID=ORD-20240516-12345、用户ID=U-98765

这样运维不用逐个翻阅几十条操作日志，就能快速定位问题环节，还能直接关联业务数据排查根源，大大提升了故障排查效率。

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