| Author |
Message
|
| brokerguy |
 Posted: Mon Mar 25, 2013 4:58 pm Post subject: WMB v8 Event monitoiring use cases? |
 |
|
Apprentice
Joined: 18 Mar 2013
Posts: 26
Location: Cosmos
|
Plz confirm whether the following use cases are a good fit for WMB v8 event emitting & monitoring capability. I have put my thought process against each one of them.
1. Auditing : Earlier I've custom built an auditing component that recorded the request timestamp, consumer name/id, request msg etc. This was done asynchronously using dedicated audit queue & audit msg processing flow & an Audit DB table. I think with an improved event monitoring capability, we can now leverage it without building custom code to record the audit parameters. Plz confirm
2. Performance Measurement: Used a similar design like the above custom audit component. Only purpose of this perf measurement component is to record the timestamps (request/response from consumer and to providers). Intent is to measure the time taken by a message flow to process a message. Again, I think event monitoring feature can again be leveraged without building any custom code to measure the timestamp.
In general, what are the downsides of using the OOB event monitoring feature?
I can think of one constraint (not really a con): If event monitoring is used both for audit & performance measurement, then I cannot make the perf measurement to be turned on/off(configurable) at a per message flow level as this would permanently switch of auditing for that particular flow. Let me know your views.
Use cases where Event monitoring may not apply:
1. Application Logging: have used custom built logging component using log4j in the past. But, was seeing the 'Activity Log' (http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.msgbroker.helphome.doc%2Fhelp_home_msgbroker.htm). What is the real life usage of Activity log ? |
|
| Back to top |
|
 |
| Esa |
| Posted: Mon Mar 25, 2013 11:58 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
1. I agree. You're on the right track.
2. Sounds OK
Maybe you could use the same events for auditing and performance monitoring? It's basicly just about event correlation.
The correct link to Activity logs |
|
| Back to top |
|
|
| McueMart |
| Posted: Tue Mar 26, 2013 1:37 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
For performance measuring check out the Message Flow statistics. This wont give you 'message level performance numbers' like you could achieve with with monitoring events - but you get a whole slew of good information from them at the Node and Message Flow level.
Also they can be turned on/off independent of the monitoring events! |
|
| Back to top |
|
|
| goffinf |
| Posted: Tue Mar 26, 2013 3:43 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| McueMart wrote: |
Also they can be turned on/off independent of the monitoring events!
|
As indeed can monitoring events (independently of flow stats) |
|
| Back to top |
|
|
| brokerguy |
| Posted: Tue Mar 26, 2013 3:18 pm Post subject: |
|
|
Apprentice
Joined: 18 Mar 2013
Posts: 26
Location: Cosmos
|
| Esa wrote: |
Maybe you could use the same events for auditing and performance monitoring? It's basicly just about event correlation.
|
Intention is to use same events, however, how can I selectively turn off performance monitoring. That is, given the fact that the flow monitoring is enabled at a per flow level, how can I ensure that Auditing is ON but Performance monitoring is switched OFF. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Mar 26, 2013 3:36 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| brokerguy |
| Posted: Tue Mar 26, 2013 5:04 pm Post subject: |
|
|
Apprentice
Joined: 18 Mar 2013
Posts: 26
Location: Cosmos
|
Thanks! I will try this option. Appears like I may have to configure two(2) events at a per node level to fulfill the Audit & Perf measurement functionality & to keep them configurable (on/off).
Btw, have you experienced or foresee any impacts to the flows from performance & resource utilization (mem, cpu..) perspective. Alternate solution is to capture the audit parameters using ESQL and put the audit msg to a queue(this latter part would be same as in event monitoring). |
|
| Back to top |
|
|
| brokerguy |
| Posted: Tue Mar 26, 2013 5:22 pm Post subject: |
|
|
Apprentice
Joined: 18 Mar 2013
Posts: 26
Location: Cosmos
|
Thanks! I will try this option. Appears like I may have to configure two(2) events at a per node level to fulfill the Audit & Perf measurement functionality & to keep them configurable (on/off).
Btw, have you experienced or foresee any impacts to the flows from performance & resource utilization (mem, cpu..) perspective. Alternate solution is to capture the audit parameters using ESQL and put the audit msg to a queue(this latter part would be same as in event monitoring). |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Mar 26, 2013 11:40 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| brokerguy wrote: |
| Esa wrote: |
Maybe you could use the same events for auditing and performance monitoring? It's basicly just about event correlation.
|
Intention is to use same events, however, how can I selectively turn off performance monitoring. That is, given the fact that the flow monitoring is enabled at a per flow level, how can I ensure that Auditing is ON but Performance monitoring is switched OFF. |
By removing the subscription. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Mar 27, 2013 1:25 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| have you experienced or foresee any impacts to the flows from performance & resource utilization (mem, cpu..) perspective. Alternate solution is to capture the audit parameters using ESQL and put the audit msg to a queue(this latter part would be same as in event monitoring). |
Whenever you emit a monitoring message you are doing extra work. This will use more CPU, and more I/O. The impact on the responsiveness and/or throughput of your flow will depend on many factors, including the 'Transaction' settings on the monitoring properties of the flow.
Implementing your own solution in ESQL will not change that - the impact will probably be the same or greater.
In this case, your best bet is to write a few test flows and try them out. Then you will have hard evidence that applies to your own technical environment. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 27, 2013 2:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also you want to stick to statistics for performance. You may want to use support pack IS03 for that. Don't use the events for performance. If you have a flow at 10 TPS with 10 nodes you get 210 TPS with 2 events per node!
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Mar 27, 2013 4:08 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| fjb_saper wrote: |
Also you want to stick to statistics for performance. You may want to use support pack IS03 for that. Don't use the events for performance. If you have a flow at 10 TPS with 10 nodes you get 210 TPS with 2 events per node!
|
You cannot calculate the number of events like that. That's more like the worst case scenario. The number of events emittetted depends entirely on the monitoring profile applied and it can be very small.
The OP never mentioned the word statistics. He wants to measure response times in multiple flow scenarions like request/response and be able to distinguish between the time elapsed during the flow execution vs. an external service call. Imho you cannot achieve that with mere Message Broker statistics. |
|
| Back to top |
|
|
| sridhsri |
| Posted: Wed Mar 27, 2013 4:59 am Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
Audit requirements can vary quite a bit (and some are driven by law). Audit usually means:
1. The audit process must be part of the same transaction as the message flow. A failure to publish an audit event must cause the flow also to fail.
2. The audit message must be digitally signed (to prove the message came from Broker and not someone else) or even encrypt the message.
I don't think these requirements can be met through Broker's record and reply feature.
Finally, you cannot in all cases reliably capture the consumer's identity (HTTP, without the use of SAML). |
|
| Back to top |
|
|
| McueMart |
| Posted: Wed Mar 27, 2013 5:09 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| Imho you cannot achieve that with mere Message Broker statistics. |
The OP didn't mention that they were doing request/reply within multi-flow scenarios (which I agree Message Flow Statistics wont help you with). If they are doing request-reply within a flow - statistics are great to see elapsed times! |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Mar 27, 2013 5:59 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| McueMart wrote: |
| Quote: |
| Imho you cannot achieve that with mere Message Broker statistics. |
The OP didn't mention that they were doing request/reply within multi-flow scenarios (which I agree Message Flow Statistics wont help you with). If they are doing request-reply within a flow - statistics are great to see elapsed times! |
You are right. I think I was thinking too much about my own scenarios. Although the OP does not say if the request/reply is implemented sycnhronously or not.
The OP is also unclear about if he wants to track performace statistics or the performance of individual requests.
@sridhsri: are you perhaps confusing request/reply with record and replay?
But I agree with what you say about audit messages.
Maybe there is a better name than audit log for not-so-security-relevant tracking of chronological sequences of activities? |
|
| Back to top |
|
|
|
|
