I am probably a little late, but thought I would add a few thoughts. One of the core issues I have with Zenoss is how it deals with SNMP Tables. To deal with them, I believe that two systems (and/or wizards) would need to be created: * I would love to see table creation moved into templates or alternatively have a wizard to create them. You set up the base OID, the index for uniqueness, a name index to name the row, and any named value indexes that you want to monitor. 95% of the modelers that we have created are largely duplicates of each other (with the OIDs and names changed). Special formatting functions could be an additional step, but again seem like a doable thing. In the background Zenoss could then create a basic modeler or whatever it wants to do. If it did create a modeler, the author could then go in and tweak things as needed. If the results just lived in a template then any special cases could continue to be dealt with in the current manner. Multilevel indexes could be a problem with this so leaving them in the old method would work if you wanted to, but in the end they largely work similar to single index tables and could probably be added with minimal effort. * The second part of this is a TAL include manager and table editor. The current way the TAL files work means that either you copy the files from the core Zenoss Installation to your Zenpack and tack on your tables every time you update the core system or add duplicate tabs to monitor the special tables which means you have to click back and forth if you want to compare tables. However, the modeled trees and relationships are all stored in the ZEO DB, so allow another wizard to create a table based on that data and then include it into the tab. Ideally the base skin file would just set up the framework and all of the current tables would be moved into includes that could then be added or removed based on whatever system works best. If the above was designed properly, Arbitrary tables could also be added for monitoring non-unique non-hardware synthetic based templates (ie multiple databases on a single host, multiple web sites on different ips/ports as sergeymasushko requested, command based tests for special cases on a single host, etc.)
As fdeckert suggests, allow templates to be bound outside the Device tree via things like Groups, Systems, or Products. Which leads into more control over the Device tree. We all believe we know where a device belongs and as such we build ZenPacks that then map that belief. This often leads to duplicate trees that reflect how a device works in each of our environments and things like /Devices/Network/Cisco and /Devices/Network/Router/Cisco. Additionally, some of the issues of having a device with multible uses (the Apache and mysql example that fdeckert supplies) causes us to move templates up the device tree from where they most make sense to be in order to allow us to map the template down multiple branches. This creates a mess at the higher level branches of many templates for specific devices found farther down. There are many ways that this issue could probably be solved, but no matter which way it happens, it will necesitate more control over the way the Device tree is setup. Timing at the template level rather than the collector level for all types of collectors would also be nice so that we can more closely monitor key devices and metrics and back off on the less important ones that may only be used for reporting or later analysis. Of course, I also have to add to the layer 2 dependency request and ways to squash sympathetic events. I think I should leave off for now as I know this is late coming to the table and I believe I have included far too much as it is. -------------------- m2f -------------------- Read this topic online here: http://forums.zenoss.com/viewtopic.php?p=37207#37207 -------------------- m2f -------------------- _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
