eG Monitoring
 

Measures reported by AzrLogicAppTest

Azure Logic Apps is a cloud-based platform for creating and running automated workflows that integrate your apps, data, services, and systems. With this platform, you can quickly develop highly scalable integration solutions for your enterprise and business- to- business (B2B) scenarios.

In a logic app, each workflow always starts with a single trigger. A trigger fires when a condition is met, for example, when a specific event happens or when data meets specific criteria. Many triggers include scheduling capabilities that control how often your workflow runs. Following the trigger, one or more actions run operations that, for example, process, handle, or convert data that travels through the workflow, or that advance the workflow to the next step.

The failure of or slowness in a workflow run can disrupt key business processes, and may sometimes result in significant losses. For instance, say that the workflow that routes and processes customer orders across on-premises systems and cloud services, fails. Such a failure will result in many dissatisfied customers and monetary losses in terms of revenues and penalties. To avoid such an outcome, an administrator should be able to rapidly capture failures/latencies in any logic app's workflow run, determine whether any failed or slow-running trigger/action caused these abnormalities, and initiate appropriate remedial action. Besides the status and speed of triggers and actions, the throughput limits defined for the same can also impact logic app performance. To avoid the throttling of a logic app, these limits need to be constantly compared with real-time usage and recalibrated if required. The AzrLogicAppTest helps with all of the above!

This test monitors the workflow runs for every logic app configured on Azure. For each app, the test then reports the count of failed runs for that app, thus promptly alerting you to workflow failures. The number of triggers and actions that failed (if any) are also revealed for each app, thereby pointing you to the probable reasons for the run failures. Similarly, the test also notifies you if the workflow runs of any logic app are unusually slow. If this slowness is a result of one/more slow triggers/actions, the test reveals the same. This way, the test warns administrators of real and potential issues in their logic apps, and enables them to ensure that nothing interrupts the smooth flow of business. Also, the test promptly captures and reports throttled events, so that administrators can instantly detect throughput limit violations, and see how these limits can be redefined to curb throttling of logic apps.

Outputs of the test : One set of results for each Azure logic app configured for every resource group in the target Azure Subscription

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Status Indicates the current status of this logic app.   The values reported by this measure and its numeric equivalents are mentioned in the table below:

Measure Value Numeric Value
Enabled 1
Completed 2
Disabled 3
Deleted 4
Suspended 5
NotSpecified 6


Note:

By default, this measure reports the Measure Values listed in the table above to indicate the current status of a logic app. The graph of this measure however, represents the status of a server using the numeric equivalents only.

Use the detailed diagnosis of this measure to know the location, version, access endpoint, outgoing IP addresses, and endpoint IP addresses of the logic app.
Prvsng_status Indicates the current provisioning status of this logic app.   The values reported by this measure and its numeric equivalents are mentioned in the table below:

Measure Value Numeric Value
Succeeded 1
Updating 2
Error 3
Unknown 0


Note:

By default, this measure reports the Measure Values listed in the table above to indicate the current provisioning status of a logic app. In the graph of this measure however, the same is represented using the numeric equivalents only.
Rns_strtd Indicates the number of runs started for this logic app. Number  
Rns_cmplt Indicates the number of runs that have been completed for this logic app Number  
Rns_sccd Indicates the number of runs for this logic app that have been successful. Number  
Rns_faild Indicates the number of workflow runs for this logic app that failed. Number Ideally, the value of this measure should be 0. If it is not, then look up the values of the Actions failed and Triggers failed measures to understand if any actions/triggers failed at around the same time as the run failure. If so, you can attribute the run failure to the action/trigger failure.
Rns_cancl Indicates the number of runs of this app that were cancelled. Number  
Rn_latnc Indicates the time interval between stimulation and response of this logic app. Seconds A high value for this measure implies that the workflow run is slow. In this case, check the value of the Action latency and Trigger latency measures to determine whether one/more latent actions/triggers contributed to the workflow's slowness.
Rn_succ_latnc Indicates the average time taken by the successful workflow runs of this logic app. Seconds Ideally, the value of this measure should be low.
Rn_throt_event Indicates the number of throttling events for this logic app. Number The Azure Logic Apps service has its own throughput limits. So, if your logic app exceeds these limits, your logic app resource gets throttled, not just a specific instance or run.

Ideally therefore, the value of this measure should be 0. If it is not, then you may want to consider these options to eliminate throttling:

  • Limit the number of logic app instances that can run at the same time: By default, if your logic app's trigger condition is met more than once at the same time, multiple trigger instances for your logic app run concurrently or in parallel. This behavior means that each trigger instance fires before the preceding workflow instance finishes running.

    Although the default number of trigger instances that can concurrently run is unlimited, you can limit this number by turning on the trigger's concurrency setting, and if necessary, select a limit other than the default value.

  • Enable high throughput mode: A logic app has a default limit for the number of actions that can run over a 5-minute rolling interval. To raise this limit to the maximum number of actions, turn on high throughput mode on your logic app.

  • Disable array debatching (“split on”) behavior in triggers: If a trigger returns an array for the remaining workflow actions to process, the trigger's Split On setting splits up the array items and starts a workflow instance for each array item, effectively triggering multiple concurrent runs up to the Split On limit. To control throttling, turn off the Split On behavior and have your logic app process the entire array with a single call, rather than handle a single item per call.

  • Refactor actions into smaller logic apps: As mentioned earlier, a logic app is limited to a default number of actions that can run over a 5-minute period. Although you can increase this limit by enabling high throughput mode, you might also consider whether you want to break down your logic app's actions into smaller logic apps so that the number of actions that run in each logic app remains under the limit. That way, you reduce the burden on a single logic app resource and distribute the load across multiple logic apps. This solution works better for actions that handle large data sets or spin up so many concurrently running actions, loop iterations, or actions inside each loop iteration that they exceed action execution limit.
Rn_fail_percent Indicates the percentage of runs for this logic app that failed. Percent A value close to 100% is a cause for concern as it implies that almost all the runs for the app failed.
Actn_strtd Indicates the number of actions started by this logic app. Number  
Actn_cmplt Indicates the number of actions completed by this logic app. Number  
Actn_sccd Indicates the number of actions of this logic app that were successful. Number  
Actn_faild Indicates the number of actions of this logic app that failed. Number The value 0 is desired for this measure.
Actn_skped Indicates the number of actions that were skipped by this logic app. Number  
Actn_latnc Indicates the time interval between the stimulation of actions by this logic app and the response. Seconds Latent actions can slowdown workflow runs. Ideally therefore, the value of this measure should be very low.
Actn_succ_latnc Indicates the time interval between the stimulation of successful actions by this logic app and the response. Seconds Actions, though successful, should not take too long to complete. This is why, a high value of this measure is often a cause for concern.
Actn_throt_event Indicates the number of throttled events for the actions of this logic app. Number A high value for this measure means that actions exceed their throughput limit often. In this case, consider the following:

  • Enable high throughput mode: A logic app has a default limit for the number of actions that can run over a 5-minute rolling interval. To raise this limit to the maximum number of actions, turn on high throughput mode on your logic app.

  • Reduce the number of concurrent outbound calls: You can reduce the number of concurrent requests or reduce the duration as necessary.
Trigr_strtd Indicates the number of triggers started by this logic app. Number  
Trigr_cmplt Indicates the number of triggers completed by this logic app. Number  
Trigr_sccd Indicates the number of triggers that succeeded for this logic app. Number  
Trigr_faild Indicates the number of triggers that this logic app failed to execute. Number  
Trigr_latnc Indicates the time that elapsed between when this logic app started and ended triggers. Seconds A low value is desired for this measure. A consistent increase in this value is a sign of bottlenecks in trigger execution. This in turn will adversely impact the pace of workflow runs.

When this measure reports abnormally high values for any logic app, you may want to compare the value of the Trigger fire latency measure with that of the Trigger success latency measure for that app. This will reveal where the delay originated - when firing triggers? or when executing them?
Trigr_fire_latnc Indicates the time taken by this logic app to fire triggers. Seconds A consistently high value for this measure could indicate undue delays in firing triggers.
Trigr_succ_latnc Indicates the latency workflow triggers that this logic app successfully executed. Seconds A consistently high value for this measure could indicate significant delays in execution and successful completion of triggers.
Trigr_throt_event Indicates the number of throttled events for the triggers fired by this logic app Number A high value for this measure means that triggers often exceeded their throughput limit. In such a situation, you may want to consider altering the defualt throughput limits.
Bill_actn_exec Indicates the number of actions of this app that are billable. Number In multi-tenant Azure Logic Apps, a logic app and its workflow follow the Consumption plan for pricing and billing. The Consumption model includes an initial number of free built- in triggers and operations, per Azure subscription, that a workflow can run. Above this number, metering applies to each execution, and billing follows the Actions pricing for the Consumption plan.

In single-tenant Azure Logic Apps, a logic app and its workflows follow the Standard plan for pricing and billing. The Standard model includes an unlimited number of free built-in operations (triggers and actions) that your workflow can run. Beyond that limit, the Standard model meters and bills an operation based on each call, whether or not the overall workflow successfully runs, finishes, or is even instantiated.
Bill_trigr_exec Indicates the number of triggers of this app that are billable. Number
Tot_bill_exec Indicates the total number of billable executions for this logic app. Number