Monitoring tools are like problem management systems and governments - they're all awful so you just have to try to choose the least bad one! I've done extensive work with QPasa 2.3. It is good in some respects and awful in others. If you have a large site, say over 20 QMgrs it can become unmanageable. If you have a fairly static environment, setting up basic monitoring and alerting is not too bad.
![]() However, if you are constantly making configuration changes, defining and deleting queues, channels etc. The rules are all updated via a GUI - and a pretty inflexible GUI, at that! And that I think is the major problem with QPasa - most things can only be updated by the GUI, which is fine for a couple of systems but just not really useful in a large environment. I believe that V3 is supposed to make things better including the ability to create event rule templates. At the moment, you need to have a separate rule defined for each queue/channel on each QMgr that you want to monitor! And depending upon what you want to do, you may need multiple rules for each queue/channel on each. Expertise in installing and setting up MQ monitoring tools such as Qpasa. • Monitoring tools like Qpasa, Appwatch, Omegamon for MQ related errors. The tools listed in the Table 2-4 are designed for monitoring applications that are running. The release of JDK 8 introduced Java Mission Control, Java Flight Recorder, and jcmd utility for diagnosing. Well, you get the idea. I have used Tivoli as well. Quite honestly I don't think it's much better, although it has the (dis?)advantage that it is not MQ specific and so is part of the wider monitoring world. (MIS) 23 Sep 02 11:30.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |