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 agent fetches payloads through the Azure REST API with the App Registration on the Authentication tab. 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. Your users then find them in Log Views, and the Message Types of the logged payloads decide how long Nodinite keeps them and which Search Fields it extracts. 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 and About Logic Apps Logging options.

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 (Monitoring Logic Apps), 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

Diagram: Successful runs and failed runs each have their own Trigger and Action settings, and each set filters what becomes a Log Event.

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 Log API 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). The agent must reach this port; see Prerequisites - Firewall settings
• Log Agent Value Id - A positive integer (Id) identifying this Log Agent; the agent stamps its Log Events with this Id. The default for the Azure Logic Apps agent is 5

  Important

  You should not change the LogAgentId once set, because the Log Events that Nodinite has already logged are tied to this particular Log Agent Value Id.

The Basic tab of the Logging settings with the Log API address and the 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

The global Successful runs tab, with its Trigger and Actions sub-tabs.

Trigger (Global)

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

All Trigger checkboxes are checked by default, which gives verbose logging.

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

The Actions tab with the Limits and the Filter configurations.

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 agent creates the Log Event 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:
Example of the Add button for 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

The Basic tab decides whether a matched Action logs its bodies and its tracked properties.

Logged tracked properties become context properties on the Log Event, which you can use in Search Field Expressions to make the data searchable.

Actions Tab (Filter Configuration Entry)

Here, you 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.
  An empty list of Action filters logs all Actions.

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

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.
Example of a workflow where the Actions to log carry the name Logging.

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 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.
The Tracked Properties tab of a Filter configuration entry.

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

The following image depicts an example of usage.
Example of a Tracked Property in a Logic App Action that the filter matches.

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.

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 - If you're only interested in the runs that fail, check the checkboxes you need.

• Trigger

• Actions

The global Failed runs tab, with the same Trigger and Actions settings as for successful runs.

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. To review the Logging settings that apply to a Logic App, use Log Configuration Details.

Next Steps

• Configure Workflow Monitoring
• Back to Event Hubs
• Back to Subscription configuration
• Configure Message Types
• Add or manage Log View
• User access to Logic Apps Logging

Related Topics

• Logic Apps Log Agent
• Logging Logic Apps
• Managing Logic Apps
• Prerequisites
• Configuration
• About Logic Apps Logging options
• Reduce Azure Logic Apps Run History Retention to Lower TCO
• Search Fields
• Log Agents
• Troubleshooting