Pandora FMS wins open-source monitoring shootout

Doing more with less remains an ongoing challenge for IT execs. Making sure everything keeps humming along to meet service-level agreements can be challenging for resource-stretched IT departments. For all but the smallest shops, effective monitoring requires tools that provide a meta view of the entire infrastructure with drill-down capabilities.

provides an attractive alternative to more costly commercial products, but can open source products deliver enterprise-grade results?

To answer this question we tested four open source products: OpenNMS, Pandora FMS, NetXMS and Zabbix. All four have solid user bases and recent updates. Our focus was on ease of installation, management tools and interface and, of course, the monitoring capabilities of each product, agent vs. agent-less, auto-discovery, etc.

We tested two products, OpenNMS and NetXMS, on Windows, and the other two, Pandora FMS and Zabbix, on Linux.

It is worth noting that each time we review a new batch of network monitoring tools we see major improvements across the board. Vendors are beginning to tap in to customers’ monitoring needs in a more management-focused way. GUIs are finally becoming the norm. Coders don’t like them, but they usually aren’t in the ranks of IT management staff that needs to make rapid decisions to meet SLAs.

+ MORE PRODUCT REVIEWS: What IT admins love/hate about 8 top network monitoring tools +

All four products were surprisingly good. Overall we liked Pandora FMS for its ease of installation and modern user interface, with easy to read information, a plus when using a smaller device like a tablet. In general, configuration was easier and more intuitive with Pandora than the other contenders, something that is sure to appeal to busy system administrators.

NetXMS came in a close second with similar positives as the winner; a nice user interface, easy to configure rules and a solid user manual. It was not the winner because some of the navigation was less than logical and the ‘save’ feature needs improvement.

So, are these products enterprise-ready? Overall, we found all four products suitable for enterprise use in small-to-midsize environments. However, this limitation is expressed only because we didn't perform high capacity or geographically distributed tests.

Each of the four products tested offers commercial options, but these vary widely. For example, NetXMS and Zabbix are available only in one open source version with optional paid support plans. OpenNMS is distributed in two different versions, both based on the same open source code, with the commercial version offering LTS (long term support).

PandoraFMS offers several commercial versions that contain additional features and support for higher capacity environments. To determine suitability for large organizations or highly complex environments, it's best to consult the vendor and request a commercial evaluation. (See .)

Here are the individual reviews:

NetXMS

NetXMS is a network monitoring and management tool that runs on Windows and Linux. We installed version 2.06 in a Windows server environment. This turned out to be an easy install, using a step-by-step wizard with just a few user inputs needed. Once installed, the NetXMS server runs as a service and provides a desktop management console, which the vendor calls the Workbench.

The Workbench is logically organized with a Windows Explorer type layout; a navigation tree to the left and detailed information in a larger right-hand panel. It also has a comprehensive top menu with more than 50 choices. It can be organized into different tabbed views or dashboards, providing an excellent level of customization.

Network monitoring with NetXMS requires SNMP or NetXMS proprietary agents. First we ran auto-discovery of our test network without agents and this worked fairly well, although it took quite a while to pick up nodes and some nodes were not discovered. However, we were able to add these manually from the Workbench.

With our network nodes all added to the Workbench, we set out to add a few data collection points. The first one was a simple network interface monitor to see how much traffic was passing through. Then we set a CPU alarm on one of our servers to notify us when utilization exceeded a certain threshold. Both of these were straightforward to configure using the administrator’s guide. By using the MIB explorer, you can ‘walk through’ the MIB (management information base) to locate various object identifiers that can be used to create data collection items.

After creating and testing a couple of basic rules, we decided to deploy NetXMS agents to a couple of nodes on our network. The agents are available for most platforms, including generic x86 and 64-bit versions for both Linux and Windows. There are some benefits to using the NetXMS agents, one is that traffic between agents and the server can be encrypted. Other benefits include centralized configuration and also the ability to execute commands on managed systems. Adding SNMP and NetXMS agents upped our game considerably and we got a more in-depth look at each node, plus we were able to quickly add multiple pre-defined data collection parameters.

When an alarm threshold is reached, NetXMS provides multiple courses of action. For instance, an email or text message can be sent to one or several recipients. You can also automatically have a command or script executed on the node or the management server, providing unattended failover options.

NetXMS provides a mobile console for administrators on the go. The mobile app is currently only available for Android and the features are mostly limited to read-only tasks. However, it does provide alarm notification with the ability to acknowledge and resolve. There is also a mobile agent for Android devices that allows for reporting static information about make and model in addition to monitoring of a few dynamic parameters, such as battery life and last data activity.

In addition to solid on-screen reporting features, including various types of graphs and geo maps, NetXMS integrates with the Jasper reporting engine that provides PDF report exports. There is a user guide in addition to a more comprehensive (more than 300 page) administrator’s guide.

There is lot to like about NetXMS, ease of installation is always important in our book. Configuration is mostly straightforward, but it is somewhat easy to get lost in some of the menus, especially when trying to navigate the aforementioned MIB explorer. On a few occasions we encountered issues with our changes not being saved. It is not readily apparent when something is automatically saved or when you need to click the tiny ‘disk icon’. The user interface is intuitive, the footprint of the server and the agents is relatively lightweight, and we measured about 2MB of memory use on average for the agents.

OpenNMS

We installed OpenNMS 18.0.1 on Windows Server 2012. OpenNMS runs on Java (version 1.8 or higher) but can also be installed on Linux and OS X systems. Although the vendor warned that the Windows install was a bit tricky compared to Linux, we actually found the opposite to be true. The Windows install consisted of 1) installing the latest Java SDK; 2) setting the JAVA_HOME path (important); 3) installing PostgreSQL), and running the OpenNMS installation script.

We then started the service with a vendor-provided batch file, which worked flawlessly. After the service was started we connected via web interface and right away began finding and monitoring network nodes. No errors, no problems. The CentOS 7 Linux install, on the other hand, was eventually abandoned after we got entangled in a maze of database and other configuration dead ends, even after carefully following the installation instructions.

Up and running on Windows, we found the management interface layout clean and logical with the home screen showing a meta summary of network availability along with notifications about outages and other pending issues. No client agents are needed to run basic monitoring tasks on discovered or manually-added nodes. To get started you need to either manually add one or multiple ‘nodes’ to monitor or you can use the auto-discovery feature to find ‘nodes’ on the network. We started by configuring the auto-discovery to find servers on our local test network and a subnet at a remote location.

OpenNMS is event-driven and events are displayed on an easy to read dashboard-type page. The dashboard provides a summary overview of the state of the infrastructure by categories such as Web, database and DNS servers. At a glance you can see active outages together with availability percentages. The dashboard allows you to drill down to the detail level to see current or recent outages, depending on the type of service along with the type of monitoring performed. This makes for easier troubleshooting and the ability to identify bottlenecks, persistent issues vs. one-offs.

On our local-area test network it did not take too long to discover the nodes, but at our remote data center location we needed to make some firewall tweaks in order to allow traffic to and from OpenNMS. Several of our servers run services that were automatically discovered, for instance DNS and HTTP services were detected and added to the monitoring. The auto-discovery is very granular so nodes on a network can easily be included or excluded from discovery. This flexibility provides for easy addition or removal of nodes as well.

Data collection and monitoring can range from simple ping commands to more advanced methods, such as SNMP traps, JMX, WMI and Syslog events. A lot of the configuration is stored in XML files, some of which can be rather lengthy. Remote ‘pollers’ (agents) can also be deployed to offsite locations to keep track of infrastructure availability.

The ‘poller’ can be installed from a URL on the OpenNMS server using a short wizard with a few prompts for basic information such as the OpenNMS server IP and user information. The topology map was useful, although a bit sluggish. To be fair, this might have been due to our somewhat memory-constrained test server. The geographical map is faster and for organizations with a distributed infrastructure, this feature is definitely helpful.

In addition to on-screen alerts, OpenNMS can be configured to send notices via SMS or email along with integration with existing third-party trouble-ticket systems or custom solutions. We liked the robust reporting feature using Jasper Reports that provides both pre-built and custom reporting options, with the ability to export to common formats such as PDF and CSV.

The built-in search feature makes it easy to search on a variety of parameters such as name, IP, MAC and our favorite, the ability to search by ‘service provided’, such as ‘HTTP’ or ‘DNS’. There is also an asset search feature that allows you to seek out items such as ‘laptop’, ‘server’ or ‘telephony’. We also found it helpful that several of the pages have a quick explanation of terms and features on the page itself. For instance, a short narrative on the reporting page explains each of the report types.

Support is available through several resources (discussion groups, Wiki online documentation and IRC). There is also commercial support options available, at either $19,995 for ‘prime’ support and $49,995 for ‘ultra’ support.

Pandora FMS

We installed Version 6.0 SP3 on a CentOS Linux server. This was an easy install from a live image (note to vendors: live images should be the industry standard). After loading the web-based interface, we were greeted by ‘Pandorin, the annoying assistant’, (the vendor’s description, not ours). Since the days of the old MS Office assistant we’ve not been too keen on such ‘helpers’, so we decided to go it alone and sent Pandorin packing.

Overall the Web interface was modern and uncluttered, with easy to read information. The welcome screen provides a quick overview of the status of the network with lists of any open alarms, the number of agents deployed and a list of recent tasks performed in the console.

To start out, we wanted Pandora FMS to map out our test network. After consulting the user manual, we found out that creating a monitoring template was the best starting point. You can create custom templates with your own monitoring choices and decide which template to apply. With a basic template in hand, we created what they call a ‘recon task’.

As the name implies, it scouts the network for devices that fit a certain set of criteria, this can be, for instance, all Linux servers running on a certain subnet. Once these devices are found, it will apply the monitoring template for those devices, in our case a small group of Windows servers.