我们的一个Azure逻辑应用程序在从调用到实际开始执行的时间上经历了一个奇异的差距。这会导致极长且错误的行程。这是一个有问题的运行的示例:
Start date: Friday, December 13, 2019, 1:45:42 PM
End date: Friday, December 13, 2019, 2:24:30 PM
运行时间:38.79分钟
Check_if_journal_file 0 Milliseconds
Condition 0 Milliseconds
Delay 1.52 Seconds
Get_Blob_Metadata 15 Milliseconds
HTTP 281 Milliseconds
ImportBreakpointJournalFile 406 Milliseconds
Initialize_JobHttpStatusCode 110 Milliseconds
Journal_file_failed_to_process 0 Milliseconds
Journal_file_successfully_processed 31 Milliseconds
Not_a_journal_file 0 Milliseconds
Set_variable 157 Milliseconds
Until 4.69 Seconds
实际执行时间:7.21秒
由于执行本身仅花费了约7秒的时间,这意味着逻辑应用程序只是闲置了将近38分钟而无所事事!在此之前的运行没有时序问题。
还有没有其他人看到过这样的行为?
什么会导致逻辑应用在开始执行之前闲置38分钟?
更新:
为逻辑应用程序打开了详细的诊断程序,并得到以下结果,表明该应用程序确实处于空闲或暂停状态。您可以看到工作08586252374669322278104928528CU37在12:23开始,然后几乎立即挂起?然后采取任何操作,然后在没有明显原因的情况下在12:58恢复。恢复后,您会看到它开始正常执行,因为Initialize_JobHttpStatusCode是应用程序中的第一个操作。
TimeGenerated [UTC] startTime_t [UTC] waitEndTime_t [UTC] resource_runId_s resource_originRunId_s resource_actionName_s endTime_t [UTC]
12/15/2019, 12:58:57.627 AM 12/15/2019, 12:58:57.471 AM Invalid Date 08586252374669322278104928528CU37 Initialize_JobHttpStatusCode 12/15/2019, 12:58:57.549 AM
12/15/2019, 12:58:57.540 AM 12/15/2019, 12:58:57.471 AM Invalid Date 08586252374669322278104928528CU37 Initialize_JobHttpStatusCode Invalid Date
12/15/2019, 12:58:57.405 AM 12/15/2019, 12:23:38.550 AM 12/15/2019, 12:58:57.330 AM 08586252374669322278104928528CU37 08586252374669322278104928528CU37 Invalid Date
12/15/2019, 12:58:57.282 AM 12/15/2019, 12:58:56.901 AM Invalid Date 08586252353485738359883907091CU99 12/15/2019, 12:58:56.980 AM
12/15/2019, 12:58:57.258 AM 12/15/2019, 12:58:56.901 AM Invalid Date 08586252353485738359883907091CU99 Invalid Date
12/15/2019, 12:58:57.247 AM 12/15/2019, 12:58:56.909 AM Invalid Date 08586252353485738359883907091CU99 08586252353485738359883907091CU99 Invalid Date
12/15/2019, 12:23:39.275 AM 12/15/2019, 12:23:38.534 AM Invalid Date 08586252374669322278104928528CU37 12/15/2019, 12:23:39.034 AM
12/15/2019, 12:23:39.172 AM 12/15/2019, 12:23:38.534 AM Invalid Date 08586252374669322278104928528CU37 Invalid Date
12/15/2019, 12:23:39.143 AM 12/15/2019, 12:23:38.550 AM Invalid Date 08586252374669322278104928528CU37 08586252374669322278104928528CU37 Invalid Date
答案 0 :(得分:0)
Logic Apps一旦触发,将不会处于空闲状态。在您的情况下,Logic App在一定时期内将尝试很少的操作。重试策略最多可配置1天。您可以检查并检查Logic App运行是否重试。
答案 1 :(得分:0)
您的“如果条件”似乎有问题。屏幕快照显示“条件”花费了0毫秒,但是由于第二个“条件”中的某些错误,应将其取消。逻辑应用程序的运行历史记录显示为0,并误导了我们。
我在自己的身边进行了测试,请参考下面的逻辑应用程序: 按照我的逻辑,我创建了一个“延迟”动作来延迟10分钟,然后手动运行此逻辑应用程序。逻辑应用程序快速执行了“延迟”操作之前的步骤,然后停留在“延迟”操作之前。 10分钟前,我使用this api取消了此逻辑应用程序,我们可以在“运行历史记录”中看到它已被取消(如下屏幕截图所示)。 然后在“运行历史记录”中单击该项目(我在10分钟后单击它,如果在10分钟之前单击它,则条件将显示x分钟并显示“正在运行”状态),“条件”显示0s(与您相同),但是不超过10分钟。
根据我的测试,逻辑应用程序运行了几分钟,但“条件”仅显示0,因此我认为您的逻辑应用程序中的“条件”在38分钟内也花费了大部分时间,请检查这两个“逻辑应用中的“如果条件”。我认为您的第二个条件应该有问题,并且导致您的第一个条件被取消。