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  Next
 How do/would you get a channel audit log? « View previous topic :: View next topic » 
Author Message
Jeff.VT
PostPosted: Fri Aug 03, 2018 10:55 am    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 68

Vitor wrote:
Jeff.VT wrote:
PeterPotkay... Because I think if I laughed in their face, I'd get fired.


In fairness, I think @PeterPotkay is more in your camp on this; I was the one who suggested laughing (and I've never been fired for it - maybe I'm just lucky).

I understand the topology you're describing but I stand by my advice; find out how the network people monitor traffic (and they must by definition be monitoring the same traffic you are) and how they're solving for this.


The networking team doesn't have to answer the same questions that I do. I don't see how that is an analogous situation. I'm sending encrypted data down an MQ channel.

And I HAVE the tool... it does 100% of what I need. it just doesn't work for the most recent version.

It seems very straightforward. Here's a channel... give me a log of what was sent down this channel. I'll save it for an amount of time so I can prove to my customer so they can prove to whoever is trying to fine them for not sending the data 3 months from now.

It can't be outside of the MQ because the connection is encrypted. So it has to be something running on the queue manager.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Aug 03, 2018 11:24 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Jeff.VT wrote:
The networking team doesn't have to answer the same questions that I do. I don't see how that is an analogous situation. I'm sending encrypted data down an MQ channel.


They still have to answer for when DNS routing goes wrong, connection links break, packets get scrambled or dropped. So they must be monitoring all the of endpoints and routes that you're using.

Granted you have the additional issue of payload, but their framework will be a start.

Jeff.VT wrote:
And I HAVE the tool... it does 100% of what I need. it just doesn't work for the most recent version.


Which indicates the size of the customer base it has.

Jeff.VT wrote:
It seems very straightforward. Here's a channel... give me a log of what was sent down this channel. I'll save it for an amount of time so I can prove to my customer so they can prove to whoever is trying to fine them for not sending the data 3 months from now.

It can't be outside of the MQ because the connection is encrypted. So it has to be something running on the queue manager.


So develop your own exit and go in peace with it. You're right to be worried and I stand by all the objects (both in terms of technology and security) that I outlined originally, but if you think that the benefits you gain outweigh the risks then that's your decision to make and I hope it goes well for you. That fact that I wouldn't do it (and would risk my career in a bout of laughter rather than try it) doesn't have any bearing on your choices or situation.

<plug_reference>Or pay Roger for his product</plug_reference>
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Fri Aug 03, 2018 11:29 am    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 68

Vitor wrote:
<plug_reference>Or pay Roger for his product</plug_reference>


Ya, I'm asking for a trial to see what it's all about. If it does what I want, it should be great.

As for me developing my own... It's frowned on me to develop programs. And my developer has been trying for far far far too long to make a suitable channel exit. It already blew up my queue manager when I was trying to test it.

They don't seem to do IBM MQ development very often. So at this point, I'd rather pay an expert so I don't have any more unexpected failures.

Anyway, thanks for the discussion.
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Aug 03, 2018 11:47 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Jeff.VT wrote:
And my developer has been trying for far far far too long to make a suitable channel exit. It already blew up my queue manager when I was trying to test it.


Exits do that.

Jeff.VT wrote:
They don't seem to do IBM MQ development very often.


Even if they did, I doubt they develop many exits. I've been doing MQ development (on and off) since 1998 and I've written 2 exits in that time, compared to I-shudder-to-think-how-much MQ aware .NET/C/C++/COBOL. Even developing them routinely doesn't protect you from the unforgiving environment in which they run and how the slightest issue craters your queue manager in a new and unexpected way.

(Yes @mqjeff, no Java. And the exits were short, simple and as quickly retired as I could manage.)

Jeff.VT wrote:
So at this point, I'd rather pay an expert so I don't have any more unexpected failures.


That's Roger.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Sun Aug 05, 2018 4:40 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Jeff.VT wrote:
So unless you have a solution that would let me tell my customer when a message left my environment for good

The customers own the business data and it has a value to them. MQ is merely reliable transport. If MQ has not delayed or failed the delivery (qmgr down, n/w link down, chls retrying, msgs expired, gone to dead letter queue etc etc), you should be able to assume that messages have passed through MQ successfully. If the customers *really* value their data, they will have their own logging and reconciliation so that they can prove to each other that data has been processed, and can be recovered / replayed in necessary. MQ is very reliable, but it is at the mercy of other resource constraints, particularly network, disk and application behaviour.
_________________
Glenn
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Mon Aug 06, 2018 8:13 am    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 68

gbaddeley wrote:
Jeff.VT wrote:
So unless you have a solution that would let me tell my customer when a message left my environment for good

The customers own the business data and it has a value to them. MQ is merely reliable transport. If MQ has not delayed or failed the delivery (qmgr down, n/w link down, chls retrying, msgs expired, gone to dead letter queue etc etc), you should be able to assume that messages have passed through MQ successfully.


My particular environment has a lot of moving parts.

Routing is changed, errors happen, connections drop, and it's a worldwide system so connectivity between things inside my own network may drop occasionally.

And if I tell my customer that their message was sent at 10pm (according to my application logs), but the connection to that particular 3rd party is down from 9pm to 4am on that particular day due to some random 3rd party outage... Well, then I'm lying to my customer.

As I mentioned elsewhere, some of my messages are only somewhat important. But some are immediate responses. And some I don't get a response.

Let's put it like this.

If you want your baggage to be at the airport when your flight lands, maybe you care about my data and if it gets to its destination in a timely manner as much as my customers do.

--------

To be honest, I think I'm getting a little flustered at so many people denying the premise of my question itself.

Can we just stipulate that my requirements and needs are valid, and I'm just looking for help in sussing out a solution?
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Aug 06, 2018 11:52 am    Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

Jeff.VT wrote:
Can we just stipulate that my requirements and needs are valid, and I'm just looking for help in sussing out a solution?


No, I can't and I would not attempt what you're attempting.

(Sorry Roger)

Having said that, I stand by my earlier comments regarding Roger. Home grown exits are as easy to write and as safe to use as a home grown nitro booster for your car, but an exit is probably your only solution.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Mon Aug 06, 2018 3:35 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Jeff.VT wrote:
Can we just stipulate that my requirements and needs are valid, and I'm just looking for help in sussing out a solution?

OK, the requirements are valid, but I suggest ownership and responsibility of delivering service should be at a management level, not MQ admin level.

When many 3rd parties are involved, the reliability of interconnections is not guaranteed. They can take an outage at any time and the other parties have no control over that. A suitable expectation needs to be set that everyone understands and is tolerant of delays or extended outages.

If there are tight time constraints and high value ephemeral data, then $$$ needs to be invested to design, build and operate a suitable infrastructure.
_________________
Glenn
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Aug 06, 2018 4:14 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Jeff.VT wrote:

To be honest, I think I'm getting a little flustered at so many people denying the premise of my question itself.

Can we just stipulate that my requirements and needs are valid, and I'm just looking for help in sussing out a solution?

I'm with you on this one. Philosophically, MQ is innocent till proven guilty. Realistically (at least for the jungle I toil in) MQ is guilty till proven innocent. So just give me a tool to prove its not MQ and lets all move on to more pressing matters.

Check out the Capitalware product in this space.
Check out the N a s t e l product in this space. The most comprehensive that I am aware of, but you pay for it.
MQGem has something lightweight, but like Capitalware, no native support to jam the reams of data into a monster database with a pretty front end to make sense of it all and correlate the data across mutiple QMs.
BMC's attempt was a miss, in my opinion.
Do share any other options you come across.

Years ago we had Transaction Vision (TV) from Bristol Technologies, eventually being owned and then disowned by HP. I learned a lot about MQ looking at what TV captured and made sense of. It was a great tool.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Jeff.VT
PostPosted: Wed Aug 08, 2018 10:23 am    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 68

Vitor wrote:
Jeff.VT wrote:
Can we just stipulate that my requirements and needs are valid, and I'm just looking for help in sussing out a solution?


No, I can't and I would not attempt what you're attempting.


I guess I'm curious - maybe it's because this is the first place I've ever had to use IBM MQ.

Do you connect to 3rd parties via MQ?

Do you have a team people around the world who can and do make mistakes?

Or are your environments set up such that it's a single flow or message type?

Because those are the only situations I could envision NOT needing something like this. The one way your networking team analogy is appropriate is that we both deal with a spiderweb of connectivity.

I mean... Let's say you have two connections.

Con 1
Con 2

Remote queues going to a third party.

And some new employee was messing around with IBM MQ and accidentally adjusted Con 1 definition so it was essentially a copy of Con 2 (or even you do it by accident so I don't get the whole "just secure your administration" argument). So now everything meant to go to Con 1 was now going to Con 2.

How would you know? How long would it take you to figure that out? What if it's a somewhat rarely used system? What if those messages are only important a week from now, and so the 3rd party and customer wouldn't tell you for a week?

How would you know:

A) When it started
and
B) All of the messages that were sent incorrectly?

All of the application logging would show it going happily to the correct queue.

What if you can't send duplicates or a government sends you a bill?

-----------------

I can literally think of dozens of situations where I would need and want this data. I'm shocked that you guys can't.
Back to top
View user's profile Send private message
exerk
PostPosted: Wed Aug 08, 2018 1:02 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Jeff.VT wrote:
...I can literally think of dozens of situations where I would need and want this data. I'm shocked that you guys can't.

We can see it, but if we seem cynical I can assure you that it's not - cynicism is often confused with hard won and bitter experience.

<example>

At one site I worked at 'someone' signed up to an SLA of zero message loss. The only way to prove to the customer that it wasn't MQ at fault (they couldn't/wouldn't tell me if their apps were doing stuff in sync-point, and they wouldn't allow tracing) was to strap in a very expensive transaction monitoring suite, such that we could prove that if a message went South, it was because an app had died after doing a non sync-point destructive GET.

I have also been on a site where the connection to a Third-Party seemingly was down a dial-up modem (I'm sure it wasn't, but it sure seemed like it!), and then there were complaints that message transmission SLAs were not being met - complaints by the TP, but they were the ones specifying the 'choke' on the bandwidth.

</example>

The road you're going down is one littered with the wrecks of 'solutions' to a 'problem', when really the 'problem' starts at the application - my default position with apps people is simple: "Prove to me that MQ accepted your message, i.e. show me the application logs that state for a given message you say was PUT, show me the zero return codes from MQ".

In Production there should be no 'accidents' if the proper controls are in place, or the controls should be such that if an 'accident' does occur, then the effect of it should be enough to trigger an eye-catcher alert.

Finally, I am assuming that if you want to do this with an exit (home-grown or otherwise) that you are going to have an instance of that exit on every SDR channel within your estate, so you can 'monitor' and correlate?
_________________
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: Wed Aug 08, 2018 1:39 pm    Post subject: Reply with quote

Acolyte

Joined: 02 Mar 2017
Posts: 68

I think my numbers are just too large to not expect an accident or two. Not really in volume, volume is easy. But in diversity.

I have ~10 million messages per day routed via ~15,000 values with specific routing to ~500 endpoints for ~100 clients, and a team of 20 employees.

My problem isn't applications - I have very robust error reporting on my applications. It's not knowing whether or not a connection is failing - I made a decent SCOM management pack for IBM MQ (scom isn't my first choice either).

My problem is that at any point, one of my customers might come to me and say,

"Government XYZ is telling me they didn't receive message 890128541 at 08:30:02.001 UTC on Feb 3rd. And they're telling me if we didn't send it, they're going to fine us $100,000. And if you can't prove to me that you did send it, we're going to pass that fine to you."

I'm sorry, an application log when there's 5 hops between the application and the government's queue manager, every one of which could have been mis-configured even for a split second, just don't appease lawyers as much as you guys want it to.

And since Queue Managers are inherently... Queuing... we could have had a timestamp in the application of it being sent at 8:30:02.001 but there just so happened to be a network hiccup or somebody ran a huge batch job or something, and the message queued a bit. So it was really had a final channel timestamp of 8:31:00:041, and that's why the Government can't find that particular needle in its stack of needles.

A channel exit log is a silver bullet. I know beyond a shadow of a doubt this message left my custody and was delivered to your custody at 8:31:00:041 - so much so I can prove it in a courtroom if I need to.

All of this is moot - tbh, if I'd spent as much time fiddling around with Roger's app as I have complaining to you guys, I'd know if it was resolved or not... But damnit I love complaining.
Back to top
View user's profile Send private message
exerk
PostPosted: Wed Aug 08, 2018 1:49 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Jeff.VT wrote:
I think my numbers are just too large to not expect an accident or two. Not really in volume, volume is easy. But in diversity.

I have ~10 million messages per day routed via ~15,000 values with specific routing to ~500 endpoints for ~100 clients, and a team of 20 employees...

I'm going to play 'how much higher up the wall can I get it than you can?" here - is that all?

Jeff.VT wrote:
...A channel exit log is a silver bullet. I know beyond a shadow of a doubt this message left my custody and was delivered to your custody at 8:31:00:041 - so much so I can prove it in a courtroom if I need to...

Erm, no. It proves it left your estate and went somewhere into the ether, because you have no way of knowing what's between you and the TP - there could be intermediaries between them and you.

Jeff.VT wrote:
...All of this is moot - tbh, if I'd spent as much time fiddling around with Roger's app as I have complaining to you guys, I'd know if it was resolved or not... But damnit I love complaining.

These fora thrive on debate - it gets the creative juices flowing!
_________________
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
mvic
PostPosted: Wed Aug 08, 2018 2:05 pm    Post subject: Reply with quote

Jedi

Joined: 09 Mar 2004
Posts: 2080

exerk wrote:
Erm, no. It proves it left your estate and went somewhere into the ether, because you have no way of knowing what's between you and the TP - there could be intermediaries between them and you.

Certificate chain validation and TLS are the industry standard way of reducing this risk to virtually zero.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Wed Aug 08, 2018 5:23 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Hi Jeff,
Jeff.VT wrote:
I guess I'm curious - maybe it's because this is the first place I've ever had to use IBM MQ.
Do you connect to 3rd parties via MQ?
Do you have a team people around the world who can and do make mistakes?

Yes, Yes (its called outsourcing)
Quote:
Or are your environments set up such that it's a single flow or message type?

No
Quote:
Because those are the only situations I could envision NOT needing something like this. The one way your networking team analogy is appropriate is that we both deal with a spiderweb of connectivity.
I mean... Let's say you have two connections.
Con 1
Con 2
Remote queues going to a third party.
And some new employee was messing around with IBM MQ and accidentally adjusted Con 1 definition so it was essentially a copy of Con 2 (or even you do it by accident so I don't get the whole "just secure your administration" argument). So now everything meant to go to Con 1 was now going to Con 2.

ITIL Change Control assures that only approved and tested changes are made to production infrastructure. If mistakes are make, there is a chain of responsibility to deal with the impact and remediation.
Quote:
How would you know? How long would it take you to figure that out? What if it's a somewhat rarely used system? What if those messages are only important a week from now, and so the 3rd party and customer wouldn't tell you for a week?
All of the application logging would show it going happily to the correct queue.

The data belongs to the various parties. They need app logging and alerting capabilities to quickly identify issues, and escalation processes to engage teams to analyse the issue and fix it. As an MQ admin, I see this happening nearly every day. We sometimes need to deal with retrying channels or msgs on dead letter queues or running out of disk space, but not much else in terms of app messaging issues. We are very good at helping out the app support teams and suggesting how they can improve their app logs, so they don't need to deal with MQ admins so much in the future.
Quote:
I can literally think of dozens of situations where I would need and want this data. I'm shocked that you guys can't.

Around 1B messages and TB of data pass through our 100+ production queue managers every day, many involve 3rd parties. We don't log any messages at the MQ level. The apps can only question MQ if they can prove that message X was successfully put to a queue, and they can prove that message X did not arrive at the destination queue.
_________________
Glenn
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  Next Page 2 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.