Jun 22, 2010 6:00 PM
Build Thread: MsmqMonitor
-
Like (0)
I'm using this a a build thread for a ZenPack that I've been working on for the past week and a half. When I've got everything working as expected, I will revise this to be a tutorial-style thread for making advanced ZenPacks. Until then, there's just the code.
This code relies on Egor Puzanov's Advanced Device Details ZenPack and is targeting Zenoss 2.4.5 and later.
A big thanks to Egor, Chet, Matt, and anyone else in the Zenoss IRC channel that helped me get this project off the ground.
Update (6/22/2010): Updated the egg to include several bugfixes/enhancements.
Any update on this? I need to do some MSMQ monitoring and I'm hoping this will accomplish that for me. I have the ZenPack installed but I'm not seeing where I would add the MSMQ monitor to any of my devices. Does this ZenPack add a template or do I need to add a datasource or something? How's that documentation coming along?
Thank you!
Sorry it has taken so long to reply... busy busy busy at work, little time to spare. Here's the documentation I have written so far. It's not 100% complete, and it doesn't detail the actual coding side, but at least it will give you an idea of how to use it.
When modeling a device, the log screen will display an INFO-level message that indicates the number of queues the modeler discovered (i.e. “MSMQ: Found 15 queues.”). Ensure that this message appears before proceeding.
The default thresholds for MSMQ are Warning at 250 messages, Critical at 500 messages. These defaults can be adjusted globally, for sub-classes, or per-queue.
Currently, defining a subclass is the only method of making threshold adjustments for specific servers without adjusting the global template.
The “Queue Type” field is not currently used by the ZenPack. This field was added to allow for greater specificity when monitoring queues (i.e. both a public and private queue with the same name). This was intended to be a "nice to have" feature when I originally wrote the code, but I never spent the time to finish it. If someone wants to finish fleshing it out, be my guest.
After adding or configuring a queue, it must be locked to prevent the ZenModeler from deleting it (if the queue object drops out of the WMI Perfmon pool). I attempted to implement a sanity check in the modeler that would ignore any existing queues, but due to the limitations of modeler plugins I was unable to quickly overcome this problem and opted for the locking mechanism instead. Takeaway: if you don't lock your queues after setting them to be monitored, they *may* disappear the next time the device is modeled (automatically or manually).
I hope that helps. Again, I'm sorry about replying so late, hopefully you'll still be able to get some use out of this pack.
Wow! Thank you for taking the time to put this together! I will be going through this in the next few days and will post back any issues/comments.
Thanks again for your time and energy!
I just realized the version of the code that's posted here is not the most recent one I had (found and fixed some bugs). I'm rebuilding the egg now, will upload shortly.
The egg has been updated. This version should correlate directly to the usage instructions given above. I have requested access to upload this ZP to the community SVN, so hopefully in the near future this pack will have its own link in the ZenPacks master list.
Follow Us On Twitter »
|
Latest from the Zenoss Blog » | Community | Products | Services Resources | Customers Partners | About Us | ||
Copyright © 2005-2011 Zenoss, Inc.
|
||||||||