IBM Integration Bus & ACE Logging with IBM MQ Monitoring Agent

Achieve end-to-end logging and full observability for IBM Integration Bus and App Connect Enterprise workflows using the unified Nodinite IBM MQ Monitoring Agent. Starting with v7.2.0, this single agent provides both IBM MQ monitoring (queue depth, channels, listeners) AND IBM Integration Bus logging (Monitoring Events, payloads, correlation).

On this page, you will learn how to:

✅ Configure the unified agent to consume IBM Monitoring Events from IIB/ACE workflows
✅ Map IBM Monitoring Events to Nodinite Log Events for full traceability
✅ Use Remote GUI configuration instead of legacy Settings.json files
✅ Understand message type mapping for business intelligence and searchability
✅ Create IBM Monitoring Profiles to emit events from your workflows

Tip

New in v7.2.0: IBM Integration Bus logging is now built into the IBM MQ Monitoring Agent with Remote GUI configuration, .NET 10 runtime, gMSA support, and AI Diagnostics. No separate agent required!

Understanding the Unified Agent Architecture

The IBM MQ Monitoring Agent provides two complementary capabilities in a single installation:

1. Monitoring – Real-Time State Visibility

• What: Current queue depths, message age, channel status, listener availability
• Purpose: Proactive alerting when thresholds are breached (queue backlog, channel failure, listener down)
• Configuration: Monitoring tab in Remote Configuration modal
• Documentation: Monitoring IBM MQ

2. Logging – Historical Transaction Traceability

• What: IBM Monitoring Events from Integration Bus/ACE workflows with full payloads and context values
• Purpose: End-to-end transaction tracking, compliance auditing, business intelligence
• Configuration: Logging tab in Remote Configuration modal (this page)
• Documentation: This page

📸 Screenshot needed: Architecture diagram showing IBM MQ Agent with two tabs - Monitoring (queue depth, channels) and Logging (IIB/ACE Monitoring Events).

The diagram above illustrates how the unified IBM MQ Monitoring Agent handles both monitoring (real-time state) and logging (historical transactions) from a single agent installation.

Why Unified Logging with IBM MQ Agent?

Previously, IBM Integration Bus logging required a separate standalone agent with file-based Settings.json configuration, IBM MQ Client library dependencies, and .NET Framework 4.8. The unified agent eliminates these limitations:

Getting Started with IBM Integration Bus Logging

Prerequisites

Before configuring logging, ensure you have:

1. IBM MQ Monitoring Agent v7.2.0+ installed and configured for monitoring

   • See Install IBM MQ Monitoring Agent if not yet installed
   • See Prerequisites for IBM MQ Monitoring Agent for requirements

2. IBM Integration Bus or App Connect Enterprise

   • IBM Integration Bus 9, 10 OR
   • IBM App Connect Enterprise 11, 12, 13

3. IBM MQ Queue for Monitoring Events

   • Queue must have 'Default read ahead' set to 'No'
   • Service account must have GET and BROWSE permissions

4. Nodinite Logging Agent Configuration

   • Created in Nodinite Administration → Log Management → Logging Agents
   • LogAgentId obtained for use in agent configuration

5. IBM Monitoring Profile configured

   • Emits Monitoring Events to IBM MQ queue
   • See Create the Monitoring Profile below

Create the Monitoring Profile

IBM provides comprehensive documentation for creating Monitoring Profiles that emit IBM Monitoring Events to MQ queues:

You may also find this IBM blog post helpful:

• Auditing and Logging Using Monitoring Events In IBM Integration Bus/Message Broker

Key Monitoring Profile Settings

When creating the Monitoring Profile, ensure:

• Destination: IBM MQ Queue (e.g., IIB.MONITORING.EVENTS)
• Event Format: XML (Nodinite parses XML Monitoring Events)
• Event Scope: Configure which workflow nodes emit events (typically Entry, Exit, Failure)
• Payload Inclusion: Enable full payload capture for complete traceability

Configure Logging in IBM MQ Monitoring Agent

Once your IBM Monitoring Profile is emitting events to an MQ queue, configure the IBM MQ Monitoring Agent to consume and process those events.

Step 1: Open Remote Configuration

From the Nodinite Administration page, navigate to:

Administration → Monitor Management → Monitoring Agent Configuration

Click the 'Configuration' button for your IBM MQ Monitoring Agent.

![Remote Configuration Button][placeholder_remote_config_button]
📸 Screenshot needed: The Configuration button in Monitoring Agent Configuration administration page (same as IBM MQ monitoring documentation).

Step 2: Click the Logging Tab

In the Remote Configuration modal, click the 'Logging' tab (next to the Monitoring tab).

![Logging Tab][placeholder_logging_tab]
📸 Screenshot needed: Remote Configuration modal showing "Monitoring" and "Logging" tabs. Logging tab is selected and empty (before adding logging sources).

Note

Logging vs. Monitoring Tabs:

• Monitoring tab - Configure IBM MQ queue managers for real-time monitoring (queue depth, channels, listeners)
• Logging tab - Configure IBM MQ queues for consuming IBM Integration Bus Monitoring Events

Step 3: Add Logging Source

Click the Add button to configure a new logging source.

![Add Logging Source][placeholder_add_logging_source]
📸 Screenshot needed: Logging tab with "Add" button highlighted. Shows empty state with instructions to add a logging source.

Step 4: Configure Logging Source Settings

Complete the following fields:

![Logging Source Configuration][placeholder_logging_source_config]
📸 Screenshot needed: Expanded logging source configuration form showing all fields (Enable Logging, Name, Queue Manager dropdown, Queue Name, LogAgentId, Polling Interval, etc.).

Basic Settings

• Enable Logging - When checked, the agent consumes Monitoring Events from this queue
• Name - User-friendly name for this logging source (e.g., "Production IIB Events", "Dev ACE Workflows")
• Description - Optional description for this logging configuration

Queue Manager and Queue Settings

• Queue Manager - Select from already-configured queue managers in the Monitoring tab

  • Important

    The queue manager must first be configured in the Monitoring tab before it appears in this dropdown. If your queue manager is not listed, switch to the Monitoring tab and add it there first.

• Queue Name - Name of the queue containing IBM Monitoring Events (e.g., IIB.MONITORING.EVENTS, ACE.AUDIT.QUEUE)

Nodinite Integration Settings

• LogAgentId - The Logging Agent Configuration ID from Nodinite Administration

  • Navigate to Administration → Log Management → Logging Agents to create/view Logging Agent Configurations
  • Copy the numeric ID from the configuration

• Log API - URI to the Nodinite Log API (typically auto-populated from agent installation)

  • Example: https://nodinitesrv01/Nodinite/LogAPI/
  • Use HTTPS with FQDN for production environments

Polling and Processing Settings

• Polling Interval - How often to check the queue for new Monitoring Events (30-300 seconds, default: 60)
  • Lower values provide faster log ingestion but increase MQ load
  • Higher values reduce load but delay log visibility
  • Recommended: 30-60 seconds for production, 60-120 seconds for dev/test

Tip

Performance Consideration: If your queue receives high-volume events (>1000 messages/minute), consider lowering the polling interval to 30 seconds to prevent queue backlog. Monitor queue depth using the Monitoring tab to ensure events are consumed faster than they arrive.

IBM Integration Bus Version-Specific Settings

• Default Log Status Code ^{New 7.2.0} - For ACE (v11+) where @terminal attribute is removed from Monitoring Events

  • -1 (default) - Auto-detect status from event data
  • 0 - Treat all events as successful unless error indicators present
  • Custom value - Set a specific status code for all events from this source

• Default Message Type Name ^{New 7.2.0} - Default Message Type if not determined from payload analysis

  • Avoid generic names like "Monitoring Event" (poor searchability)
  • Use descriptive names like "ACE Transaction" or "IIB Workflow Event"
  • Best practice: Configure Message Types with proper matching rules instead of relying on defaults

Bad Message Handling

• Bad Message Queue - Queue name for malformed Monitoring Events that cannot be processed
  • Example: IIB.MONITORING.BADMESSAGES
  • If blank, bad messages remain on source queue and are skipped
  • Recommended: Always configure a bad message queue for troubleshooting

Step 5: Save Configuration

Click 'Save' or 'Save and close' to persist your changes.

The IBM MQ Monitoring Agent will:

1. Connect to the specified queue manager
2. Poll the logging queue at the configured interval
3. Consume Monitoring Events (XML messages)
4. Parse event structure and extract metadata
5. Send transformed events to Nodinite Log API
6. Store events in Nodinite Log Database for searching and analysis

Note

Synchronization Delay: Changes are applied after the next agent synchronization interval. Click 'Sync Now' button to force immediate synchronization.

Mapping from IBM Monitoring Event to Nodinite Log Event

This section describes how IBM Monitoring Events are transformed into Nodinite Log Events.

Important

Critical: Configure Message Types for Business Intelligence

When IBM Monitoring Events arrive in Nodinite:

1. Message Types identify message formats from monitoring event properties or XML payload content (PurchaseOrder, Invoice, Shipment, etc.)
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 or correlation IDs
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 IBM Integration Bus workflows and other systems

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

Version Differences: ACE vs. IIB

IBM changed the Monitoring Event XML structure between versions:

• ACE (Version 11 - 13): New XML schema with removed @terminal attribute
• IIB (Version 9 and 10): Legacy XML schema with @terminal attribute

The agent automatically detects the version based on XML structure.

Version 11 - 13 (ACE)

This section applies to IBM ACE

Sample IBM Monitoring Event (ACE 11+ XML Message):

<?xml version="1.0" encoding="UTF-8"?>
<mon:event xmlns:mon="http://www.ibm.com/xmlns/monitoring/event/v2">
	<mon:eventPointData>
		<mon:eventData mon:productVersion="110010"
			mon:profileVersion="11" mon:eventSourceAddress="HTTP Input.transaction.Start">
			<mon:eventIdentity mon:eventName="HTTP Input.TransactionStart" />
			<mon:eventSequence mon:creationTime="2020-07-20T16:20:21.776758Z"
				mon:counter="1" />
			<mon:eventCorrelation mon:localTransactionId="40ddc412-f102-4840-a212-8b793d12b6bf-1"
				mon:parentTransactionId="" mon:globalTransactionId="" />
		</mon:eventData>
		<mon:messageFlowData>
			<mon:integrationServer mon:name="110010"
				mon:hostName="DESKTOP-7Q9JIP6" />
			<mon:application mon:name="Transformation_Map" />
			<mon:messageFlow mon:name="TestFlow" />
		</mon:messageFlowData>
	</mon:eventPointData>
	<mon:bitstreamData mon:encoding="base64Binary" mon:bitstream="PD94bWwgdmVyc2lvbj0iMS4..." />
</mon:event>

Key ACE Mapping Fields:

ACE-Specific Considerations:

• No @terminal attribute - Use DefaultLogStatusCode configuration to determine success/failure
• Base64 payload encoding - Agent automatically decodes mon:bitstreamData/@bitstream to extract payload
• Application grouping - Events are grouped by mon:application/@name for logical organization

Version 9 and 10 (IIB)

This section applies to IBM Integration Bus 9 and 10

Sample IBM Monitoring Event (IIB 9/10 XML Message):

<?xml version="1.0" encoding="UTF-8"?>
<MonitoringEvent xmlns="http://www.ibm.com/xmlns/monitoring/event"
    productVersion="80020" eventSourceAddress="Flow.transaction.Start"
    eventSequence="1" eventIdentity="Flow.TransactionStart"
    eventDateTime="2018-01-15T14:30:22.123456Z"
    localTransactionId="4a2e1234-5678-90ab-cdef-1234567890ab"
    parentTransactionId="" globalTransactionId=""
    terminal="Out">
    <IntegrationServer brokerName="IB10" executionGroupName="default" />
    <MessageFlow messageFlowName="TestFlow" />
    <Bitstream encoding="base64Binary">PD94bWwgdmVyc2lvbj0iMS4...</Bitstream>
</MonitoringEvent>

Key IIB Mapping Fields:

IIB-Specific Considerations:

• @terminal attribute - Automatically maps to LogStatusCode (Out=0, Failure=-1)
• Execution Group - Used as ApplicationName for grouping events
• Broker Name - Identifies the IIB broker instance

Message Type Configuration for Business Searchability

To make IBM Monitoring Events searchable by business data (Order IDs, Customer Names, Invoice Numbers, etc.), configure Message Types and Search Field Expressions.

Step 1: Create Message Type

Navigate to Administration → Log Management → Message Types.

Create a new Message Type (or update existing) with:

• Name: Descriptive name (e.g., "Order Processing Event", "Invoice Transaction")
• Match Pattern: XPath expression to identify this message type from Monitoring Event payload

Example XPath for detecting Order messages:

//*[local-name()='Order']

This matches any XML element named Order in the decoded Monitoring Event payload.

Step 2: Add Search Fields

For the Message Type, add Search Field Expressions to extract business data:

Example Search Fields for Order Processing:

Step 3: Test and Verify

After configuring Message Types:

1. Send a test transaction through your IIB/ACE workflow
2. Wait for Monitoring Event to be consumed (check polling interval)
3. Navigate to Log → Log Views
4. Search for your event using business identifiers (e.g., OrderNumber="ORD-12345")

If the search returns results, your Message Type configuration is correct!

Tip

Reindexing Historical Data: If you add new Search Fields to an existing Message Type, use the Reindex feature to extract values from already-logged events. This is one of Nodinite's unique advantages—you never lose data due to incomplete logging configuration.

Automatic Queue Cleanup

Unlike custom logging solutions that accumulate events indefinitely, Nodinite automatically consumes Monitoring Events from the IBM MQ queue after successful processing.

Benefits:

• ✅ No manual cleanup jobs required - Events are removed from MQ queue once logged
• ✅ No disk space waste - MQ queue stays empty or near-empty
• ✅ Retention controlled by Nodinite - Log retention policies determine how long events are stored
• ✅ High availability - If Nodinite is offline, events accumulate safely in MQ queue until service resumes

Queue Depth Monitoring:

Use the Monitoring tab in the same IBM MQ Monitoring Agent to set queue depth alerts for your logging queues:

• Warning threshold: 1000 messages (indicates processing lag)
• Error threshold: 5000 messages (indicates Nodinite service issue or network problem)

This ensures you're notified if Monitoring Events stop being consumed.

Troubleshooting IBM Integration Bus Logging

Events Not Appearing in Nodinite Log Views

Possible Causes:

1. Monitoring Profile not emitting events

   • Verify IBM Monitoring Profile is active in IIB/ACE
   • Check MQ queue depth - are events arriving on the queue?
   • Use MQ Explorer to browse messages in the logging queue

2. Agent not consuming events

   • Check agent diagnostics log for connection errors
   • Verify Queue Manager name matches configuration exactly
   • Ensure service account has GET and BROWSE permissions on logging queue

3. LogAgentId incorrect

   • Verify LogAgentId in configuration matches the ID in Nodinite Administration → Log Management → Logging Agents
   • Check Log API URI is correct and accessible from agent server

4. Bad message queue receiving events

   • Browse bad message queue for malformed events
   • Check agent diagnostics for parsing errors
   • Common issue: Monitoring Event XML structure doesn't match expected schema

Events Logged But Not Searchable

Possible Causes:

1. Message Type not configured

   • Create Message Type with XPath match pattern for your event payload structure
   • Test match pattern using sample event payload

2. Search Fields not extracting values

   • Verify XPath expressions using XML sample from actual Monitoring Event
   • Check for namespace issues in XPath (use local-name() function)
   • Reindex existing events after adding new Search Fields

High Queue Depth on Logging Queue

Possible Causes:

1. Polling interval too high

   • Reduce polling interval to 30 seconds if events arrive faster than consumption rate
   • Monitor trend over 24 hours to determine optimal interval

2. Agent service stopped

   • Check Windows Service status for IBM MQ Monitoring Agent
   • Review Windows Event Log for service crashes or errors

3. Network connectivity issue

   • Verify TCP connectivity between agent server and queue manager
   • Check firewall rules (port 1414 or custom listener port)

4. Log API performance issue

   • Check Nodinite Log API response times
   • Review SQL Server performance if Log Database is slow

Best Practices

1. Separate Monitoring and Logging Queues

Use different MQ queues for monitoring events vs. application messages:

• Monitoring Events Queue: IIB.MONITORING.EVENTS (consumed by Nodinite)
• Application Messages Queue: ORDERS.IN, INVOICES.OUT (consumed by business applications)

This separation prevents accidental mixing of audit events with business transactions.

2. Configure Queue Depth Alerts

In the Monitoring tab, add queue depth thresholds for logging queues:

• Warning: 1000 messages (10-15 minutes of backlog at typical volume)
• Error: 5000 messages (significant processing delay)

3. Use Descriptive Logging Source Names

Name logging sources by environment and purpose:

• ✅ Good: "Production IIB Events", "Dev ACE Workflows", "QA Integration Testing"
• ❌ Poor: "Logging1", "Queue2", "Test"

This improves clarity in diagnostics and audit logs.

4. Implement Message Type Standards

Create consistent Message Type naming across all workflows:

• Transaction types: OrderProcessing, InvoiceGeneration, ShipmentNotification
• Error events: OrderProcessingError, InvoiceGenerationError
• Audit events: UserLoginAudit, ConfigurationChangeAudit

This enables cross-workflow correlation and reporting.

5. Monitor Bad Message Queue

Regularly review the Bad Message Queue to identify:

• Malformed Monitoring Events (indicates IIB/ACE configuration issue)
• Unexpected XML structures (may need Message Type updates)
• Encoding problems (Base64 decoding errors)

Set up alerts when bad message queue depth exceeds 10 messages.

Related Topics

IBM MQ Monitoring Agent:

• IBM MQ Monitoring Agent Overview
• IBM MQ Configuration
• IBM MQ Prerequisites
• Install IBM MQ Monitoring Agent

Logging Concepts:

• What is a Log Event?
• Message Types
• Search Field Expressions
• Log Views

Legacy Documentation (Reference Only):

• IBM Integration Bus Logging Agent (Deprecated)