This is a question that we get asked quite regularly, so we thought it worth writing up the answer as a blog post.
If you’re asking this question, there are two reasons that immediately come to mind that might be behind your question:-
- You just want some sort of documentary log, a history of what you have done to look back on.
- You need a log of commands issued for audit reasons.
However, applications logging their own activity have a number of disadvantages. For example, if the log file were on your own machine, then you have to manage those files, house-keep them as they get old enough to delete, etc. Flat log files are not very easy to search through, say to find out what happened last weekend, or all the activity associated with a particular object.
If you want something for audit reasons, using a log file on the user machine has a number of additional problems:-
- Firstly, it is not audit proof because
- It is easy to circumvent
- It is incomplete since other tools might be used to issue commands to the queue manager
- The user could switch off the logging feature in their tool, or install a new version of it to avoid the logging configuration
- Secondly, it is hard to collect the logs from all the different users’ machines to have the complete picture.
- Thirdly, if individual applications are creating the log file, e.g MO71, runmqsc, MQ Explorer and so on, then you get a myriad of different log file formats.
To solve all of the above, IBM MQ Queue Managers have a feature called Command Events. When enabled these result in an event message being emitted by the queue manager for any command issued (with a tweak to avoid DISPLAY commands if you wish – see EVENT Switches). This is a far better solution than logging in the user-facing tool (e.g. MO71), for reasons such as:-
- Central collection is better because it is easier to obtain a complete record, since the records are not segregated across many user machines
- It cannot be subverted by non-privileged users
- The format is consistent regardless of the tool used by the user
- No updates are required to any tool, the logging capability is available immediately for all applications
If all you want is something to pass an audit, command and configuration events might be enough. But if you want a record for diagnostic purposes there are other things you might wish to add to the record of what happened, such as:-
- Channel problems via Channel events
- Queues High or Full via Performance events
- Queue Service Interval High via Performance events
- Queue Manager Fail-overs via Start/Stop events
We have been recommending using Command (and Configuration) events rather than logging at the user-side MQ administration tool, for many years. Previously the problem with this recommendation was the collection and searching of the event data. However, we have recently released a new product, MQEV, which will help you in this regard. MQEV will collect, process and store your event data, and make searching and report building very simple. You can now easily get the information from the event messages that your IBM MQ queue manager is designed to emit. If required you can process the events real-time, and make changes immediately, or even raise alerts to your MQ administrators for follow-up.
Lumberjack image courtesy of vectorolie at FreeDigitalPhotos.net