- 7 minutes to read

Release Notes

Track, Archive and find Log Events and Data from all your Microsoft Logic Apps

The Nodinite Azure Logic Apps Logging and Monitoring agent extracts logged incoming and outgoing events (payload and context properties), for all your Actions within all your Logic Apps. Nodinite creates a RunId property on each run, making it easy for you to correlate and view events from runs. With Nodinite Search Fields you extract search field values from the Context and/or the payload. Your business can therefore find business transactions using self-service Log Views without asking you or your other IT resources.

You distinguish the Logging from each Azure Subscription by setting a unique Log Agent ID. Business Users gain access to logged data through Role-based Log Views. Read Monitoring vs Logging on the Overview page to learn how the two features differ.

How Logging Works

Each Logic App sends its runtime events through an Azure Diagnostic setting to an Event Hub (Configuration - Event Hubs). The agent reads the stream, fetches the payloads of matching Actions from the run history through the Azure REST API, and posts Log Events to the Nodinite Log API. The Logging Service then makes the data available in your Log Views. The full list of Azure services involved is on the Prerequisites page.

graph LR LA["fa:fa-sitemap Logic Apps
Consumption and Standard"] -->|"Diagnostics"| EH["fa:fa-code-branch Event Hub"] EH -->|"Read stream"| AG["fa:fa-monitor-waveform Logic Apps agent"] AG -->|"Payloads via REST API"| LA AG -->|"Log Events"| LAPI["fa:fa-cloud-arrow-down Log API"] LAPI --> LV["fa:fa-magnifying-glass Log Views
Search Fields"] style EH fill:#3F827B,color:#fff style AG fill:#E47528,color:#fff style LAPI fill:#2678BD,color:#fff style LV fill:#93d16d

Diagram: The Event Hub (teal) carries the diagnostic stream to the agent (orange), which posts Log Events to the Log API (blue); business users search the result in Log Views (green).

To choose which events to log, review About Logic Apps Logging options and the Logging filters.

Configure Message Types for Business Intelligence

Note

Configure Message Types and Search Fields before you roll out Log Views to the business. Without them, Nodinite stores your Logic Apps events, but users can't search them by business data.

When Logic Apps events arrive in Nodinite:

  1. Message Types identify message formats (PurchaseOrder, Invoice, Shipment, CustomerUpdate, etc.) from tracked properties or payload content
  2. Search Field Expressions extract business data - Order Numbers, Customer IDs, Invoice amounts, Transaction codes, etc.
  3. Log Views become searchable by business identifiers, not just timestamps
  4. Non-Events Monitoring can track volumes, detect missing messages, and alert on pattern anomalies
  5. Business Process Modeling (BPM) can correlate transactions end-to-end across Logic Apps, Azure Functions, API Management, and other systems

Without proper Message Types and Search Fields, your Logic Apps events are stored but not searchable by business data. Learn more: Log Event Processing

Info

When you deploy new workflows, Nodinite automatically monitors and logs the data, provided that the Logging feature is enabled (Configuration - Logging) and the Azure diagnostics are properly set up (Prerequisites - Logic Apps).

Log Features

Nodinite Azure agents use the Azure built-in Diagnostics (Standard and Consumption) feature and offer you a long-term archiving solution for your Logic Apps. Your Azure Subscriptions limit how long Azure stores tracked events (Retention with major drawbacks). With Nodinite you have fine-grained control over how long data stays available for your business in the Log Databases. Store as much data as you like, for as long as you like.

  • No coding required(!) i.e. NO VENDOR LOCK-IN
  • Correlation for individual runs - Without custom coding(!)
  • Successful/Failed runs - The Log Status Code indicates the outcome of the run (Successful runs and Failed runs settings)
  • Failed Triggers (Trigger settings)
  • Non-Events - Get alerts for traffic patterns that don't meet your thresholds. Use logged data together with Log Views and the Non-Events Agent to create virtually any non-event check imaginable
    • Minimum number of runs over the lookback period
    • Maximum number of runs over the lookback period
    • Longest allowed Duration over the lookback period
  • Shorter retention, lower costs - Nodinite has secure, low-cost, long-term storage, so you can shorten the Azure run-history retention; see Reduce Azure Logic Apps Run History Retention to Lower TCO
  • Enable and Disable Logging (Configuration - Logging)
  • Safe to stop - For each Logic App, the agent keeps track of when it downloaded the last logged event, and automatically resumes operations
    • Allows upgrading the agent at any time (Update)
    • Allows Internet Access to be unavailable
    • You are free to do whatever you want with your Logic Apps at any time
  • Action Events - Based on your filter settings:
    • In - All your inbound events are logged
    • Out - All your outbound events are logged
  • Tracked Properties - The agent logs all your custom coded Tracked Properties according to your filter settings.

    Tip

    Add Code to Workflows for Tracked Properties using Nodinite Context Options for an even better experience for you and your business

With the Nodinite Log Views in the Web Client, you dig into logged data without the User having access to the Azure Portal.

  • Run history - Use the RunId to perform correlated search operations (Application Interchange Id in Nodinite). The example below uses the Group By feature; see Design grouped Log Views for Runtime Inspection. Log View grouped by RunId
    Example of grouped, correlated data for a run spanning Logic Apps, APIMs, and Functions.
  • Triggers and Actions - The agent automatically logs all Triggers and Actions according to the filter settings. Logged Triggers and Actions in a Log View
    Example of the logged Triggers and Actions from a Logic App run.
  • Payload - If you include the payload in the Logging (filter setting), click the Action button and then click the 'View message body' menu item. View message body menu item in the Log View
    The 'View message body' menu item opens the logged payload.
    The body then displays on screen: Logged Logic Apps message payload
    Example of a logged Logic Apps message payload.

    Tip

    You can use a Stylesheet to render the base64 encoded payload as you see fit; review the 'Base64Decode XML from JSON' user guide.

  • Tracked Properties - If you include tracked properties in the logging (filter setting), click the small button and then click the 'Context values' tab. Tracked properties on the Context values tab
    Tracked Properties from the Logic App run, shown as context values.

To search for failed runs, create a Log View (Add or manage Log View) and use the Log Status Code as a Search Field (built-in).

Log View listing a failed Logic Apps action
Example of a failed Action found by its Log Status Code.

Failed runs monitoring is built-in; see Failed Runs and Manage failed runs:

Manage failed runs dialog
The Manage failed runs dialog lists failed runs for a Logic App.

Frequently asked questions

Additional solutions to common problems and the FAQ for the Nodinite Azure Logic Apps Logging and Monitoring agent exist in the Troubleshooting user guide.

How do I get started?

Follow the Prerequisites user guide, then Install and Configure the agent.

How do I access the Logged data?

Users access logged data through Log Views with Role-based security. The User access to logic apps logging guide shows the steps.

Add correlation ID to Service Bus Queue message 

"CorrelationId": "@{workflow()['run']['name']}",

Read correlation Id from Service Bus Queue Message 

@{if(equals(string(triggerBody()),''), guid(), coalesce(triggerOutputs().body?['CorrelationId'], guid()))}

Next Steps