Hyperic HQ

Hyperic HQ watched over our network with a keen and discerning eye.

Its accurate and thorough discovery feature ferreted out even the most minute details about our network infrastructure, and its interface displayed the activity-based relationships among the infrastructure elements in an easy-to-understand graphical manner. Hyperic HQ noted, for example, device vendors and model IDs, as well as server resources, such as CPU, memory and disk and running applications.

We loved Hyperic HQ’s thresholds, which we could make as elaborate as we wished. We easily set up thresholds for excessive traffic levels that expressed time-of-day relationships – for instance, network use of 70% was acceptable midmorning and midafternoon but not at other times of the day.

Hyperic HQ’s thresholds and associated alerts rather comprehensively covered our network, from traffic levels to server use and from running applications to log files. At our behest, Hyperic HQ even processed security events by detecting, logging and alerting us when someone tried to gain remote access to our servers.

However, we would have like to see Hyperic HQ have more closely monitored applications, such as Exchange, as we’d seen Argent Extended Technologies do in the commercial products test. It e-mails and pages administrators when Hyperic HQ detects a problem.

Hyperic HQ’s remediation feature requires more manual effort than that of Zenoss Core. We used it to perform device- and application-specific control actions, such as instructing Apache Web server to restart. We found we could also control resources in groups that we set up. Hyperic HQ fell far short of the automatic corrective actions of nearly all the midtier tools.

Hyperic HQ’s reports depict problem histories, monitoring status information, network activity levels, network performance data (useful for capacity planning) and network infrastructure inventory data.

The Web-based portal interface is completely configurable. To see the current status and health of our network, we easily configured Hyperic HQ to show highly useful views of monitored data. We also found creating, moving and erasing portlets (customized Hyperic HQ subsets of network infrastructure elements) via Hyperic’s drag-and-drop visual-design environment to be painless and quick.

For the sake of reliability and uptime as well as load balancing, the Hyperic HQ central server component can be clustered. Using Microsoft’s server clustering to distribute the Hyperic HQ workload across two servers, we found that Hyperic HQ works well in a clustered environment.

Coincidentally, Hyperic HQ’s discovery and monitoring components recognized the clustered servers and treated them as a group for alerting and notification purposes. For a small network that employs five to 10 Hyperic HQ agents, Hyperic recommends 10 GB of storage, 512 MB of RAM and a fast single processor. For medium- to large-sized networks using 10 to 50 agents, Hyperic suggests at least 40 GB of storage, 1 GB of RAM and two or more CPUs. For a greater number of agents, you’ll need to run multiple instances of Hyperic HQ.