Monitoring in IIB

Monitoring is a feature in IIB which enables us to log events when something happens at a node. By default the logs are pushed to a topic. Developers can create a queue subscribing to that default topic(How to get the default topic name is explained below in the same blog). These events can also be pushed to DB or consumed by monitoring applications such as websphere business monitor for auditing and replay of messages.

There are two types of events in IIB.

1. Terminal events –> The events that are emitted by the terminals of a node in II B
   • Out Terminal –> Event generated when the control passes successfully though OUT terminal of that particular node.
   • In Terminal –> Event generated when the control passes successfully though IN terminal of that particular node .
   • Failure Terminal –> Event generated when the control passes through the failure terminal of that particular node.
   • Error Terminal –> Event generated when the control passes through the Error terminal of that particular node.
   • HTTP Timeout Terminal –> Event generated when the control passes through the HTTP Timeout Terminal.
   • Catch Terminal –> Event generated when the control passes through the Catch Terminal.
2. Transactional events –> The events that are emitted by the transaction of a node in IIB.
   • Transaction Start –> When the transaction is started.
   • Transaction End –> When the transaction is ended.
   • Transaction Rollback –> when the transaction is rolled back.

Based on the nodes the events are available. Like transactional events are available only on input nodes.Same applies for terminals node. All terminal events may not be available on all nodes. Like catch terminal is only available on Input nodes and trycatch nodes.

Steps to setup monitoring

Step1: configuring monitroing

There are two ways to configuring monitoring. One: Node properties. Two: Monitoring profile

Let’s first have a look at configuring the monitoring by using node properties.

• On you flow, select the node for which you want to configure monitoring and goto properties and then to monitoring tab. And then select “Add”. You will see pop up screen as shown below

• On basic tab, in Event source section there is a drop down in which we select the event for which we want to emit logs. In Event source address section the value specifies the address(Node name) for which we are configuring events. It is not editable in this screen to change it we need to change the node value.In the Event name section the value specifies a literal which is associated for emitted event which is helpful to differentiate the events emitted(Like INFO, ERROR, DEBUG). In Event filter section we give true() or false() or a xpath which evaluates to true/false. This is like a on/off switch whether to emit event or not. In Event Payload section we specify the xpath that we want to emit.

• On Correlation tab, we have 3 types of event correlations to link events emitted by flow. If you select correlator value to automatic, broker will try to find the correlator from environment path. If there is no parent correlator in Environment, the correlator value will be null except for local correlator(It will generate a unique value).
• The Local transaction correlator is used to link between events emitted by a message flow. On input node set it to automatic where it will generate a unique value and the same will be used till the end of the flow. To specific a value use the xpath.
• The Parent transaction correlator is used to link between two different message flows(Like facade and canonical).
• The GlobalTransactionID field contains an identifier from the message header or payload. This identifier correlates events from the external process and IBM® Integration Bus.

• On Transaction tab, we have 3 values which control when the events need to be emitted. If you select message flow, events are emitted when message flow commits transaction. If you select NONE events are emitted regardless the message flow transaction commits or roll back. If you select Independent, a group of events will be emitted regardless the message flow transaction commits or rolls back.

Now let’s have a look at configuring monitoring using monitoring profile

Monitoring profile helps us to configure monitoring for a message flow nodes at run time. All the properties that can be configured on monitoring properties of node,can be filled out in a xml which we call it as monitoring profile as shown below. Once the properties are filled in monitoring profile.xml, this can be associated with a node of a message flow which is already deployed in a Integration Server. With this approach there is no need to do a redeployment or code changes. That is why its called a run time approach. In the earlier approach we need to make changes to the message flow, rebuild the .bar file and deploy the .bar(development time approach).

<p:monitoringProfile
xmlns:p="http://www.ibm.com/xmlns/prod/websphere/messagebroker/6.1.0.3/monitoring/profile" p:version="2.0">
    <p:eventSource p:enabled="true" p:eventSourceAddress="SOAPInput.transaction.Start"> --> This tells us the source event(Node/terminal name or event name)

        <p:eventPointDataQuery>
            <p:eventIdentity>
                <p:eventName p:literal="INFO" p:queryText="To dynamically read the value from input specify Xpath"/> --> Event Name
            </p:eventIdentity>
            <p:eventCorrelation> --> This is to add corelation to track the related transactions
                <p:localTransactionId p:queryText="" p:sourceOfId="automatic"/>
                <p:parentTransactionId p:queryText="" p:sourceOfId="automatic"/>
                <p:globalTransactionId p:queryText="" p:sourceOfId="automatic"/>
            </p:eventCorrelation>
           <p:eventFilter p:queryText="true()"/>   -->This is filter the events by specifying the conditions
		   <p:eventUOW p:unitOfWork="messageFlow" />    --> Specify when the message/event has to be emitted 
		</p:eventPointDataQuery>

        <p:applicationDataQuery> --> To decide what part of the message assembly to be emmited
            <p:simpleContent p:dataType="boolean" p:name="" p:targetNamespace="">
                <p:valueQuery p:queryText=""/>
            </p:simpleContent>
            <p:complexContent p:name="" targetNamespace="">
                <p:payloadQuery p:queryText=""/>
            </p:complexContent>
        </p:applicationDataQuery>
		
        <p:bitstreamDataQuery p:bitstreamContent="all" p:encoding="base64Binary"/> --> To emit the bitstream data
    </p:eventSource>
</p:monitoringProfile>

Steps to associate monitoring profile to node/flow

After preparing the monitoring profile, We need to associate the monitoring profile with message flow. To do so, run below coammnds

mqsicreateconfigurableservice <Broker> -c MonitoringProfiles -o mySampleMonitoringProfile
mqsichangeproperties <Broker> -c MonitoringProfiles -o mySampleMonitoringProfile -n profileProperties -p <MonitoringProfile.xml>
mqsichangeproperties <Broker> -c MonitoringProfiles -o mySampleMonitoringProfile -n useParserNameInMonitoringPayload -v TRUE
mqsichangeflowmonitoring <Broker> -e <EG> -k <AppName> -f <FlowName> -m <MonitoringProfileName>

Running the above command will create a configurable service and add monitoring profile to it and then associate it a particular flow in an Application.

If your flow is parked in Integration project, directly give the flow name as shown below

mqsichangeflowmonitoring <Broker> -e <EG> -f <FlowName> -m <MonitoringProfileName>

Step2 : Activating Monitoring

Adding monitoring at node level or with a profile will not enable monitoring. For this we need to run commands as shown below. Run the below commands after deploying the message flow.

Command to enable monitoring for a particular message flow in an Application mqsichangeflowmonitoring <Broker> -e <EG> -k <AppName> -f <FlowName> -c active

Command to enable monitoring to all the applications in all the execution groups                                 mqsichangeflowmonitoring <Broker> -g -j -c active

Command to enable monitoring to specific nodes in a message flow   mqsichangeflowmonitoring <Broker> -e <EG> -f <FlowName> -s "Node1_Label.terminal.out,Node2_Label.terminal.in" -i enable

Note : After every new deployment, we need to run the above commands.

To verify if monitoring is enabled or not run the below commands.

mqsireportflowmonitoring <Broker> -e <EG> -k <AppName> -f <FlowName>

mqsireportflowmonitoring <Broker> -g -j

mqsireportflowmonitoring <Broker> -e <EG> -f <FlowName> -k <AppName> -s “Node1_Label.terminal.out,Node2_Label.terminal.in

Doing the above configuration will make broker to push monitor logs for events configured.

Now where to see these logs ? Where does broker saves these logs ?

By default broker publishes the monitoring logs to Topic. We can subscribe to this Topic and see the monitoring logs. The Integration Node to which you want to enable monitoring logs should have a Queue manager configured. The default topic is created on the associated Queue manager of the Integration Node. Below is the default Topic to which your broker publishes logs.

$SYS/Broker/integrationNodeName/Monitoring/integrationServerName/flow_name

For example if your flow named Sample_MF is deployed in default Integration server of TESTNODE_UserName Integration node, then your topic will be
$SYS/Broker/TESTNODE_UserName/Monitoring/default/Sample_MF

Create a subscriber to the above Topic by using MQ Explorer.And give the above as topic string when you create Subscriber. Now this subscriber will continuously keep listening for messages on that particular Topic string and save those message to the base queue that you have specified during the creation of subscriber.

Events are published to a topic, where they can be read by multiple subscribers. The hierarchical structure allows subscribers to filter the events that they receive. One subscriber can receive events from all message flows in the integration node, while another receives only the events from a single integration server.

Summary:

1. Configure monitoring either using node properties or monitoring profile.
2. Deploy the flow if you have used node props. If you have used the later run commands to associate profile to flow.
3. Run commands to enable monitoring. And then verify by commands.
4. Create a subscriber on the topic string.
5. Run a request and you should be able to see your logs saved in Queue.