| Author |
Message
|
| jdye |
 Posted: Tue Feb 05, 2013 7:41 am Post subject: agent vs agentless MQ monitoring |
 |
|
Apprentice
Joined: 14 Jun 2002
Posts: 31
Location: Kansas City
|
| Okay I am tired of listening to the spiel of two competing vendors on the benefits of agent vs agentless monitoring of queue managers. Of course, whatever they offer is the best and only reasonable way to do it. I would like to hear some real life experiences of users. Has anyone had issues with using agentless? One vendor said that agentless is fine for non-production queue managers but of course you need an agent production environment. I see pro and cons for both, but it would be nice to hear others experiences. Thanks! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Feb 05, 2013 7:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I personally do not like agentless approaches.
It is offloading the work of monitoring the queue manager onto the queue manager itself, forcing that work to move over server connection channels.
An agent-based approach uses a bindings connection to retrieve the exact same information, which is a smaller impact on the queue manager.
But that is an opinion and not an experience.
One can counter my above arguments by saying that an agent performs it's work on the queue manager machine, causing additional load on the processor and memory of the server.
I consider that much easier to track and manage and audit and deal with than trying to isolate the impact of a specific srvconn channel and it's instances - which also cause additional load on the processor and memory of the server. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 05, 2013 11:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
agent less monitoring is fine but you might run into some problems:
How do you determine qmgr down vs channel stopped vs a number of other problems like mq port stopped by firewall?
Usually the advantage an agent gives you is "out of bandwidth" monitoring. You are not dependent on MQ connection or MQ traffic for your monitoring...
Hope this helps some 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Feb 06, 2013 1:07 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Either one done well will be good 'nuff, but I lean towards agent. Yeah, you have to deal with the rigamaroll of getting access to install it and maintain it, and if the agent goes bonkers it can use a lot of CPU or Memory or Disk (excessive logging).
But when things are working as designed, the agent solution will typically allow additional functionality that can't be done thru a QM, things like inspecting local files (error logs and FDCs), being able to restart the QM, getting specific OS and MQ versions, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 05, 2015 6:00 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Update: A lot has changed in the last few years between agent and agentless monitoring, truth be told. I have since had the chance to put my hands on an agentless system and there is virtually very little difference between agent monitoring and agentless monitoring.
Anyways it looks like agentless will be the way to go as the MQ2000 appliance will not allow you to install any agents...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Jun 05, 2015 6:40 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| fjb_saper wrote: |
| Anyways it looks like agentless will be the way to go as the MQ2000 appliance will not allow you to install any agents... |
You mean to say they haven't built in a Tivoli agent? 
_________________
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.
Last edited by exerk on Fri Jun 05, 2015 11:09 am; edited 1 time in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 05, 2015 10:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| exerk wrote: |
| fjb_saper wrote: |
| [b]Anyways it looks like agentless will be the way to go as the MQ2000 appliance will not allow you to install any agents... |
You mean to say they haven't built in a Tivoli agent? |
Tivoli probably, but what about each of the companies doing agent monitoring out there?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Jun 05, 2015 11:30 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
I'm not a fan of the closed box system. Basically, IBM goes on the premise that their code is perfect and everyone else's code has problems.
Years ago, I asked/begged IBM to put my MQAUSX client-side security exit on their DataPower appliance and they refused. They would say 'security reasons' or 'stability reasons' etc.. I had customers who wanted their credentials be sent encrypted from the DataPower appliance to the queue manager. Nothing I said would change IBM's mind. 
Also, there was another problem: they incorrectly implemented the MQCSP structure in the DataPower MQ code and so there was no way to authenticate the DataPower appliance.
It took forever to first get IBM to make the change then actually create a release image for customers to implement. Even after the customers finally got the fix, the credentials were being sent in plain text from the DataPower appliance to the queue manager which is not what the customers wanted but had no choice in the matter.
Apple's iOS system is a closed system but at least they offer an app store where the user can download and install applications.
IBM should do the same thing for their appliance boxes. Have it be a closed system but offer 'approved' applications to be installed on the appliance. There is nothing special about IBM's appliances, they just run a harden version of Linux (from what I have been told).
When IBM installs its own competing software (i.e. monitoring agent) on the appliances but does not offer the ability for their competitors to have their software installed on the appliance then IBM is walking down the 'anti-trust' world and the DOJ (Department of Justice) loves taking companies to court over this.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 05, 2015 11:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I have several different, conflicting opinions about appliances.
I do, however, generally support the blocking of "user applications" on appliances. Part of the main feature of appliances is "it's pure IBM code, not messed with and running on a well configured system".
Also, iOS is not a closed system any more. You can get a unix prompt. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Jun 05, 2015 12:14 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| mqjeff wrote: |
| I do, however, generally support the blocking of "user applications" on appliances. |
I would say that is ok "if" IBM allowed approved applications on the appliances.
| mqjeff wrote: |
| Part of the main feature of appliances is "it's pure IBM code, not messed with and running on a well configured system". |
I'm sorry but IBM developers are no different from any other developers - they are human and humans make mistakes. Saying we only allow IBM code on the appliances because we are superior coders doesn't fly with me.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 05, 2015 12:16 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I didn't say it was because we were superior coders.
I said it is because it is code directly and only from the vendor...
I'm not going to argue the point much more. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Jun 05, 2015 12:25 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| mqjeff wrote: |
| I didn't say it was because we were superior coders. |
I didn't say you said it. It is the impression I was given many, many years ago when I asked to have MQAUSX client-side security exit installed on the DataPower appliance.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mo_lightapps |
| Posted: Fri Oct 16, 2015 9:55 pm Post subject: |
|
|
Novice
Joined: 12 Oct 2015
Posts: 18
|
I have administered MQ on distributed platforms for a number of years now and have been burnt a couple of times by dodgy custom monitoring code running on the same server as the MQ installation. Most outages were either my own or a colleagues fault. In my experience running anything other than MQ on a server is a risk not worth taking. I don't think load on MQ is a reason to dismiss agentless, the only over head of connecting via server connection channel is network overhead. Most of which is spent with threads blocked waiting on network I/O to complete. The remaining code path in theory should be the same or similar. IBM are in a better position to confirm or deny that, so don't quote me.
Some examples of where running non MQ processes on the MQ server went awry for me:
Outage 1 - we had a utility written in C which we used to browse the contents of queues. We used that utility for everything from one off browse operations, message dumping to files to monitoring as part of regularly executing scripts. One day I start receiving reports from application owners that their applications are logging connection reset errors from the queue managers. A few days went by and we were still not 100% sure as to what was causing the error. I was desperate and decided to fire up top (linux host) and just watch the processes go by. Low and behold the C utility which we entrusted everything to was consuming all the available RAM on the system, forcing it to swap heavily. The thing that made this condition difficult to identify was that this would only happen when our monitoring scripts were scanning queues during a busy period (large backlogs and all that). In the end numerous leaks were identified in the code and after heaps of load testing we managed to patch the code. I never looked at that utility the same again!
Outage 2 - Our mq system was configured to execute under veritas control. The resource dependency hierarchy in veritas was configured such that our web server (which provided a rudimentary queue browsing function for users) became the most critical process. A routine change procedure required us to shut down the web server which triggered veritas to think that the entire system had failed causing an un-necessary restart. Granted, this was the fault of the person who configured veritas but a well designed system is one which has proper separation of concerns.
I think monitoring over a server connection channel provides better separation of concerns than a local agent process on the queue manager host. A pessimistic administrator for example may choose to create a server connection channel which a monitoring system could use with the following attributes:
- Setting a MAXINST and MAXINSTC value
- Setting an MCAUSER to a user with a low scheduling priority (OS level)
- Setting a low MAXMSGL
- Setting a higher SHARECNV setting
An agentless monitoring system should be built such that a queue manager which cannot be reached triggers an alert itself. At the point the administrator knows roughly where the issue lies before beginning further investigations.
_________________
LightApps - Creators of Lighthouse software. Modern web based management of messaging systems IBM MQ and Solace - queue browsing, automated configuration deployment and monitoring.
www.lightapps.com.au |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Oct 21, 2015 2:31 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
A poorly written application will always cause problems no matter the environment. There are far too many people being hired as programmers that really should be doing something else.
Even a poorly written agentless monitor can cause major issues for the queue manager. Just because you have an agentless monitor does not give you a free pass.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 21, 2015 10:03 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| RogerLacroix wrote: |
There are far too many people being hired as programmers that really should be doing something else.
|
Also so called "on the job" training is all very well if there is a culture of investigation, asking questions and challenging assumptions.
_________________
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 |
|
|
|
|
