When it was launched in 1999 under the name NetSaint, Nagios was the first open-source tool to unify a wide range of essential mechanisms for the efficient monitoring of complex IT infrastructures. It relied on hosts and services, monitoring plug-ins and close collaboration with the open-source community. This approach set new standards back in those days, but since that time, much has changed. It is becoming clear that the use of Nagios is no longer appropriate for monitoring such modern IT innovations. In this blog post, however, I would like to explain why companies should as soon as practicable remove Nagios from their networks and replace it with more modern monitoring approaches.
In many areas, open-source technologies have changed the IT world. This can be seen, for example, in the success of Google's Android operating system, which has had a lasting impact on our idea of modern smartphones since its introduction in 2007. The influence of Nagios in the field of IT monitoring has been especially exciting. Nagios was important, but there are many arguments against the continued use of Nagios. And many users are not aware of the fact that migration to a better solution is no big deal.
Nagios ties up too many hardware resources, burdens IT teams with complex configuration and inevitably leads to gaps in monitoring. IT teams are setting up their monitoring in the cloud and as Docker containers when needed, while developers like to use their own monitoring tools such as Prometheus which can retrieve targeted metrics via querying languages. Many innovations such as containers and managing these via Kubernetes have added new methods to the world of IT monitoring, but nowadays none of these lead to Nagios.
Who still uses Nagios these days?
Nagios is not suitable for monitoring complex networks and systems in modern enterprises with an acceptable degree of effort. Working with Nagios config files has always been inconvenient, but today it is too far out of the mainstream. Other tools rely on automation and configuration concepts that can easily manage even a large set of hosts. They also come with appealing graphical interfaces that relieve the users, while in the case of Nagios working on the Linux console is often unavoidable. The handling of plug-ins and add-ons in Nagios also does not meet modern standards: Updates, documentation and customization of Nagios require too much manual fine-tuning.
As networks have become larger and more complex, and IT teams need to monitor more systems, the use of Nagios places monitoring managers under immense time pressure. This is a risk for companies and IT professionals. There is a danger of IT problems being overlooked, a lack of information on which to base decisions, and a costly commitment of human resources.
Some organizations hoped to improve the performance of their IT teams and monitoring by investing in commercial versions of Nagios, but the disadvantages of the outdated code base remain evident: The workload is comparatively high, the graphical interface is outdated, and scalability is limited by an architecture, which relies heavily on active checks. Monitoring large environments with little effort is simply not practical with Nagios.
When Nagios first appeared, it was still relatively normal for IT administrators to specialize in a few applications. Over the last 20 years, however, the complexity of IT in companies has grown steadily, while the staff levels in IT departments have not increased to the same extent. The demands on IT professionals have been increasing. The time required to learn and operate Nagios is no longer available. Other tools respond better to the needs of users, for example they are easier to use and relieve users through targeted automation.
What does Nagios really cost?
Many companies now have a large number of different monitoring tools. This has often grown historically, for example through former employees who implemented their own tools and then left the company. Often companies still have one or more Nagios core instances in use, since the open-source version can be operated for free, e.g. to support tools from another manufacturer that are subject to a fee.
There is a fallacy here, because an equation that includes Nagios usually doesn't add up. Operating Nagios Core requires hardware resources and users with very deep Nagios knowledge. Due to the high user requirements, it is almost impossible to efficiently make insights from monitoring data available to other teams. As a result, there is a risk of information silos, as only a few users can properly understand the monitoring. Modern tools are much more collaborative. They open up better processing and access to monitoring insights. New approaches can also monitor more assets with less effort. If, instead, companies keep satisfying Nagios' hunger for resources by expanding their hardware resources, they are missing a great opportunity to use their budget more wisely. So, the argument that Nagios is free cannot be sustained if you must invest in expanding your hardware simply to operate Nagios, in addition to the personnel effort – especially if there are more powerful Nagios alternatives that are also free.
Handling Nagios plug-ins
Regardless, which version of Nagios you are running: At first glance, the effort required to switch away from Nagios probably seems like stopping a runaway train. Many companies have built up their Nagios monitoring over many years and thus cannot imagine a replacement solution being simple to implement.
Switching from Nagios can however be quite easy, if the new tool has a good auto-discovery function and provides a fair number of monitoring plug-ins. Additionally, an alternative should support Nagios plug-ins, in case some non-standard host is not supported or someone has built extensively custom plug-ins. If organizations choose the appropriate monitoring solution as a successor to Nagios, they can kill several birds with one stone:
- You can replace outdated Nagios plug-ins with better extensions of the new tool and so improve the quality of the monitoring data. At the same time, you reduce the monitoring's resource consumption, since the new plug-ins work more efficiently.
- You can access more of the new tool's official plug-ins, which are maintained and extended by its developer. This reduces the effort of maintaining the monitoring integrations by your own staff.
- Due to its aging technology, there are certain assets that cannot be monitored well with Nagios, such as dynamic Docker containers. Modern tools offer integrations here as well, eliminating monitoring blind spots.
- Especially open-source-based monitoring tools usually continue to support Nagios extensions, so you can also continue to use self-written Nagios plug-ins.
Does it all sound too good to be true? Of course, it really depends on the monitoring solution. You have doubts that switching to an alternative tool is really possible? We show you a practical solution for replacing your Nagios monitoring with Checkmk.
In our next blogpost we will migrate a monitoring from Nagios to Checkmk – which can be accomplished in just a few minutes. We provide step-by-step instructions, so feel free to try this out for yourself.