| Author |
Message
|
| PeterPotkay |
 Posted: Thu Jul 03, 2014 4:09 am Post subject: MQ Application Activity Trace - How to restrict what it coll |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I’m just starting to play with this App Activity Trace thing and the MS0P Support Pack to read the data produced. I wanted to start small and only capture activity by amqsput or amqsputc. I am getting that, but I continue to pick up activity from other things still talking to the Queue Manager – one of my BMC WMB monitoring agents, and what I’m guessing is MQ Explorer itself based on the evidence, although I’m kinda disappointed the Activity Trace Messages wouldn’t be crystal clear in identifying MQ Explorer by name.
So what am I doing wrong given my mqat.ini file – why am I picking up activity from programs that don’t match the amqsputc* string.
MQ 7.5.0.3 on RHEL 6.4
Below is my mqat.ini file.
| Code: |
#*******************************************************************#
#* Module Name: mqat.ini *#
#* Type : WebSphere MQ queue manager configuration file *#
# Function : Define the configuration of application activity *#
#* trace for a single queue manager. *#
#* *#
#*******************************************************************#
AllActivityTrace: # Global settings stanza
ActivityInterval=0 # Time interval between trace messages
# Values: 0-99999999 (0=off)
# Default: 0
ActivityCount=0 # Number of operations between trace msgs
# Values: 0-99999999 (0=off)
# Default: 0
TraceLevel=MEDIUM # Amount of data traced for each operation
# Values: LOW | MEDIUM | HIGH
# Default: MEDIUM
TraceMessageData=0 # Amount of message data traced
# Values: 0-104857600
# Default: 0
StopOnGetTraceMsg=ON # Stop trace on get of activity trace message
# Values: ON | OFF
# Default: ON
##################################################################
# Prevent the sample activity trace program from generating data #
##################################################################
ApplicationTrace: # Application specific settings stanza
ApplClass=ALL # Application type
# Values: (USER | MCA | ALL)
# Default: USER
ApplName=amqsact* # Application name (may be wildcarded)
# (matched to app name without path)
# Default: *
Trace=OFF # Activity trace switch for application
# Values: ( ON | OFF )
# Default: OFF
ActivityInterval=0 # Time interval between trace messages
# Values: 0-99999999 (0=off)
# Default: 0
ActivityCount=0 # Number of operations between trace msgs
# Values: 0-99999999 (0=off)
# Default: 0
TraceLevel=MEDIUM # Amount of data traced for each operation
# Values: LOW | MEDIUM | HIGH
# Default: MEDIUM
TraceMessageData=0 # Amount of message data traced
# Values: 0-104857600
# Default: 0
##################################################################
# Monitor amqsputc or amqsputc#
##################################################################
ApplicationTrace: # Application specific settings stanza
ApplClass=ALL # Application type
# Values: (USER | MCA | ALL)
# Default: USER
ApplName=amqsput* # Application name (may be wildcarded)
# (matched to app name without path)
# Default: *
Trace=ON # Activity trace switch for application
# Values: ( ON | OFF )
# Default: OFF
ActivityInterval=1 # Time interval between trace messages
# Values: 0-99999999 (0=off)
# Default: 0
ActivityCount=0 # Number of operations between trace msgs
# Values: 0-99999999 (0=off)
# Default: 0
TraceLevel=MEDIUM # Amount of data traced for each operation
# Values: LOW | MEDIUM | HIGH
# Default: MEDIUM
TraceMessageData=10 # Amount of message data traced
# Values: 0-104857600
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Jul 03, 2014 5:12 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5856
Location: UK
|
| Quote: |
You have a number of options for configuring the level of detail in Application Activity Trace output. Configurable options in the mqat.ini file include:
The ability to restrict the applications that the trace runs against. For example, you can specify the application you want to trace by specifying the ApplName in the ApplicationTrace stanza.
|
http://www.ibm.com/developerworks/websphere/library/techarticles/1306_bushby/1306_bushby.html
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 03, 2014 6:49 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I stared at that article last night. It doesn't help. Perhaps I'm dense, but I don't see any examples or instructions in either that article or the Knowledge Center on exactly how one is supposed to restrict what this thing collects to just one app name.
I tried various things in the mqat.ini file and the last attempt is what I show above. My logic was using zeros for everything in AllActivityTrace to not collect anything, then creating a ApplicationTrace stanza to look just for amqsput* stuff. But clearly that's not the right line of thinking.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 03, 2014 7:06 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5856
Location: UK
|
Try having a catch all rule (*) which does not generate a trace, and a more specific rule which does.
The best match will apply.
Otherwise you could Email Emma (our AVP rep as it happens).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 03, 2014 7:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Try having a catch all rule (*) which does not generate a trace, and a more specific rule which does.
The best match will apply |
yeah, I would just modify your mqat.ini file to change "ApplName=amqsact*" to "ApplName=*" and try again. |
|
| Back to top |
|
|
| markt |
| Posted: Thu Jul 03, 2014 8:16 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
And how did you get the config file refreshed in the qmgr? Just editing the ini file doesn't dynamically change what gets logged.
The file is reread only on qmgr restart OR when a qmgr attribute is changed (simplest thing is disable activity trace and then enable it) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jul 03, 2014 8:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Mark, I was stopping and restarting the collection as I was making changes to the mqat.ini file. But maybe more out of coincidence then specifically thinking it was needed to pick up changes in mqat.ini. Thanks for pointing that out.
| mqjeff wrote: |
| zpat wrote: |
Try having a catch all rule (*) which does not generate a trace, and a more specific rule which does.
The best match will apply |
yeah, I would just modify your mqat.ini file to change "ApplName=amqsact*" to "ApplName=*" and try again. |
Thanks jeff, I needed my hand held 
Its working as expected now.
Any tricks on restricting the tracing activity to a specific queue name or MQ channel name? Use Case: I have an MQ Client Concentrator with dozens of DataPower client connections into it. Telling mqat.ini to only look for Datapower* still leaves with me with a lot to parse. Would be nice to further restrict it to a specific queue or client channel so that I can get trace activity only for one DataPower MQ Front Side Handler.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Jul 06, 2014 1:08 pm Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
A few thoughts.
1) You could tweak the amqsact tool to allow you to do this. The manual says they provide the source for amqsact so it could be enhanced by the user for something like this. If you are a C programmer, enhancing it to do what you want should be trivial.
2) You could use the qload program as a makeshift way to do this. For example, you could create a back up queue for the SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE and copy the existing messages on the S.A.T.A.Q to the back up queue using qload. Then you could use qload to destructively read messages from the S.A.T.A.Q that do not match on the channel name or queue name. The channel name and queue name should appear as strings in the S.A.T.A.Q message, so it should be easy to match on them. If you wanted to select on pid, I think you could do that as well, but that might need to be a search in hex (and if the qload supports a hex search, which I think it does). This should leave you with roughly what you want. You could then clear the S.A.T.A.Q and reload it from the back up, if you wanted to do another selective search. It is crude, but it would probably work. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jul 06, 2014 3:31 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Thanks for the ideas, Tim, I'll have to experiment.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 07, 2014 4:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
I have opened a RFE on this topic. Here is the direct link to vote on this RFE if you think it’s a good idea.
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=55753
Headline: MQ Application Activity Trace - Allow MQ administrator to limit tracing by queue name, channel name, Connection ID
Description: The ApplicationTrace stanza in the mqat.ini file currently allows the MQ Admin to restrict Application Activity tracing by application name, by using the ApplName parameter.
This RFE is to add additional parameters to allow the MQ Admin to limit the application activity tracing even further - by queue name, or by MQ Client Channel name, or by Connection ID.
In a highly shared environment with multiple high volume applications sharing the same queue manager, the App Activity Trace is of limited value if those apps all have the same name due to the massive amount of trace data sent to SYSTEM.ADMIN.TRACE.ACTIVITY.QUEUE. By implementing this RFE we could definitely use the powerful App Activity Trace feature more often to solve problems on our own, hopefully reducing the # of PMRs we need to open.
Use case: Our queue managers all support multiple applications. Frequently there are dozens of instances of an application connected to the same queue manager, and restricting the App Activity Trace to an appl name still produces a massive amount of App Activity Trace output. For example, on a WMB Queue Manager, all the message flows are "DataFlowEngine". And on our queue managers where DataPower connects with their Front Side Handlers, there are dozens of "WebSphere Datapower MQClient".
By allowing us to restrict the App Activity Trace to a specific queue name or set of queue name with a wildcard, it would allow us to focus the App Activity Trace on the one App whose Activity we would like to Trace. Other options to focus the trace could be by MQ Client Channel Name and / or by Connection ID.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
