- 12 minutes to read

Configuring a Subscription in the Azure Logic Apps Logging and Monitoring Agent

Info

This guide teaches how to configure Subscriptions in the Nodinite Azure Logic Apps Logging and Monitoring Agent to enable Monitoring and Logging of Logic Apps. Please read the 'About Logic Apps Logging options' user guide before you continue.

  • The basic configuration is documented here.

Add Azure Subscription with Logic Apps

Important

Azure access information is required; follow the Prerequisites and the 'Azure Applications Access' user guide first if you have not yet configured and created an Azure AD application and service principal to access Azure resources.

The Logic Apps tab has an array with one or more Subscription configurations.
Remote Configuration Subscriptions
Add your Azure Subscriptions to Log and Monitor

  • Press the Add button to add one (or more) Azure subscription(s):
    Empty Accordion
    Here's an example of a Subscription configuration entry.

  • Repeat this step for each of your Azure subscriptions to Log and/or Monitor with Nodinite

Click the Accordion to expand the subscription configuration, and you can then manage the content of the configuration.
Subscription Entry
Example with configuration tabs

Basic tab

From the Basic tab, you can enter the basic information about the Azure Subscription configuration with Logic Apps to use:
Basic tab (6.1.0.11)

  • Enabled - When checked, this Azure Subscription configuration is enabled
  • Configuration name - The User-friendly Name of this Azure Subscription configuration

Logging tab

Note

The Diagnostics logging feature in Azure for Logic Apps produces a verbose logging. You can limit the events that actually gets logged to Nodinite.

To enable Logging and the Failed Runs, and Failed Triggers Monitoring, you must enable the Logging feature and set some properties as described in this section.

Tip

We highly recommend that you follow the guidelines in this section as this is our design idea.

There are two different types of Logging settings; Successful runs and Failed runs.

graph TD subgraph "fal:fa-sitemap Logic App Workflow" subgraph "fal:fa-check-square Successful runs" roSRTS["fal:fa-bolt Trigger settings"] roSRAS["fal:fa-exchange-alt Action settings"] end subgraph "fal:fa-square-xmark Failed runs" roFRTS["fal:fa-bolt Trigger settings"] roFRAS["fal:fa-exchange-alt Action settings"] end end subgraph "Nodinite" roLE["Log Event"] roSRTS -.-> |Filter|roLE roSRAS -.-> |Filter|roLE roFRTS -.-> |Filter|roLE roFRAS -.-> |Filter|roLE end

Important

These settings are mutually exclusive!

Basic tab (Logging)

Apply the essential Logging settings.

  • Enable logging - When checked; Runs (events and payload) are logged from your Logic Apps
  • LogAPI URI - The LogAPI URI for the specified Nodinite instance, e.g. http://localhost/Nodinite/LogAPI/
  • Log Agent Value Id - A unique positive integer (Id) identifying this Log Agent (Stamp the Log Events with this Id)

    Important

    You should not change the LogAgentId once set. This is because already logged events in Nodinite has already "married" to this particular Log Agent Value Id.
    Logging options - Basic tab (6.1.0.11)

Successful runs (global)

In the 'Successful runs' tab you set the Logging options for Successful runs. There is another setting for Failed runs.

There are two types of filters to set:

Global Successful Runs Settings (6.1.0.11)

Trigger (Global)

Settings about the Trigger. For successful runs you may want to uncheck these checkboxes to your minimum requirement to reduce the verbose logging which is enabled by the default.

Global Trigger settings for Susccessful runs (6.1.0.11)

  • Log Trigger start - When checked; Log the input of Trigger
  • Log input body - When checked; Log the body of the input
  • Log Trigger end - When checked; Log the output of Trigger
  • Log output body - When checked; Log the body of the output
Actions (Global)

Use the settings available in the Actions tab to filter events from connectors in your workflows. There are two main parts to consider here, Limits and Filter Configurations.

The purpose of the Limits are to reduce the net amount of Log Events.

  • Limit to 1st repetition - When checked (Default); Log only the 1st repetition found in Actions. Checked also disables the Max Log Events for Repetitions checkbox.
  • Max Log Events for RepetitionsNew 6.1.0.11 - Set the maximum number of records to log within any Workflow run action repetition. The value range is 1 to 1000.
  • Max Log Events for ActionsNew 6.1.0.11 - Set the maximum number of Action records to log. The value range is 1 to 50,000.

    Note

    The Default is 1000(!)

  • Filter configurations - Add one or more filter configurations to create [Log Events]Log Event[] based on Action names AND Tracked Property names.

Actions tab  Successful runs - Global section

Filter Configurations

Note

By default, the Logging is Verbose (with a limit on the max number of Log EventsNew 6.1.0.11). Whenever you add one or more Filters, the Log Event is created if there is a match on either the Action name, AND the name of the Tracked Property. Each Filter entry has an OR in between.

Click the button to Add a new Filter entry:
Add new Filter button (6.1.0.11)

Expand the accordion to reveal the settings. There are tabs with different settings.

  1. Basic
  2. Actions
  3. Tracked Properties
Basic Tab (Filter Configuration Entry)
  • Enabled - When checked, this configuration is in use
  • Description - User-friendly filter configuration description
  • Log input body - When checked; Log the body of the input
  • Log output body - When checked; Log the body of the output
  • Log input tracked properties - When checked; Log context properties of the input
  • Log output tracked properties - When checked; Log context properties of the output

Basic Tab - Filter Configuration Entry (6.1.0.11)

Actions Tab (Filter Configuration Entry)

Here, you will apply the filter based on the name of the shape in your Logic Apps Workflow. There can be any number of such Filters.

  • Action Filter configurations - Add one or more filter configurations to include Log Events based on Action names. If there are no entries, then all Actions are included in the Logging.
    Actions tab - Filter Configuration Entry (6.1.0.11)

Click the button to Add a new RegEx-based Action Filter. There can be any number of of such entries.
Add new Actions Filter button (6.1.0.11)

Tip

Make it easy for your self and others. Set a common name like Logging in the filter and then apply this to the shapes in your workflows where Logging is required. This pattern is very easy to understand and the filter configuration is dead simple.
Logic Apps naming example

Important

There is an AND between the Actions tab and the Tracked Properties Tab for a single Filter entry.

Tracked Properties Tab (Filter Configuration Entry)

Here, you will apply the filter based on the name of the Tracked Property in the output shape of your Logic Apps Workflow. There can be any number of such Filters.
Tracked Properties Filter Tab(6.1.0.11)

Click the button to Add a new RegEx-based Tracked Property Filter. There can be any number of such entries.
Tracked Properties Filter Entry (6.1.0.11)

The following image depicts an example of usage.
Tracked Properties Filter example in an Azure Logic App Workflow

Important

You should most likely add Actions filters, as adding a single tracked properties filter limit the Logging to only output shapes containing a match on the name of the Tracked Property. Remember that our proposition is to have a single Actions filter with the name: Logging.

Important

There is an AND between the Actions tab and the Tracked Properties Tab for a single Filter entry.

Failed runs (global)

In the 'Failed runs' tab you set the Logging options for Failed runs. There are other similar settings for Successful runs.

  • Failed runs - Maybe your are only interested in the runs that fail, please check the checkboxes according to your need.

  • Trigger

  • Actions

Failed runs - Global (6.1.0.11)

Note

The settings for Failed runs are essentially identical to Successful runs, hence, the documentation is not repeated.

Tip

You can supersede the global Logging settings for each Resource Group.

Resource groups tab

From the Resource groups tab, you can enter information about what Resource Groups to include in Monitoring and the Logging options to use:
Resource Groups tab

There are three additional tabs:

  1. Basic tab
  2. Successful runs
  3. Failed runs

Click the Add button to add a Resource Group.

  • Repeat this step as necessary. The list is easier to maintain on the Subscription Resource.

Basic Tab (Resource Group)

Tip

You can supersede the global Logging settings for each individual Resource Group.

You must enter the name of at least one existing Azure Resource Group.
Resource Group Entry

The following fields exist:

  • Enable Monitoring - When checked, Monitor the state of Logic Apps in this Resource Group and Failed runs.
  • Enable Logging - When checked, Log the Logic Apps in this Resource Group when the Global log setting is Enabled
  • Override the global filter Logging settings - When checked, Log the Logic Apps according to this specific filter configuration
  • Resource Group name - Name of the Resource Group with Logic apps within this Subscription configuration Missing resource group
    Here's en example of a bad och changed configuration for a Resource Group to monitor. When you remove, or rename a Resource Group in Azure, you must change the configuration accordingly, otherwise, it will appear as Unavailable.
  • Description - User-friendly description

Tip

It is much easier to manage the list of Resource groups from a Monitor View with the Subscription Category.
Details Action as seen in a Monitor View

Click the Details action menu item to open a modal to select which Resource groups to include in the Monitoring and Logging.
Resource groups

Successful Runs (Resource Group)

Note

The settings for Successful runs on Resource Group level are essentially identical to the global setting for Successful runs, hence, the documentation is not repeated.

Failed Runs (Resource Group)

Note

The settings for Failed runs on Resource Group level are essentially identical to the global setting for Failed runs, hence, the documentation is not repeated.

Workflows tab

Enter settings in the Workflows tab for specifics.

Workflows tab

General Tab (Workflows)

  • Enable monitoring of Workflows - When checked, Workflows for enabled Resource groups(s) will be monitored
  • Enable trigger evaluation of Workflows - When checked, triggers for enabled workflows will be monitored
  • Workflow exclusion filter - The list of RegEx expressions in use to exclude Azure Workflows from Monitoring
Workflow exclusion filter

You can exclude Workflows based on the name using a regular expression. Click the Add button to add a new entry.
Workflow exclusion filter

Global Tresholds (Workflows)

You can configure Non-Events type Monitoring. This option is easier to use on the Logic App Resource.

Global Tresholds tab (6.1.0.11)

  • Lookback time period - The time period to look back for Azure Workflow execution KPIs
  • Min execution count - Warning - Warning threshold for the minimum number of executions in period (set value -1 to disable this check)
  • Min execution count - Error - Error threshold for the minimum number of executions in period (set value -1 to disable this check)
  • Max execution count - Warning - Warning threshold for the maximum number of executions in period (set value -1 to disable this check)
  • Max execution count - Error - Error threshold for the maximum number of executions in period (set value -1 to disable this check)
  • Max Action invocation count - Warning - Max number of allowed Action invocations for a single run (set value -1 to disable this check)
  • Max Action invocation count - Error - Max number of allowed Action invocations for a single run (set value -1 to disable this check)
  • Duration - Warning - The longest allowed run duration for the Workflow in milliseconds (set value -1 to disable this check)
  • Duration - Error - The longest allowed run duration for the Workflow in milliseconds (set value -1 to disable this check)

Specific thresholds tab (Workflows)

For a specific Workflow, you can override the global settings. Specific thresholds tab - Workflows (6.1.0.11)

  • Name - The name of the Azure Workflow (note: case sensitive)
  • Web Site Name - Conditional: The name of the Web Site with the specified Workflow (Applies only to the Standard App Service Plan)
  • Resource Group Name - The name of the Resource Group with the Workflow
  • Description - User friendly description for this configuration
  • Clear DateTime (UTC) - The date time in UTC format to ignore Workflows that has previously failed (the look back time span will supersede this value if too long time has passed)
  • Use global thresholds - When checked, the Monitoring thresholds uses the global settings

    Note

    These are essentially the same as in the global settings and as such are not repeated in this documentation.

Specific thresholds entry - Workflows (6.1.0.11)

Event Hubs tab

You can enter information about what Event Hubs to fetch diagnostics data from the Event Hubs tab. This setting is vital for the Logging feature:
Event Hubs tab

click the Add button to add an Event Hub configuration.

Repeat this step for each Event Hub in use by the Diagnostic settings in Azure for your Workflows in the specified Subscription.

The following required fields exist:

  • Enabled - When checked, this Event Hub configuration is enabled (mandatory for Logging, and mandatory for Monitoring failed runs for Logic Apps).
  • Event Hubs Namespace Connection string - The Azure Event Hubs namespace connection string to use for this configuration.
  • Event Hub name - Name of the Event Hub set in the Diagnostic settings for Logic Apps.
  • Storage Connection string - The Azure Storage Connection string with the Storage Container with the Checkpoint for the specified Event Hub entity.
  • Checkpoint Storage Container name - Name of the Storage Container in use to store the checkpoint/offset for the specified Event Hub entity.
  • WebProxy - The URI for the WebProxy in use with this Event Hub configuration.
    Event Hub Configuration Entry(6.1.0.11)

Important

You must make sure to comply with the prerequisites! Otherwise; The Logging feature is not operational.

graph LR subgraph "Azure Cloud / Subscriptions" storage(fa:fa-boxes Checkpoint Storage Container) A[fal:fa-clouds Logic App
with diagnostic setting] --> B(fa:fa-list Azure Event Hub entity) end subgraph "Nodinite Instance" B --- C[fal:fa-monitor-waveform Azure Logic Apps
Logging and Monitoring Agent] C--- db(fa:fa-database Monitoring Database) C --> |Log Event| F[fa:fa-cloud-download Nodinite's Log API] C --- |Checkpoint| storage storage -.- |NOTE 1:1 relationship| B end

Authentication tab

From the Authentication tab, you can enter information about how the Agent connects with the configured Azure subscription:
Authentication tab

You must set the following properties for each Azure Subscription:

  • SubscriptionId
  • TenantId
  • ClientId
  • ClientSecret

Tip

Review Azure Application Access page for additional information and learn how to obtain the mandatory values

Logic Apps

When Monitoring is enabled, the Azure Logic Apps Logging and Monitoring Agent evaluate the outcome of runs. If a run fails only once, the Resource for that particular logic with category Logic App - Runs is in the Error state until the error has been cleared, either manually using the Remote Action clear or an Auto Healing operation sets the Clear Date Time property (to the point in time when the action was executed...).

This record creates automatically by the system on the first run failure. If you need to alter the time, this is the place to do so.
LogicAppsSetting


Next Step