ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General Discussion » How do/would you get a channel audit log?

Post new topic  Reply to topic Goto page Previous  1, 2, 3
 How do/would you get a channel audit log? « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Wed Aug 08, 2018 7:34 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Exits and/or tools that consume and make sense of the App Activity Trace messages are a powerful way to prove what actually happened and when.

You think every single last change to every single system goes thru change control. And even if yes, when something goes wrong you can look thru the 100s if not thousands of change tickets and spot the culprit. And the technical detail in these change tickets is high quality. Uh-huh.

When App A sends a request to App B, and the reply message is sitting on the reply queue but App A says they got a 2033, how easy is that to answer? There is mainframe involved, DataPower maybe, lets throw in some JBoss and don't forget MQ Clustering. All these teams are on the call, with some network people for good measure. Go ahead and ask App B any question you want. Do you have any confidence in any answer they give you? I don't. They won't self incriminate, they will never have the onions to say "I don't know" and if you ask "Do you see anything in your logs" and expect anything other than a default "No" I want to work where you do.

Or, you can have a tool that shows the message left App A at 12:00:01.001, made it thru DataPower by 12:00:01.110, was picked up by App B at 12:00:01.132, and the reply message was put 13.234 seconds later. App B we don't need you to answer any more of our questions, we have proof you chewed on that request for 13.234 seconds. App A, MQ was not slow, when App B finally spit it out, it only took another 0.188 seconds to go thru MQ and DataPower to hit your reply queue, but your Get With Wait had ended a few seconds prior to that. By the way, I'm opening a problem ticket for you because I see you are not using syncpoint on that MQGET. Tsk, tsk.

Drop the mic, walk away, done.

What's the alternative? You don't have a tool that tracks transactions and we all sit on this call and everyone shrugs and everyone says they have no logs or nothing abnormal in their logs. And since the only "error" is MQ RC 2033, must be an MQ problem.

Wanna really spice it up? Have a Get With Wait of say 10 seconds, send 3 transactions one after another.
The first one takes .25 seconds, reply comes back in time.
The next one takes 9.9 seconds, reply comes back in time.
The 3rd one take .25 seconds, but doesn't come back in time because it waited on the req queue for 9.9 seconds for trans #2 to finish.

Trans #3 times out, and App B's logs if they have them show Trans #3 only took 0.25 seconds. No problem here, must be MQ. Eventually, maybe, App B will look at Trans #2.
Or you can look at your MQ transaction data yourself and move on with life.


"We code an expiry of 1000 seconds! I don't have to show you my code. MQ is losing my messages." Ah, no, looking at our exit data, you are coding 1 second for expiry. Oh, and you are JMS. Yes, yes you are, I can see it in MY logs. So go read up on TimeToLive and your "1000" seconds.

Are you doing a Get With Syncpoint like our standards say? "Yes....What's Syncpoint?" Nevermind, I'll look at my logs and tell you what your app is doing for syncpoint, not what you think you are doing, not what you think what I want to hear, not what some design spec from 5 years said you should have coded, not some source code you might show me with no proof that is what is actually executing on the floor.

"MQ lost my message."
Do you have an errors? "No"
What was your MQRC? "What's that?"
Never mind, my logs show you got a MQRC 2087 on the MQOPEN call, the put never worked, MQ didn't lose the message because it never got to MQ. And by the way, here is exactly why your app code failed.

I agree with Jeff.VT, the push back seems odd to me on this thread. With the scourge of outsourcing and never ending KT and a revolving door of support staff, knowledge of what the apps actually do is weak. Where, if or how they log is a mystery to them. At least once a year I have to convince an app support team that they use MQ! And I'm supposed to rely on them during trouble shooting? Forget it - a proper and robust MQ API transaction tracing tool to capture that data and make sense of it will pay for itself 10x over.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
exerk
PostPosted: Wed Aug 08, 2018 11:11 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

I agree with everything you say above, especially in regard to having a tool that shows calls and transactions-with-timings, something the N'tel product does wonderfully - it certainly allowed me to show that time in MQ was so negligible and waiting on database was the sloooooow bit, and that non-sync-point calls were being used.

Unfortunately though, most sites want to use the clunky enterprise framework product of their choice, which doesn't ever seem to work to the level of detail we admins would like (or work at all for that matter), or, they want some home-grown solution that becomes ever more difficult to maintain (loss of skills etc. as people move on), or does work but Ivory Tower management wants it gone because it doesn't fit within a product catalogue and they want to consolidate to...(see the beginning of this paragraph.

I'm not so sure it's push-back against Jeff.VT, more that it's bitter experience talking.

Hopefully we'll all get to work in a nirvana installation one day, and questions like this will be moot. In the meantime, I shall continue to take my dried frog pills!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Thu Aug 09, 2018 7:33 am    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 68

gbaddeley wrote:
We sometimes need to deal with retrying channels


I'd guess it's just the nature of my 3rd parties, but I have to deal with this daily.

Some 3rd parties just turn off their test queue managers when nobody is actively scheduled to be testing.

Others have maintenance regularly.

I have some that in order to make any change to their routing must stop their channels - so it happens several times a day.

I have some (typically governments if I'm being honest) that have atrocious uptime and yet will still blame us for not receiving data.

So our industries are probably quite different.

------

But overall, I think my main issue is that App B isn't my company so once it leaves that channel, it's a huge black box until I get a response... And sometimes that black box goes to up to 5 other different companies before it hits its destination - all of us must be in sync.

The instances where I have control over the source and the destination apps are few and far between - and I agree - I don't need any logs in between to understand what's happening.

I mean my inbound is just as chaotic. Without some sort of channel exit logging I pretty much have no knowledge of which one of my hundreds of 3rd parties originally sent me this message. It's my fault, for simplicity my inbound routing is one big queue - but it also keeps my inbound logs very concise.

Anyway - I'm digressing.

Thanks for the conversation everyone. I think I found a minute to play with Roger's deal.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page Previous  1, 2, 3 Page 3 of 3

MQSeries.net Forum Index » General Discussion » How do/would you get a channel audit log?
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.