Test Driving Zenoss - page 3
Adding nodes manually is extremely tedious. Zenoss is capable of Layer 3 discovery, which means it can find IP information, like routing tables and automatically enumerate your hosts, but it cannot provide Layer 2 information, such as "what switch port is this host attached to?" Starting discovery on a subnet is not straightforward, but the guide explains it all.
I decided to "discover" a subnet which contained 55 Solaris and Linux servers. After browsing to the Network section, locating the subnet (it already knew the subnet because it was in the routing table of a host we added), and clicking the secret magical arrow menu button, Zenoss was told "Discover Devices."
After nearly an hour of churning, due mostly to timeouts on devices with no SNMP running, Zenoss reported that it was done. On the main Dashboard page I was able to click on /Devices/Discovered and find all of our SNMP-able hosts from that subnet. Now, the only thing to do was set the production state (production, pre-production, test, etc), and the Class (/Devices/Server/Linux).
At this stage of the game, most NMS products are usually extremely painful to deal with. Zenoss, on the other hand, consumed much more time than anticipated--we could not stop playing with it. We added another subnet that contained around 100 nodes, and started organizing them into classes and production states. It was extremely fun, and the best part is that after a day of Zenoss running, we had charts of some extremely useful information about our servers. Tools such as Cacti or Munin can collect this type of information, but anyone who has configured either of those tools knows that it is barely worth it.
If you decide to give Zenoss the keys to your network gear (SNMP community), watch out! You are in for a treat. Zenoss will automatically discover the Layer 3 topology, and clicking on "Network Map" provides an extremely good, interactive map of your network. The accuracy rivals HPOV, and the usability is unmatched. Oh, did we mention that simply pointing Zenoss at your routers and switches would obsolete another piece of enterprise software? Cricket, the prevailing traffic stats collector for network gear, just became useless to this Zenoss user. After Zenoss has crawled a switch, you can simply browse to the "OS" tab and view all your interfaces and their descriptions. Clicking on one brings up the graphs of bandwidth, packets per second, and errors. The performance tab provides the CPU and memory usage graphs for your Cisco. So long, Cricket.
These features are all great, but we really want to obsolete Nagios. Sorry Nagios, you're a pain to configure and scale.
Zenoss has a leg-up already, since it knows about most of our servers as a result of discovering them. It tries to automatically generate events when the CPU load goes too high, or when a well-known service it has discovered seizes to function, but we certainly don't want pages in the middle of the night about things we could care less about. Configuring monitoring is not straightforward in Zenoss, but we're expecting to discover that it is both fun and productive. We're off to read the documentation, install some ZenPacks from the community pool, and see if we can really wean myself off Nagios.
This article originally appeared on Enterprise Networking Planet, an OnlineJupiterMedia site.