Ah, pity to reply to my own response like this but I thought of one more uber-useful feature that needs to be added, whether it be by me, the community, or the ZenOSS organization:
8) Custom graphs/dashboards for aggregating+viewing RRD data. Among the features that makes Cacti the best "monitoring" tool for viewing trending/graphed data (in spite of its horrible interface for creating custom templates/graphs ;) is the ability to create custom graphics pulling data from all available RRD's in the system. EXTREMELY useful for creating aggregate graphs for ingress/egress bandwidth via WAN/internet links, total filer ops for a Netapp cluster, jobs in queue for a cluster, etc. It's currently great that so MUCH info can be gathered with zenoss, one way or another, but the ability to do something useful with that is still lacking, IMO. Even alerting is fairly undeveloped, but in time surely will evolve as well. Again, thanks for asking for input. Cheers, /eli Eli Stair wrote: > > Definitely. Sorry for the long email, I assume you're interested since you > asked, if not skip to the bottom for my top-7 list in quick summary ;) > > I'm currently migrating (and significantly expanding upon) my current very > customized Nagios deployment. I've got >5,000 hosts, >20,000 frequent > service > checks across my "enterprise" composed of several international > locations and > WAN links, making extremely extensive use of service dependencies and event > handlers, as well as being very dependent on the parent directive (among > others > obviously ;). Nagios has some extreme limitations, but works very > dependably > as an alerting mechanism. The addition of trending/graphing, combined > with the > core infrastructure is one of the few ways to improve on it, IMO. Or to > make a > superior package. > > In the process of testing and rolling out zenoss, I'm quite impressed by the > number of things that have been included, but my biggest concern is that > there > are a large number of features that are not documented well (if at all), > or are > "included" but non-functional. Specifically, WMI access, > event-handler/response script usage, the RPC/XML API, and a number of other > items I've attempted to use are either downright broken or there is no > way to > access without doing serious digging through the underlying code to > glean some > knowledge... that's not a very efficient way of trying to implement > something. > > That being said, I'm not trying to be negative, but give you some creative > criticism. I'm making a serious effort to utilize what does work, > figure out > what doesn't and document it, etc. I've already written some scripts to > handle > integrating Zenoss with other tools using what IS known about the API and > system to interact with it. I'm concurrently evaluating Zabbix and Hyperic, > both of which are missing some core functionality that you have already (but > sometimes doesn't work), and flaws of their own to be sure. > > What I'd like to see most out of the next few releases of zenoss: > > 1) Stability of the core daemons, and better (useful) alerting on their > failures. > 2) Functional WMI system with documentation on use. > 3) Xenpack documentation, and a system that works. > 4) API documentation, abilities, examples, how to replicate GUI actions, > etc. > 5) Better documentation of "event handler" equivalents. > 6) Network parent device capabilities, needs to support >1 device > 7) Service dependency support, integrated with event handlers. > > So most of the groundwork for that appears to already be laid very > firmly. I > know from the list that problems I've seen are seen by others, and are > likely > being worked on already. The topic of documentation is a sticky one, > everyone > (including me) would rather be "doing" rather than writing for > posterity, but > it's hard for new adopters to get much use out of the product (and stick > with > it), and eventually buy something if it's TOO difficult ;) > > > Thanks for creating such an exemplary piece of code so far. Lots of people > have "tried" to do better than Nagios, without much success or even hope... > without contributing back anything of worth to the community. While you > guys > have gone on a tangent, it's obviously with skill and an actual goal. > Doing well. > > > Cheers, > > > /eli > > > > mrhinkle wrote: >> We have noticed that many Zenoss users are former Nagios users. To help >> understand what features you liked in Nagios and replicate those >> features in Zenoss we need your help. If you have thoughts please >> respond to the poll and offer any other insights you might have to make >> your migration from Nagios to Zenoss more rewarding. If you have other >> thoughts not addressed in the questions on the poll please expand upon >> them in the comments. Thank you for your participation. >> >> Mark >> The Zenoss Community Dude >> >> >> >> >> -------------------- m2f -------------------- >> >> Read this topic online here: >> http://community.zenoss.com/forums/viewtopic.php?p=9446#9446 >> >> -------------------- m2f -------------------- >> >> >> >> _______________________________________________ >> zenoss-users mailing list >> [email protected] >> http://lists.zenoss.org/mailman/listinfo/zenoss-users >> > _______________________________________________ > zenoss-users mailing list > [email protected] > http://lists.zenoss.org/mailman/listinfo/zenoss-users > _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
