Configure Logging for Azure Logic Apps

This page covers the Logging tab of a Subscription configuration in the Nodinite Azure Logic Apps Logging and Monitoring Agent. It decides which workflow activity becomes Nodinite Log Events. The agent reads that activity from the diagnostics Event Hub, which you configure first on the Event Hubs tab; the Event Hub can be in a different subscription than the workflows. The other tabs are on the Subscription configuration page.

Understanding Logic Apps logging filters

Azure diagnostics for Logic Apps are verbose: they produce events for every trigger and every Action, in and out, including every iteration of a loop. A single run of a complex workflow can produce hundreds of thousands of Action invocations, and Azure keeps all of them in the run history for the whole retention period.

The agent reads that stream from the Event Hub, but it doesn't have to keep everything. The Logging filters decide which events become Log Events, and which of those carry payloads:

Diagram: The agent applies the filters to the diagnostics stream. For matched events, it fetches the payloads from the run history (yellow) through the REST API, and they become Log Events (green); everything else (red) is not logged.

The result is a Nodinite history that holds the business-relevant steps, such as the receive and the send of a message, instead of every internal step. This is also why Nodinite storage can be a small fraction of what Azure keeps; see Reduce Azure Logic Apps Run History Retention to Lower TCO.

Logging tab

Note

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

To enable Logging and the Failed Runs, and Failed Triggers Monitoring, you must enable the Logging feature and set the required filter settings 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.

• Basic tab
• Successful runs
• Failed runs

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. 'https://nodinite.contoso.com:40002/LogAPI/'; the host and port come from your environment's settings in the Nodinite Portal (Servers step)
• 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.

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:

• Trigger
• Actions

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 default.

• 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 is to reduce the net amount of Nodinite 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 Repetitions^{New 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 Actions^{New 6.1.0.11} - Set the maximum number of Action records to log per run. 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 based on Action names AND Tracked Property names.

Filter Configurations

Note

By default, the Logging is Verbose (with a limit on the max number of Log Events^{New 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:

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

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.

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

Tip

Make it easy for yourself 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.

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.

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

The following image depicts an example of usage.

Important

You should most likely add Actions filters, as adding a single tracked properties filter limits 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 you are just interested in the runs that fail, please check the checkboxes according to your need.

• Trigger

• Actions

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; see the Resource groups tab.

Next Steps

• Configure Workflow Monitoring
• Back to Event Hubs
• Back to Subscription configuration
• Configure Message Types

Related Topics

• About Logic Apps Logging options
• Reduce Azure Logic Apps Run History Retention to Lower TCO
• Logging Logic Apps
• Configuration
• Logic Apps Log Agent