| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to implement Tracing logs in WMB without TNode |
View previous topic :: View next topic |
| Author |
Message
|
| Mitran |
 Posted: Fri Sep 19, 2014 12:15 am Post subject: How to implement Tracing logs in WMB without TNode |
 |
|
Newbie
Joined: 19 Sep 2014
Posts: 1
|
Hello,
I am new here and pretty noobish with the message broker. I read as much topics, as I could find here, about tracing and logging within the MB and could not reach a conclusion what technology to use. Currently we use, the build in trace nodes, and they provide some extras – like different log files per flow for example, and the ease to collect the log output using ESQL ($Root, $Enviroment…).
Requirements:
1. Trace logs for different levels – to be able to set a global parameter for the broker to stop logging on specified levels – for example I. Severe
II. Error III. Warning IV. Information V. Route info (for example if we need ony up to 2 we set that and rest logs are not working)
2. Rotate policy – for size or day of the week/month - to close the current file(s) and create a new one(s)
I guess the policy requirement could be worked around for our existing trace nodes - with java compute node(JCN) embedded in some regularly running flow where the JCN code checks and creates new files.
I read here that using java.util.logging is the fastest way to incorporate my requirements and have rolling files using FileHandler. I made a testing Java Compute Node(JCN) and a singleton for the Logger, got the logger instance and i could use it in a JCN to log warnings, info msg, could also use a global parameter to avoid logging over certain severity level. I could set global parameters for the MB accessible from java code.
So far so good but I am unable to pass any parameter to the JCN when I create it in the visual interface (need to customize the msg output with those params and write only one java class for the JCN log node) . Tried few things, even tried to find how to get the short and long description of a JCN but I had no luck so far. Also java.util.logging did not separate logs per flow and that’s kind of detrimental to the way logs were created by the trace nodes, readability suffers.
So could someone help me with the choice for logging trace mechanics for a MB that could be turned on/off on different levels, have rolling policy mechanics and could replace relatively easy the Trace nodes ? 
PS: We had an idea if we could embed some ESQL code in the trace nodes “Pattern” field and exclude the logging in case we get some global parameter for the MB. But the pattern field did not parse the ESQL at all  |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Sep 19, 2014 5:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The actual technology that's built into the product for giving you all the information you need, with a small caveat, about what your flow is doing is Monitoring Events.
Even within a node, you can emit monitoring events whenever you want using Propagate. Then you can write any flow you want that subscribes to the monitoring events and stores them in a file or more than one file or a database or or or or...
In terms of the rest of your question, there are two basic ways to pass data into a JavaCompute node: Using information populated by the flow before hand in one of the logical message trees (Environment, LocalEnvironment, etc. etc. etc.), or by using User Defined Properties (which live on the message flow).
If you want to access things like the description field of the Java Compute node, you have to use the Broker Administrative API, and that can get compllicated.
If you want to make a general purpose "log" node that has configurable properties, create a subflow. Add a bunch of user defined properties the subflow, and then wire an Input node to your JavaCompute and then to an Output node.
Then every time you drop the subflow onto your flow, you can set different properties to use at runtime. |
|
| Back to top |
|
|
| vicentius |
| Posted: Fri Sep 19, 2014 6:05 am Post subject: |
|
|
Apprentice
Joined: 01 Mar 2013
Posts: 28
|
Take a look at IAM3 SupportPac, which introduces log4j functionality, albeit with a few limitations.
One thing to consider about logging inside the flow from JCN: if you code a synchronous IO write operation inside the flow, performance might be impacted. Depending on the design of the flow and on the performance requirements, this might or might not be an issue. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri Sep 19, 2014 6:45 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi Mitran,
you should read about the "Record and replay" feature and monitoring
the link bellow is a good starting point if you are using version 8
http://www-01.ibm.com/support/knowledgecenter/SSKM8N_8.0.0/com.ibm.etools.mft.doc/bc37851_.htm
In a glance this is how it works:
1) When you build a message flow you can define monitoring properties to react to events (here we have a rule: every soap input node has a monitoring defined in the event "begin transaction" and every soap.reply node as monitoring defined in the "terminal in" event). You should define an enterprise rule/best practice so that all message flows deployed react to pre-defined events
2) This event/monitoring info is put in a queue (publish)
3) The queue has a capture store, that subscribe the events published and write the info to a database
4) now you can search the table using SQL Tool to search for problems. You can use the web admin console to display this info.
hope it can help
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
