Tuesday, 25 March 2014

Event Monitoring in WMB

Auditing vs Logging
From what I have worked on, there is a difference between them based on their nature. A log is(may be) perishable while an audit trail is secure and non-perishable. As a result ou will never log sensitive information or information which you will need later. An audit trail on the other hand is secure. It is something that should not be perished easily.
For example : in a bank software you will audit the transactions;: credit-debit, failed transactions etc. This audit will be in to the database. THe log file may save the transaction that crashed when the softare failed and did not enter the system.
Difference between Audit log and normal log
An audit log contains all the information necessary to follow a user's interaction with a system. It will usually contain more information and detail than what is necessary to have in day-to-day operations.
You can think of it in terms of a phone system. You can record every call that passes through the phone system to be able to go back in time and prove exactly what a person said, but it wouldn't be feasible to use a log containing all of that information for taking care of phone system operations.
An audit log usually contains more sensitive information than other system logs so access to it should be more restricted.
Example scenario:
i use audit to trace the users actions, and to reconstruct current values.
for instance, we have a table with giftcardvalues, and we can see in that table that the current value is $100 and the original value $200.
Is that correct, we don't know....
for that question to be answered we have to know what happened in between.
so we have a audit table in which we save all actions for that table, like this:
jan. 1 init $200
jan. 3 add $300
jan. 5 subtract $350
jan. 7 check value (returned 150)
jan. 8 subtract $50
now i know what to say if a user calls and says: hey, where did my $100 go?
'normal' logging is used to log errors, process info etc. wo we can debug the app when, for instance, the audit info and the actual values for the giftcard don't match, so we can see what is going wrong in the code.
Statistics vs Event Monitoring
Statistics : Gives the statistical information about Broker,Execution Group,Message Flow.This will also  collect metrics information about the broker,EG,Message flow ,Resources such as JMS,JDBC,FTP,etc.
Event Monitoring:
Message broker emits a monitoring event (an XML document) when something interesting happens. Events are typically emitted to support transaction monitoring, transaction auditing, and business process monitoring. The event XML conforms to the monitoring event schema WMBEvent.xsd.
Event types
You can configure a message flow to emit two types of events: transaction events and terminal events. There are three types of transaction events: start, end, and rollback. The transaction events are emitted only from input nodes such as MQInput and HTTPInput. Terminal events are emitted from any terminal of any node.

Event Monitoring works on the basis of Pub-Sub feature of message broker.The events emitted from terminals or transaction in a flow are XML messages and they are published to specific topics.
Eg:  Topic name here is  BROKER_EVENTS_DEFAULT
       
The form of the Topic String is :
$SYS/Broker/<brokerName>/Monitoring/<executionGroupName>/<flowName>

Topic String in the example is $SYS/Broker/RadBroker1/Monitoring/default/MonitoringFlow
As per the above specification,the events emitted in the flow “MonitoringFlow” deployed in the ExecutionGroup “default” are published to the topic “BROKER_EVENTS_DEFAULT”.
To subscribe to the
This event data includes the payload and transaction data (i.e. what message flow, execution group, timestamp, and other useful transaction information).

1)Setup the Topic and Topic String

Subcription for this topic  will be done as below

 Without even enabling the monitoring in the toolkit and the need to redeploy the flow,we can enable
mqsichangeflowmonitoring BRK1 -e default -f MonitoringEvents_MF -s 
"QIN.transaction.start,QIN.transaction.end,QIN.transaction.rollback" -i enable
Activating Monitoring on the broker as ,
mqsichangeflowmonitoring RadBroker1 -c active -e default  –f MonitoringFlow 

To check the status of the monitoring,
mqsireportflowmonitoring RadBroker1 -e default -f MonitoringFlow  -a

Enabling statistics:
mqsichangeflowstats RadBroker1  -s -e default -f MonitoringFlow -c active -o xml

$SYS/Broker/RadBroker1/StatisticsAccounting/SnapShot/default/MonitoringFlow

Useful Links –  Event Monitoring

Setting up Event Monitoring in Message Broker version 8

No comments:

Post a Comment