Logging with the IBM Integration Bus Logging Agent

Unlock full visibility and control of your IBM Integration Bus workflows by leveraging Nodinite for end-to-end logging. This guide shows you how to centralize, govern, and map IBM Monitoring Events to Nodinite Log Events, empowering your team with actionable insights and compliance-ready traceability.

✅ Achieve end-to-end logging and monitoring for all IBM Integration Bus events
✅ Centralize and govern logs for compliance and operational excellence
✅ Map IBM Monitoring Events to Nodinite Log Events for full traceability
✅ Eliminate manual cleanup—Nodinite handles log retention automatically

On this page, you will learn how to enable and configure end-to-end logging of IBM Monitoring Events with Nodinite. Discover the technical process, mapping rules, and best practices for seamless integration.

Create the Monitoring Profile

IBM provides user guides for creating the required Monitoring Profile, which emits IBM Monitoring Events:

You may also find this IBM blog post helpful:

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

Technical details for Logging IBM Monitoring Events

In complex environments, you may have multiple IBM Integration Bus workflows running on different servers, resulting in a high volume of Monitoring Events. Developers may enable or tune logging differently, leading to inconsistent governance. Nodinite provides total control, centralized logging, and active documentation using the Repository Model.

With Nodinite, you can centralize logging and manage or share insights from IBM Monitoring Events.

The diagram above illustrates how IBM Monitoring Events are collected and processed by Nodinite for centralized logging.

Tip

Messages put on IBM MQ queues are consumed by Nodinite, so you do not need to create custom cleaning tasks.

Scenario: Basic Request/Response

In this scenario we have one or more Consumers of the IBM Integration Bus workflow.

IBM Monitoring Events enabled

Enable logging by defining Monitoring profiles. With the built-in IBM Monitoring Events enabled the Request and the Response is caught by the policy and is copied to the IBM MQ destination queue.

Nodinite Nodinite Logging

The Nodinite IBM Integration Bus Logging Agent consumes the Monitoring Events on the IBM MQ queues. This means that Nodinite will NOT waste your disk space or other valuable resources over time and you do not have to setup any cleaning maintenance jobs.

Mapping from IBM Monitoring Event to Nodinite Log Event

This paragraph describes the how IBM Monitoring Events are mapped to Nodinite Log Events.

You must first configure IBM Integration Bus to emit Monitor Events to one or more queues, read more in the Configuring IBM Integration Bus Logging user guide.

Note

IBM changed the format with version 11 (same for version 11 - 13) compared to version 9 and 10.

• ACE - Version 11 - 13
• IIB - Version 9 and 10

Version 11 - 13 (ACE)

This section applies to IBM ACE

Sample IBM Monitoring Event in version 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:uniqueFlowName="110010.Transformation_Map.Transformation_Map"
				mon:name="Transformation_Map" mon:threadId="12244" />
			<mon:node mon:nodeLabel="HTTP Input" mon:nodeType="ComIbmWSInputNode" />
		</mon:messageFlowData>
	</mon:eventPointData>
	<mon:bitstreamData>
		<mon:bitstream mon:serializationEncoding="base64Binary"
			mon:dataCCSID="1208" mon:dataEncoding="546">UE9TVCBodHRwOi8vbG9jYWxob3N0Ojc4MDAvVHJhbnNmb3JtYXRpb25fTWFwIEhUVFAvMS4xDQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXRmLTgNClVzZXItQWdlbnQ6IEphdmEvMS44LjBfMjUxDQpIb3N0OiBsb2NhbGhvc3Q6NzgwMA0KQWNjZXB0OiB0ZXh0L2h0bWwsIGltYWdlL2dpZiwgaW1hZ2UvanBlZywgKjsgcT0uMiwgKi8qOyBxPS4yDQpDb25uZWN0aW9uOiBrZWVwLWFsaXZlDQpDb250ZW50LUxlbmd0aDogNjgwDQpYLU9yaWdpbmFsLUhUVFAtQ29tbWFuZDogUE9TVCBodHRwOi8vbG9jYWxob3N0Ojc4MDAvVHJhbnNmb3JtYXRpb25fTWFwIEhUVFAvMS4xDQpYLVNlcnZlci1OYW1lOiBsb2NhbGhvc3QNClgtU2VydmVyLVBvcnQ6IDc4MDANClgtUmVtb3RlLUFkZHI6IDEyNy4wLjAuMQ0KWC1SZW1vdGUtSG9zdDogbG9jYWxob3N0DQpYLVNjaGVtZTogaHR0cA0KDQo8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KPFNhbGVFbnZlbG9wZT4NCgk8SGVhZGVyPg0KCQk8U2FsZUxpc3RDb3VudD4xPC9TYWxlTGlzdENvdW50Pg0KCQk8VHJhbnNmb3JtYXRpb25UeXBlPnhzbDwvVHJhbnNmb3JtYXRpb25UeXBlPg0KCTwvSGVhZGVyPg0KCTxTYWxlTGlzdD4NCgkJPEludm9pY2U+DQoJCQk8SW5pdGlhbD5UPC9Jbml0aWFsPg0KCQkJPEluaXRpYWw+SjwvSW5pdGlhbD4NCgkJCTxTdXJuYW1lPkR1bm53aW48L1N1cm5hbWU+DQoJCQk8SXRlbT4NCgkJCQk8Q29kZT4wNDwvQ29kZT4NCgkJCQk8Q29kZT4wNTwvQ29kZT4NCgkJCQk8Q29kZT4wMTwvQ29kZT4NCgkJCQk8RGVzY3JpcHRpb24+VGhlIE9yaWdpbiBvZiBTcGVjaWVzPC9EZXNjcmlwdGlvbj4NCgkJCQk8Q2F0ZWdvcnk+Qm9va3MgYW5kIE1lZGlhPC9DYXRlZ29yeT4NCgkJCQk8UHJpY2U+MjIuMzQ8L1ByaWNlPg0KCQkJCTxRdWFudGl0eT4wMjwvUXVhbnRpdHk+DQoJCQk8L0l0ZW0+DQoJCQk8QmFsYW5jZT44MS44NDwvQmFsYW5jZT4NCgkJCTxDdXJyZW5jeT5FdXJvczwvQ3VycmVuY3k+DQoJCTwvSW52b2ljZT4NCgk8L1NhbGVMaXN0Pg0KCTxUcmFpbGVyPg0KCQk8Q29tcGxldGlvblRpbWU+MTIuMDAuMDA8L0NvbXBsZXRpb25UaW1lPg0KCTwvVHJhaWxlcj4NCjwvU2FsZUVudmVsb3BlPg==</mon:bitstream>
	</mon:bitstreamData>
</mon:event>

Mapping table between Log Event and the IBM Monitoring Event

Tip

Use the Nodinite Context Options to override default behaviour

Version 9 and 10

Sample IBM Monitoring Event (XML Message)

<?xml version="1.0" encoding="UTF-8"?>
<wmb:event xmlns:wmb="http://www.ibm.com/xmlns/prod/websphere/messagebroker/6.1.0/monitoring/event">
	<wmb:eventPointData>
		<wmb:eventData wmb:eventSourceAddress="MQInput1.terminal.in" wmb:eventSchemaVersion="6.1.0.3" wmb:productVersion="7000">
			<wmb:eventIdentity wmb:eventName="MQInput event"/>
			<wmb:eventSequence wmb:creationTime="2017-09-23T12:00:00+02:00" wmb:counter='2'/>
			<wmb:eventCorrelation wmb:localTransactionId="a13122ae-1c01-0000-0080-b1b02528c6cd" wmb:parentTransactionId="456" wmb:globalTransactionId="789"/>
		</wmb:eventData>
		<wmb:messageFlowData>
			<wmb:broker wmb:UUID="d53122ae-1c01-0000-0080-b1b02528c6bf" wmb:name="myBroker"/>
			<wmb:executionGroup wmb:UUID="d43122ae-1c01-0000-0080-b1b02528c6bf" wmb:name="default"/>
			<wmb:messageFlow wmb:UUID="e6d224ae-1c01-0000-0080-9100cd1a61f7" wmb:name="myMessageFlow" wmb:threadId="4201" wmb:uniqueFlowName="myBroker.default.myMessageFlow"/>
			<wmb:node wmb:nodeLabel="MQInput1" wmb:nodeType="ComIbmMqInputNode" wmb:terminal="in" wmb:detail="MYMESSAGEFLOW.IN"/>
		</wmb:messageFlowData>
	</wmb:eventPointData>
	<wmb:applicationData xmlns="">
		<wmb:simpleContent wmb:name="invoiceNo" wmb:targetNamespace="" wmb:dataType="string" wmb:value="567"/>
		<wmb:complexContent wmb:elementName="customerName" wmb:targetNamespace="">
			<customerName>
				<firstName>Steve</firstName>
				<lastName>Bloggs</lastName>
			</customerName>
		</wmb:complexContent>
	</wmb:applicationData>
	<wmb:bitstreamData>
		<wmb:bitstream wmb:encoding="base64Binary">TUQgIAIAAAAAAAAACAAAAP////8AAAAAIgIAALUBAAAgICAgICAgIAAAAAAAAAAAQU1RIFFNMSAgICAgICAgIHo640ggABsHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFFNMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg</wmb:bitstream>
	</wmb:bitstreamData>
</wmb:event> 

Mapping table between Log Event and the IBM Monitoring Event

If this is not a GUID, then the value is in the Context collection with the ThreadId as the key| ||string|ProcessingTime|N/A||

Tip

Use the Nodinite Context Options to override default behaviour

SimpleContent

The following simpleContent will be converted to Nodinite Context Properties (Key Value pairs):

Info

The wmb prefix is just a prefix, it can be different in your instance/examples and you can use the Nodinite Context Options to override default behaviour

Additional field values

The following example converts simpleContent to Additional Field Values:

Override options

Use the following override options to change some properties of the final Log Event before it is pushed to Nodinite.

Event Direction

You can provide additional information about the direction of the logged event(EventDirection). Simply log the message using simpleContent using either the integer or string value as exemplified in the table below:

<p:simpleContent p:name="ExtendedProperties/1.0#EventDirection" p:dataType="integer"><p:valueQuery p:queryText="17"/></p:simpleContent>

Example sending EventDirection ExternalIncoming using integer value

<p:simpleContent p:name="ExtendedProperties/1.0#EventDirection" p:dataType="string"><p:valueQuery p:queryText="ExternalIncoming"/></p:simpleContent>

Example sending EventDirection ExternalIncoming using string value

ComplexContent

complexContent will be converted to Nodinite Context Properties (Key Value pairs):

<wmb:complexContent wmb:elementName="customerName" 
                            wmb:targetNamespace="">
    <customerName>
        <firstName>Steve</firstName>
        <lastName>Bloggs</lastName>
    </customerName>
</wmb:complexContent>

<customerName><firstName>Steve</firstName><lastName>Bloggs</lastName></customerName>

Tip

Use the Formula plugin to extract values from ComplexContent context properties!

ExceptionList

If you have a Monitoring Profile that catches the error information as ExceptionList in the ComplexContent element then Nodinite will replace any existing body with this XML content. The LogStatus code if not overridden will be set to -2.

The name of the ComplexContent element does not matter when the content is ExceptionList xml data.

An exception Log Event if not overridden has this Message Type Name: IBM.IIB.ExceptionList/6.1.0.

bitstreamData

The content of the <bitstreamData> element is the payload encoded as a base64string. Nodinite internally happens to use the same base64string encoding for the payload so this value is simply copied to the body property of the Log Event.

Transaction Ids

Some properties for correlation are put in the Additional Fields but they are also copied to the Context Properties.

<wmb:eventCorrelation wmb:localTransactionId="123" wmb:parentTransactionId="456" wmb:globalTransactionId="789"/>

RFH2 Header

If your IBM MQ message has an RFH2 header, then, the IBM Integration Bus Logging Agent converts all these to Context Properties and thus becomes an integral part of the Nodinite Log Event.

Nodinite IBM Integration Bus Logging Agent takes care of the RFH2 header automatically if it exists on the IBM MQ queue

Next Step

Now Add or manage Log Views and use the Log Views to enjoy end-to-end tracking with Nodinite including IBM Monitoring Events.

• Context Options - Additional optional properties
• Log Agents - Manage Log Agents

Related Topics

• Log Event