| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Application Traffic on the Network |
« View previous topic :: View next topic » |
| Author |
Message
|
| Richter12x2 |
 Posted: Fri Jun 04, 2010 9:52 am Post subject: MQ Application Traffic on the Network |
 |
|
Newbie
Joined: 04 Jun 2010
Posts: 4
|
I'm not sure if this is the best place for this question, but I'm very new to MQ and from a different perspective, so here goes.
I basically run and configure a network-based monitoring tool, and I'm looking to make sense of what I see on the network. I'm not involved in configuring the servers directly, so I can only go off what data I have and hypothesize, so I'm hoping to appeal to an MQ expert's knowledge to see if this makes sense.
We have a group of Linux application servers that are configured to provide a service on a particular TCP port, like 25024 for example. Normally I would expect to monitor that port for traffic, but when I monitor that port for weeks, I see no traffic.
When I view the netstat -n outputs for the servers, the only services I see provided consistently are 1414 (MQ Series). The application group audits the logs for their services and see connections on their port, 25024. When we look at the netstat output, there aren't any entries for that port at all, even from the box to the box.
My theory is that the requests are tunneled in over MQ and the conversion and conversation is done without accessing the regular network channels, which is why we don't see 25024 on the server or on the network at all. Does this jibe with the way MQ works? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Jun 04, 2010 9:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Is MQ even installed on that machine?
Is there a queue manager configured on that machine? Is that queue manager configured to use the default port of 1414 for it's MQ Listener?
Is there an application configured that will talk to that queue manager and make connections on port 25024? A queue manager by itself will not do this. Depending on the protocol that the app is using over port 25024, there is some possibility that a service that comes with MQ could be configured to forward data to this app, but pretty much that's only if the app is using HTTP. |
|
| Back to top |
|
|
| Richter12x2 |
| Posted: Fri Jun 04, 2010 10:24 am Post subject: |
|
|
Newbie
Joined: 04 Jun 2010
Posts: 4
|
Pretty sure it is an HTTP app - so that wouldn't be out of the question? Unfortunately I can't tell to what extent MQ is on the box, other than that it's sending and receiving traffic on 1414 from my perspective  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 04, 2010 10:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
there are HTTP bridges and gateways that come with MQ that could be moving traffic from MQ onto HTTP.
The app team could have written their own application to do this.
But network traffic on port 1414 is no guarantee that MQ is being used at all. |
|
| Back to top |
|
|
| Richter12x2 |
| Posted: Fri Jun 04, 2010 10:57 am Post subject: |
|
|
Newbie
Joined: 04 Jun 2010
Posts: 4
|
Awesome, I have confirmation that these app servers are communicating using HTTP, so it looks like I have a match.
I know that 1414 is just the default for MQ, but it's been the rule rather than the exception at this customer so far to use defaults for almost everything (or at least wellknown secondaries, like 8080, 8443, or 9080).
Thanks for your help!
The followup clarification just for my own personal understanding - in this type of instance, where we have multiple members of the same MQ pool performing this service, this is basically like a kind of load balancing, right? So each server is basically processing the incoming requests as they become available?
If that's the case, it may explain some other unusual traffic we're seeing as well. Things like supposedly load-balanced servers that seem to show a bias for particular servers. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 04, 2010 11:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You really can't make any assumptions about MQ function or load balancing from looking at the network layer traffic.
You really have to look at the MQ layer configuration.
You shouldn't really be using network layer tools to monitor MQ layer traffic, or MQ listener ports, you could be creating lots of error messages on the MQ systems and doing fun things like interrupting MQ traffic itself, without having any visibility into the effect you're having. |
|
| Back to top |
|
|
| Richter12x2 |
| Posted: Fri Jun 04, 2010 11:36 am Post subject: |
|
|
Newbie
Joined: 04 Jun 2010
Posts: 4
|
Let me clarify - what I'm monitoring is tapped traffic with an extensively tested solution designed for the purpose, I'm not talking about taking a packet capture from the command line of the server or something homegrown. Like I said, I don't have access to the server, physically or virtually to have an affect on it anyway.
Now that we've estimated the traffic is MQ, if it were necessary I can turn on the MQ analyzer in our tool and get detailed information on what the MQ is doing. I'm just interested in the health of this software application though, and with your responses, it looks like monitoring the availability and performance of the incoming traffic on port 1414 should be indicative of the availability and performance of the service on that server. Which is all I'm going for at this point. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 04, 2010 12:43 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Richter12x2 wrote: |
| Let me clarify - what I'm monitoring is tapped traffic with an extensively tested solution designed for the purpose, I'm not talking about taking a packet capture from the command line of the server or something homegrown. Like I said, I don't have access to the server, physically or virtually to have an affect on it anyway. |
If it's really using MQ, and your monitoring does something to disrupt the network layer traffic, this could cause issues with the queue manager and you'd never know it from the network.
| Richter12x2 wrote: |
| Now that we've estimated the traffic is MQ, if it were necessary I can turn on the MQ analyzer in our tool and get detailed information on what the MQ is doing. I'm just interested in the health of this software application though, and with your responses, it looks like monitoring the availability and performance of the incoming traffic on port 1414 should be indicative of the availability and performance of the service on that server. Which is all I'm going for at this point. |
That's an unsafe assumption.
And, as I've said, I would not assume that even though the application team says they are using HTTP and you see traffic coming in over the default MQ port, and you have been told that there are ways to bridge MQ over HTTP or forward data sent over MQ to HTTP - that MQ is involved in any way. That's also an unsafe set of assumptions.
You need to get the application team to be specific about what configuration has been made on this machine. If they at least go as far as to confirm that they are receiving data over MQ, and that their queue manager is using the default MQ port of 1414 (there's *no* guarantee of that)... THEN I would be comfortable assuming that if there's some traffic coming in on that port, then at least something is running.
But the app on the other side of the MQ listener port or the MQ queue manager could still be dead and you'd never know it from monitoring incoming network traffic. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
