| Author |
Message
|
| Partha.Baidya |
 Posted: Tue Feb 23, 2016 6:20 pm Post subject: |
 |
|
Voyager
Joined: 05 Nov 2009
Posts: 97
|
| Partha.Baidya wrote: |
| Do you we have any other option to create a custom logging framework? |
Aside from studding your code with log4j calls or intercepting event messages? Not really.[/quote]
If I compare between Log4j and intercepting event messages, which one would be better solution?
Can you give some thoughts and best practices about these? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Feb 23, 2016 11:38 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There is another solution that works using a DB but can add value to the whole subsystem.
We have a logging framework that allows the flow developer to set values specfic columns in the Audit DB. for example a Product Batch Number and a Machine ID. Then you can search the audit DB using these keys for specific sets of data.
Naturally, we include all the vital things like input and output messages in the logs but also header information. This is very useful for the HTTP nodes where there is no payload as such but the commands are part of the HTTP string. We link the inputs and outputs using the Message ID's.
The logging is handed off to other flows to update the logs via MQ (outputs not transactional). There are template frontends (subflows) for several different Nodes types including MQ, SOAP, HTTP, JMS and TCPIP.
We can even throw errors with error codes and text from indies a flow that end up once again in a third table which again provided us with a reason for why the throw too place. For example, we get a lot of data from external suppliers that is Valid from a schema and value point of view but the data itself does not match up with our system. We can log the error to a table. The operators have a view of this so that they can see the reasons in plain language for a failure.
Makes support a lot easier. There are far too many logging and audit systems that hold huge amounts of data but no one used them because finding anything is like a needled in a haystack.
If you are going to invest in a logging/audit subsystem it might be worth looking at the support Point Of View and incorporating those requirements into the solution.
Just my worthless (£0.02p) thoughs on the issue which can be ignored and probably will. 
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 24, 2016 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Partha.Baidya wrote: |
| Can you give some thoughts and best practices about these? |
If you use log4j, you're reliant on all developers adding the calls, and the calls being in the places you need them to be. Changing this requires a code redeploy.
If you use event messages, you are not reliant on anything code based and have administrative control over message production.
That's why commercial products (which you're attempting to reinvent) use event messages or other administrative hooks into the software.
(I would not recommend you attempt some of the other hooking strategies I've seen in commercial BAM software. They're advanced, ingenious and not for the beginner. That's why you pay the money - for clever people to do clever things and offer support when it all goes to heck).
Have fun with your wheel. I recommend the axle somewhere towards the middle..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| timber |
| Posted: Wed Feb 24, 2016 7:32 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
IIB has it s own logging capabilities like writing logs to Operating System event logs/syslog where the error or exception messages get logged. Even we can use trace logs to some files.
But this level of logging details does not give a end to end view of what is going on with a message coming to IIB. We can not use this logs to monitor SLAs and performance of the message flow. It can not be used to create a Dashboard of system monitoring. |
True. Nobody in their right mind would attempt to montor their business using syslog or user trace. BUT have you read this topic in the Knowledge Center?
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/ac37860_.htm?lang=en
This is what mqjeff, vitor and ruimadaleno are talking about. IIB does provide the business-level 'logging' that you need. It calls it 'monitoring'. And many customers are using it very successfully. |
|
| Back to top |
|
|
| Partha.Baidya |
| Posted: Wed Feb 24, 2016 10:32 am Post subject: |
|
|
Voyager
Joined: 05 Nov 2009
Posts: 97
|
Thanks to mqjeff, vitor, smdavies99, timber and ruimadaleno for your thoughts and sharing.
This is what I was thinking.
We can use IIB provided event emitting feature and log those events to a Database with some identifier for each messages processed. This is will be used for auditing and problem determination of the message flows.
In log4j we can achieve the same by java coding.
But events are more flexible because of
1. java adds extra processing loads along with processing of functionality.
2. events are generated separately and does not block the processing of functionality.
3. events are configurable and does not require a code deployment if we want to change the configuration or disable it
4. java code are embedded with message flow coding which requires redeployment if we want to change it or disable it.
I was reading somewhere in an article that current recommendation from IBM to use event emitting feature for WMB logging and auditing purpose.
Please let me know if you have seen any such recommendation. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Feb 24, 2016 12:28 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Partha.Baidya wrote: |
Thanks to mqjeff, vitor, smdavies99, timber and ruimadaleno for your thoughts and sharing.
This is what I was thinking.
We can use IIB provided event emitting feature and log those events to a Database with some identifier for each messages processed. This is will be used for auditing and problem determination of the message flows.
In log4j we can achieve the same by java coding.
But events are more flexible because of
1. java adds extra processing loads along with processing of functionality.
2. events are generated separately and does not block the processing of functionality.
3. events are configurable and does not require a code deployment if we want to change the configuration or disable it
4. java code are embedded with message flow coding which requires redeployment if we want to change it or disable it.
I was reading somewhere in an article that current recommendation from IBM to use event emitting feature for WMB logging and auditing purpose.
Please let me know if you have seen any such recommendation. |
If you are a Java shop then it might make sense.
The other solutions mentioned are applicable to ALL supported Broker languages.
With mine I don't have to faff around with Jars. {Personally, I think that Java is about the worst programming language ever concieved and I've developed in Coral and Ada}
With respect to your Item 3) above. My framework has the facility to change behaviour of a flow just by updating a DB Table and a flow restart. No redeploy needed.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Partha.Baidya |
| Posted: Wed Feb 24, 2016 12:51 pm Post subject: |
|
|
Voyager
Joined: 05 Nov 2009
Posts: 97
|
To smdavies99
Can you please let me know how did you build your framework?
I am not asking the details but what technology you have used like Java or some custom ESQL code etc? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Feb 25, 2016 12:18 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
My framework is all ESQL. no Java in sight.
You import a template sublow of the right type into your project. Edit the input node properties to fit your requirements (queue Name, Http etc). Then you build your flow as normal.
All the input logging is taken care of as well as standard error handling.
Bedore deploying, you add a row that configures your flow to a table. This row is read when the flow starts and then again every 24 hours. Changes can be mande to the data in the row and implemented with just a simple flow restart.
There is an optional Audit Subflow that you can stick at the end of the operation. By setting some values in the Environment tree in your fflow you can identifiy things about the detail of the message being processed. These are used when the audit record is added to the Audit DB Table.
It is this ability that swung us to use this over using the IIB monitoring facility. There is very little overhead to the developer when building the flow/application.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
