Monitoring Logic Apps
Info
Learn how to monitor Logic Apps based solutions using Nodinite to get alerts from failed runs, disabled Logic Apps, and configuration/deployment mistakes.
Tip
Do make use of the Non-Event based Monitoring on business critical solutions!
This section describes what's being monitored and the rules for how Nodinite translates this into meaningful monitoring states. Also, some remote commands are available as Actions to help you swiftly manage problems. Actions are further detailed on the Managing Logic Apps page.
Monitoring Features
Automatic Discovery
- Nodinite Azure agents make use of the Azure Rest API and offer you an automatic discovery of your Logic App resources. Sharing access to any individual Logic App resource is very easy from within Nodinite using Monitor Views.
State Evaluation - Make sure the Logic App resources have the intended run-time state!
- State evaluation for Logic Apps * Enabled/Disabled - Provides means to get you alerted if anyone disables your logic app
- Failed run evaluation - When Monitoring is enabled, get alerted when runs fail
If Nodinite can't check the state of your Logic Apps, chances are no one else can use them either
Category-based monitoring - To help you sort out the different type of Logic Apps artifacts, the monitored Resources are grouped by Categories
List of categories being monitored
Logic App Workflows
Each Logic App Workflow discovered in the Logic App Category is presented within Nodinite as one Resource. If you have 42 deployed Workflows, then you will have 42 Resources in Nodinite.
List of Logic App Workflows in a Monitor View.
- The name of the Resources comes from the name of the deployed Logic App
- All Logic Apps belong to the 'Logic App' category
- The Application name is based on physical deployment paths. This pattern guarantees uniqueness:
- subscription name/resource group name/logic app name
Here's an example of the Nodinite Application naming pattern.
>[!NOTE]
Logic Apps standard have the Web Site name as suffix in the naming scheme.
Each presented Logic App Workflow has one of the following evaluated monitoring states at any given moment:
| State | Status | Description | Actions | |
|---|---|---|---|---|
| Connection Error | Resource not available | Evaluation of the 'Logic App' is not possible either due to network or security-related problems | Review prerequisites | |
| Unavailable | Resource not available | Workflow does no longer exist | Inactivate | |
| Error | Error threshold is breached |
|
Enable Edit thresholds | |
| Warning | Warning threshold is breached |
|
Edit thresholds | |
| OK | Within user-defined thresholds | Logic app is enabled and/or there are no runs breaching the Monitoring thresholds | Disable Edit thresholds Details View history |
Logic app example when too few executions exist within the current lookback timespan.
From within Nodinite, you can reconfigure the state evaluation on the Resource level using the Expected State feature.
Failed runs
The Nodinite Azure Logic Apps Logging and Monitoring agent evaluates the outcome of runs. There is one virtual resource available within Monitor Views where this resource is included.
Here's an example of an Error when there are one or more failed runs.
Whenever a run has failed, the Resource is evaluated as being in state Error. It will remain in this state until the error is cleared.
Note
The Monitoring feature must be enabled using an operational Azure diagnostics in order for the failed runs evaluation to be functional.
Resource Group
For each configured Azure Subscription; You can manage the set of named Resource groups to include in the Monitoring. Each of these is presented by the Resource Group Category. Each such monitored configuration is presented as a Resource in Nodinite to help you make sure the Monitoring is operational.
Here's an example of monitoring the 'Resource Group' Category as seen in a Nodinite Monitor View.
Example with a missing 'Resource Group'.
This feature's background was that customers with deployed solutions by accident had business-impacting incidents due to people (usually developers), or automated deployments accidentally changed the name or even deleted the Azure Resource Group.
| State | Status | Description | Actions | |
|---|---|---|---|---|
| Connection Error | Resource not available | Evaluation of the 'Resource Group' is not possible either due to network or security-related problems | Review prerequisites and/or Configuration | |
| Unavailable | Resource not available | Resource Group does no longer exist | Review Configuration Inactivate | |
| OK | Configuration is operational | Resource group exists and is operational | Details Statistics |
List of Remote Actions available for the Resource Group Category:
- Details
- Inactivate - This Action is available only when the Resource Group is misisng
- Statistics
Subscription
Tip
Use the Details Action to manage the set of Resource Groups to include in the Monitoring and Logging.
Each configured Azure Subscription manifests as one Resource of the Subscription Category.
Here's an example of monitoring the 'Subscription' Category as seen in a Nodinite Monitor View.
Example with a Subscription in the OK state.
| State | Status | Description | Actions | |
|---|---|---|---|---|
| Connection Error | Resource not available | Evaluation of the 'Subscription' is not possible either due to network or security-related problems | Review prerequisites and/or Configuration | |
| Unavailable | Resource not available | Subscription is not accessible | Review Configuration | |
| OK | Configuration is operational | Resource group exists and is operational | Details Statistics |
List of Remote Actions available for the Resource Group Category:
Log Configuration
The Log Configuration category exists to help you monitor both the agent Configuration, and the Azure configuration. You must match the configuration in Azure with the agent Configuration.
Here's an example of the Log Configuration Category.
| State | Status | Description | Actions | |
|---|---|---|---|---|
| Connection Error | Resource not available | Evaluation of the 'Log Configuration' is not possible either due to network or security-related problems | Review prerequisites and/or Configuration | |
| Unavailable | Resource not available | Log Configuration is not accessible | Review Configuration | |
| OK | Configuration is operational | Log Configuration is operational | Details |
List of Remote Actions available for the Log Configuration Category:
Alert history for Logic Apps
During root cause analysis or other purposes, it might be helpful to understand how often your Logic Apps problems happen. If your Monitor View allows it, you can search for historical state changes for the provided time span, either for all your Logic Apps or individually. This topic is further detailed within the generic instructions on how to Add or manage Monitor View page.
| Search | Resource history |
|---|---|
 Search for alert history for all resources in the Monitor View |
 Alert history for the selected logic app |
Frequently asked questions
Use the troubleshooting guide to find the FAQ and answers to known problems.
How do I grant my users access to logic apps monitoring?
This topic is detailed in the User access to logic apps monitoring guide.
How do I grant my users access to logic apps logging?
This topic is detailed in the 'User access to logic apps logging' guide.
How do I enable monitoring of Logic Apps
To Monitor Logic Apps, the Agent must be configured for each Subscription with the Enable monitoring checkbox checked for each Resource Group to Monitor (default is checked) further detailed in the 'User access to logic apps monitoring' page.
The image below is from the remote configuration form available from the [Subscription Details] modal.
Example with monitoring for Logic Apps enabled.