Monitoring (monitoring status of services), along with backup, is probably one of the oldest and most popular tasks for a system administrator. Of course, there are many different tools for its implementation. In this voluminous splendor, even experienced specialists feel it hard to choose. In this text I have collected two popular monitoring systems with a brief description and comparison of pros, cons, and features.
Quite an ancient tool, originally called Nagios (author Ethan Galstadt). During the development process, a split occurred in the developer’s camp and a fork (Icinga) appeared. Now these systems develop independently, but there is much more in common than differences. Nagios exists in the free (core) and paid editions, Icinga is an honest Open source. Initially, a server-oriented daemon on bare C, the daemon is managed through a C-like config (looks like ISC BIND config). All checks are collected in a live queue and executed in strict order. This imposes certain limitations on scalability – the server will keep a large number of checks without difficulty, but the more of them, the more time passes between them. A couple of thousand checks (400 servers x 5 checks per server) makes the monitoring system virtually meaningless – there is too much time between checks. As an option, there is a client application called NRPE, it allows you to test locally, on the client (for those cases when it is not possible to check the service remotely), but this is an option. In addition, the checks through the client are conducted on the initiative of the server, so this does not affect the scalability. Nagios extends very well, plugins are written very simply (and there are a lot of them). Nagios is famous for its powerful and flexible system of readings – in the database it can write letters and send sms and messages to a pager, but there is a whole set of plug-ins – from an automatic call to a traffic light (not figuratively, but literally – this joy is controlled via ModBus). Icinga has two web interfaces to choose from – classic CGI and more modern in PHP. Subjectively, CGI is more convenient, although less flexible. The progenitor (nagios core) has only a CGI-version of the interface. It is important to note that Nagios does not know how and does not want to collect the statistics of answers, therefore it is meaningless to expect beautiful graphs in the style of Munin / Ganglia / Cacti from it. There is a bridge for Icinga connection with Ganglia, this is a fairly popular tandem in which Icinga responds primarily to the network map, hosts overview and notifications.
Main advantages of Nagios
- Simple file format. It can be easily configured using any self-written utilities
- Allows to leave comments with a timestamp
- There are plug-ins for all cases from third-party manufacturers
Disadvantages of Nagios
- There are no built-in visualization tools (except the network map)
- The complexity of scaling without the use of third-party plug-ins
- There is no way to monitor performance
- Can not be configured via interface
- You need to restart the server to take effect of the configuration changes
- Each plug-in runs as a separate process
Initially, this tool is positioned to quickly and easily build SNMP statistics, but with the use of plugins (notify + treshold), it acquires the capabilities of a monitoring system. This PHP application, settings and configurations are stored in the MySQL database (the statistics are stored in RRD, which has a beneficial effect on the performance of the service). Very simple installation and initial setup (everything is done via the web interface), in general, scales well (especially if you use spine with a multithreaded SNMP questionnaire), a large number of basic templates for testing different types of devices. The main disadvantage of the application is its SNMP-centricity. This service is well suited for data collection from equipment, tolerable for collecting typical statistics of service performance (disk space, load CPU, etc.) and disgusting to collect complex and atypical metrics. Customization is poor.
Main advantages of Cacti
- High deployment speed with minimal additional coding
- Simplicity and convenience of the diagram browsing interface and their settings (do not immediately learn something complicated)
Disadvantages of Cacti
- A fairly rapid increase in the number of similar settings in the case of a large number of environments and Java application servers.
- Limited performance of non-native JMX solutions for Cacti.