Notifications on error – Logic Apps

Notifications on error – Logic Apps

Once you have several Logic Apps running, orchestrating important processes within your organization. You soon run into limitations regarding monitoring workflow runs and getting notified when something unexpected has occurred. To overcome this, I’ve created a small project on GitHub and will cover how everything came together within this post.

Notifications on error

Problem

The problem is simple; the current version of the Azure Logic apps implementation does not support the option to configure alerts. In addition to this, the existing monitoring options have to be enabled and monitored on an individual level, which is also somewhat cumbersome.

I’m not the only one who notices this shortcoming given that an enhancement request has already been submitted on the feedback portal; https://feedback.azure.com/forums/287593-logic-apps/suggestions/10101393-notifications-on-error Now, instead of waiting for this to get implemented as a core feature if the product, I’ve decided to create a small solution to fulfill my needs.

The information found here is somewhat of a rehash of what I’ve already written on the GitHub project page.

Solution

The project consists of a Azure WebJob which constantly monitors for failed Logic App workflow runs (all runs within a given Azure subscription). By default, the application only Tracks failed workflow runs however, the project can be extended. More details on this can be found within the “Developers” section on Github or just open the VS solution.

The logging part depends on the Azure Application Insight monitoring and diagnostics platform. This to keep the implementation simple and avoid mail, SQL server other dependencies. This will also help keeping all diagnostic information in one central place, and the ability to configure alerts.

In addition, the WebJob also writes pull details within the WebJob log. This includes the amount of failed runs found for every pull as well as the run name.

Notifications-on-error-Logic-Apps

Deployment

I’m not expecting that everyone wants to build and deploy the solution using Visual Studio and therefore included a packaged version as well. This package can be found within the releases folder of the GitHub project.

Deployment is simple given that every step has been well documented by the Azure team. Just make sure you have provisioned and configured the following first.

Requirements

  • Active Directory application and service principal – details
  • Azure Web App with Always On enabled – details
  • Azure Application Insights Environment (Application Type set to Other)

Deployment steps

Feel free to deploy the project as you prefer. The steps below are included for everyone not interested in using MSbuild.

  • Update the ApplicationInsights.config and App.config files within the .zip package with your information.

App.config
The SubscriptId should be contain the id of the subscription in which the workflows have been created

ClientId, TenantId and ClientSecret are covered within the Active Directory application and service principal step. AzureWebJobsDashboard and AzureWebJobsStorage contains the connection string to your Azure storage account. You can find the connection string within the Settings > Access Keys section of a storage account

Apps-key

ApplicationInsights.config

The Application Insights InstrumentationKey can be found within the settings blade as shown below.

Appsin-key

  • Create a continuously running Web Job using the portal as in this article or use Powershell.
  • Add the same connection strings within your Azure Web App or you won’t be able to use the WebJob dashboard within the Azure Management Portal (AzureWebJobsDashboard and AzureWebJobsStorage).

After this you can create dashboards and alerts within the Azure Applications Insight environment, Make sure to use the custom metric called Workflow-Failed,

Logic-Apps-alert

Logic-Apps-Chart

Important to know

  • Not required to alter any Logic App workflows.
  • Only errors for workflow runs with a failure date greater that the start date if the WeJob will be reported.
  • The Webjob only keeps track of custom events and not summiting diagnostic information.
  • Logging is not real-time

Post Navigation