Nagios alternative: Tired of them? Comparison with Pandora FMS
This post is also available in: Spanish
Even though nobody can agree on how to pronounce it, Nagios is still the name that comes to mind when one thinks about monitoring an IT environment. Why so? Many reasons, young Padawan, but basically it is a landmark in the crowded terrain of monitoring software. We, the good people of Pandora FMS, are here today to take an in-depth look at Nagios (Na-jee-ohs? Na-gai-us?) and to throw our own hat into the ring, as a contender for the crown, as a serious Nagios alternative. Read on for our compare and contrast analysis of the most important features of both tools.
Nagios was released in 1999 (the same year as the original Blackberry and Napster, just to give an idea of its hierarchy) as the first complete package of monitoring software. It went on to establish the canonical monitoring standards that all solutions now follow. Since then, it has been added to, incorporating add-ons, plugins, and third-party elements, the vast majority deriving from its loyal community.
Pandora FMS started from a clean slate in 2004 (along with Facebook, Skype and Firefox, just to give an idea of the wildly different technological landscape into which Pandora FMS was born). Pandora FMS was conceived to be a comprehensive solution to issues that were unresolvable at the time with a single piece of software. Its evolution has been guided both by the OpenSource community and by its own users and clients, whose demands and requirements have played an important part in shaping the tool that we have today. All this without using third-party contributions; every update is official.
Nagios is designed to run on Linux, and to store data in plain text files, which can be rotated, or not, in order to free up storage space. It doesn’t use a default database but there is an external utility (ndoutils) that exports the information and loads it in MySQL.
Nagios is coded in:
- Core: C.
- Agents (NRPE, NRDP, NSClient++, NCPA): C and C++.
- Web console: CGI and a little PHP.
The bulk of the monitoring is carried out by a system of plugins that can be developed in any programming language: Bash, C++, Perl, Python, etc.
Pandora FMS, on the other hand, does indeed use a MySQL database. This implies certain infrastructural requirements but also offers many advantages when it comes to using and managing the information retrieved as well as facilitating maintenance and performance.
Pandora FMS is coded in:
- Server: perl.
- Satellite server: perl.
- Agent Linux: perl.
- Windows Agent: C++.
- Android agent: java.
Proxy and broker functions are integrated on the Pandora FMS agent and don’t require any additional components to be installed.
Unlike Nagios, most of the essential monitoring functions are integrated onboard, whether on the web console and server, or on its agents, and don’t require any additional plugins to carry out the majority of tasks.
Despite this, there is also a library of specialized plugins available for Pandora FMS. These are essentially for executing complex tasks, oriented toward application monitoring, and are able to access remotely or locally to OpenSource and Enterprise applications.
Nagios incorporates a layer known as Nagios Core Config Manager to facilitate its own administration, which consists of a web console where most tasks can be carried out. It does, however, have a few lacks such as not permitting simultaneous agent configuration, or the establishment of coherent groupings of monitored agents.
Setting up new checks is done via wizards or plugins and in both cases a certain amount of specialized systems knowledge is necessary, since most function at command layer. It doesn’t include native checks out of the box, and cleaning up errors is a manual job, performed at terminal level.
Pandora FMS has its own web console. It permits task centralization and also centralizes practically 100% of the administration and management of your monitoring. At no time is it necessary to go down to machine layer as all system management can be done remotely. Dynamic menus and the clarity and design of the interface mean that navigating the console is more intuitive and aesthetically pleasing than on Nagios.
There are numerous preconfigured modules available for the tool that cover the most common monitoring necessities, and which don’t require specialist knowledge. In a few cases it may be necessary to add your own checks and to get your hands dirty down at machine layer. However, given its flexibility, and customization possibilities, Pandora FMS’s resources can be easily extended with custom checks or additional plugins to perform more complex tasks.
Managing large environments
This is where Pandora FMS starts to put blue sky between itself and its competitor, where its viability as a Nagios alternative starts to become more apparent. Due to its system based on plain text files and tedious configurations, Nagios’s problems multiply in large environments. For starters, there’s no way to massively deploy checks over a high number of agents; and data file management gets complicated if it’s necessary to handle large amounts of information. And what other amounts of information are there?
Pandora FMS, on the contrary, is set up for optimal performance in large-scale Enterprise environments, featuring diverse tools intended to operate specifically in these situations. The Open version has a series of template modules that can be applied to as many agents as necessary, as well as being applicable on recently integrated agents, via auto-discovery tasks. Furthermore, it allows massive editing or deleting of elements (modules, agents, alerts, etc.) in an intuitive way.
What’s more, in the Enterprise version, there is a powerful function for achieving centralized monitoring control: policies. These consist not only of groups of modules but also of alerts, plugins, collections of attachments (for massive deployments), etc. Policies can also be applied to as many agents as necessary, and with just a single update of any one element of the policy the change will be inherited by all the agents included in the same. Last but not least, Pandora FMS also has an additional component for managing geographically distributed environments with independent databases: the metaconsole. It constitutes a central control point from which to oversee all the local networks simultaneously.
One of Nagios’s strengths is the time it’s spent in the marketplace, and its user community, thanks to whom it is nourished and maintained with plugins and third-party components. These components allow Nagios to monitor almost any infrastructure or technology. This, however, is a very DIY way to proceed, requiring some specialized knowledge and slowing down the deployment and initializing of monitoring services.
With its powerful server and agents, Pandora FMS has the necessary technology out-of-the-box to perform practically any kind of monitoring, without the need for external elements, plugins or extensions. It supports remote technologies, including SNMP, ICMP, WMI, TCP, UX monitoring, etc.
Reports and custom maps
Both alternatives allow the user to create custom screens. In Nagios this is done via an addon, nagvis, whereas in Pandora FMS it comes as standard.
Due to its dual nature as OpenSource and Enterprise, Pandora FMS has a more powerful report generating system than Nagios that includes more default report types, but also allows a greater level of customization.
The screenshots below give a better idea of what’s possible with each tool. Clearly, at least for this humble IT guy, the Pandora FMS reports are more visually pleasing, and easier to interpret:
Agent-based monitoring is sometimes considered to be problematic. Nevertheless, although installing software on production systems can imply some inconveniences, agents are almost indispensable for carrying out local monitoring tasks, as they are capable of reaching deeper layers than remote monitoring is able to.
Nagios employs different agents (NRPE, NCPA, NRDP…) that are designed to execute different plugins. Many of these agents, however, are long overdue an update, and, like almost everything on Nagios, require laborious, low-layer work.
As a Nagios alternative, Pandora FMS shows another clean pair of heels along this straight, as its agents are some of the most powerful on the market, outrunning those of its competitors. Apart from performing the habitual monitoring tasks, they have other interesting functions. They can be used to receive files and serve as mechanisms for deploying software, plugins and configuration files. They support proactive monitoring, being able to execute actions based on pre-established conditions, in function of the data they receive. And they permit programmed monitoring checks to be carried out, programmable to the day, hour or even minute of execution.
Pandora FMS as Nagios alternative
To sum up, it’s only fair to acknowledge Nagios’s user community, and its fundamental role in establishing centralized monitoring as a staple of IT services. Unfortunately, unlike fine Bordeaux wine, Monica Bellucci or George Clooney, Nagios hasn’t aged well. Like a lumbering stegosaurus, it struggles to adapt to fast-changing, modern infrastructures, where time and resource management are priorities. Pandora FMS has focused its own efforts on not only maximizing its technical capacities but also on providing a flexible solution able to adapt to demanding IT environments while maintaining accessibility, usability and a more gentle and forgiving learning curve. Plus, everyone knows how to say it.