Besides Nagios, Icinga and check_mk there are some other, more slimmer tools to monitor servers. Especially if you are a private person and you want to monitor your vServer, Raspberry Pi or whatever, you may want to use a smaller and easier monitoring solution than those big three.
This article is about monit. Monit is one of these simple monitoring tool. However, just because the configuration is more simple, that doesn’t mean hat you are limited in the ways you monitor your servers with Monit.
How does monit works? And why not just use Nagios?
monit works differently than Nagios or Icinga. While Nagios, Icinga and check_mk needs a monitoring server which connects in given time periods to the machines it checks, monit doesn’t need this kind of server in order to do these checks. So basically that means that wherever monit is installed, it checks locally and reports the results via mail.
In the first moment this sounds like a disadvantage whether it be due to reliability or security, but think about it for a second: What does Nagios, Icinga or check_mk basically do? They ping the destination machine and if this ping is successful it opens up an NRPE or SSH connection and executes the given CPU, Ram, service checks and so on, locally. The console output is then used for analysis. If the check exceeds it’s given limit, Nagios / Iciniga / check_mk creates an E-Mail and send it to the user /group of users which is / are responsible for this service. So basically the server executes local commands like monit. The initiator however is not locally, it’s a different (remote) server.
You now may think “but how do I even test if the server is available?” (the remote ping which is executed by Nagios). Well, you just setup another monit instance which is checking if the destination is pingable, just like with Nagios / Icinga / check_mk.
A real benefit for monit is it’s easy configuration and syntax. While you have to dig through a bunch of files in order to create a simple check in Nagios, monit allows you to simply put one (human readable) configuration file in the correct directory and the check is ready to use. In combination with a configuration management like Ansible (I’ve already created an article about Ansible a long time ago) you have an easy central to use monitoring tool with automatically distributed configuration files.
Installation of monit
Monit is available for most Linux distribution. With the following command you install monit on a Ubuntu / Debian machine:
user@machine:~$ sudo apt-get update && sudo apt-get install monit
Or if you’re an openSUSE user, you can install monit like this:
user@machine:~$ sudo zypper ref && sudo zypper in monit
That’s basically it. Compared to Nagios or Icinga, you don’t need an installed Apache web server. Monit comes with it’s own built-in web service. In order to check if monit is running, you can use systemctl to do so:
user@machine:~$ sudo systemctl status monit ● monit.service - LSB: service and resource monitoring daemon Loaded: loaded (/etc/init.d/monit; generated; vendor preset: enabled) Active: active (running) since Wed 2017-10-11 11:47:39 CEST; 3 months 13 days ago Docs: man:systemd-sysv-generator(8) Tasks: 2 (limit: 4915) CGroup: /system.slice/monit.service └─18228 /usr/bin/monit -c /etc/monit/monitrc Dez 26 06:25:02 machine systemd: Reloading LSB: service and resource monitoring daemon. Dez 26 06:25:02 machine monit: Reloading daemon monitor configuration: monit. Dez 26 06:25:02 machine systemd: Reloaded LSB: service and resource monitoring daemon. Jan 10 06:25:02 machine systemd: Reloading LSB: service and resource monitoring daemon. Jan 10 06:25:02 machine monit: Reloading daemon monitor configuration: monit. Jan 10 06:25:02 machine systemd: Reloaded LSB: service and resource monitoring daemon.
In order to start, stop or restart the service, use these following commands:
user@machine:~$ sudo systemctl start monit user@machine:~$ sudo systemctl stop monit user@machine:~$ sudo systemctl restart monit
Enable the monit built-in web server
If you’re an Debian / Ubuntu user, monit will store it’s main configuration under /etc/monit/monitrc. This files is really well documented. However, I want to give a short brief about how to enable the built-in web server which is one of the most important features.
The following block can be found (at the time of writing) at line 155:
# set httpd port 2812 and # use address localhost # only accept connection from localhost # allow localhost # allow localhost to connect to the server and # allow admin:monit # require user 'admin' with password 'monit
If you uncomment this section the built-in monit web server will be started and will listen on port 2812. The second line sets the network address where the web server instance is listening on. If it only listens on localhost you will not be able to connect from any other host. For e.g. if your server has an IP address of 192.168.0.2 you can replace localhost with this IP address here in order to get the monit built-in web server to listen on this network interface.
The third line regulates which other hosts are allowed to establish a connection to the web server. You can define single IP addresses or even whole subnets (like 192.168.1.0/24) here. Just like in the line before, simply replace localhost with the IP address or subnet you want to allow to connect to the web server.
The fourth line defines a user with a password which will be able to login. monit does not allow an anonymous login which is good from a security point of view obviously. In this example the username would be admin with the password monit.
When you’re done setting these lines, restart the monit service:
user@machine:~$ sudo systemctl restart monit
Besides using the web interface, you can also check your services on the command line. However, to do so you also need the web interface to be enabled because the command line simply gets an HTTP output and process it. To get a summary of all your monitored processes you can enter the following command:
user@machine:~$ sudo monit status
Enable mail notifications
Nagios or Icinga is able to send you a mail every time when a host or a service of this host went down. monit also offers this feature. In order to enable mail notifications, you have to open once more the monitrc file (which can be found in /etc/monit/) and search for the following lines:
## Set the list of mail servers for alert delivery. Multiple servers may be ## specified using a comma separator. If the first mail server fails, Monit # will use the second mail server in the list and so on. By default Monit uses # port 25 - it is possible to override this with the PORT option. # # set mailserver mail.bar.baz, # primary mailserver # backup.bar.baz port 10025, # backup mailserver on port 10025 # localhost # fallback rela
As you can see, you can set multiple mail servers which monit should try to connect each time a notification is about to be send. The downside here is that monit does not support authentication for mail servers. This basically means that you can’t just enter public mail servers like GMail. If you want to use those service you have to have a local mail server setup. This mail server could be configured as a satellite / client to keep it more simple. If you’re mail server is up and running, you can simply set the mail server in the monitrc file like this:
set mailserver localhost
If you have access to a mail server which doesn’t require authentication, you can replace localhost with this mail server of course.
Now that you’ve set the mail server, you also have to enter the recipient for the notification mails. Search for the following line in the monitrc file:
# set alert email@example.com # receive all alerts
Uncomment this line and replace firstname.lastname@example.org with the recipient of your choice. You can also define which kind of notification are going to be send to this mail address. However, this is more advanced configuration which would burst this articles length.
When everything set, restart monit and you will now get a mail each time a service status changes:
user@machine:~$ sudo systemctl restart monit
Some examples for monitoring services
In order to monitor services, a new file has to be created under the subdirectory /etc/monit/monitrc.d/ on Ubuntu / Debian. The name of this file should be the same as the service which is going to be monitored. The following examples are showing how to monitor services, programs and system resources with monit:
- Monitoring a running program / service or service without a PID file:
check process TeamSpeak matching "ts3"
In this example we simple check if a process called “ts3” is running on the machine. You can use ps ax on the command line by yourself on the target machine to see if the process is running. That’s basically what monit is doing. The name of this check is TeamSpeak as seen in the first line. You can change this to whatever you want.
- Monitoring a program / service with a PID file:
check process mysqld with pidfile /var/run/mysqld/mysqld.pid start program = "systemctl start mysql" stop program = "systemctl stop mysql" if failed host localhost port 3306 protocol mysql with timeout 15 seconds for 3 times within 4 cycles then restart if failed unixsocket /var/run/mysqld/mysqld.sock protocol mysql for 3 times within 4 cycles then restart if 5 restarts with 5 cycles then alert
In this specific example we monitor a MySQL instance installed on the system. If the service crashes, monit tries three times within four cycles to restart the service. For this restart monit uses the two defined commands which are defined in start program and stop program. In this case monit checks the unixsocket as well as a network connection to get in touch with MySQL before it trys to restart the service.
If after four cycles (which includes restarting the service after each cycle in this case) the service is still unreachable for monit, monit runs into the fifth cycle. This last cycle is defined with “alert”. The administrator, which has been declared in the monitrc file, will get a mail. If there is another competent person defined for this specific service, this person will be mailed as well. The name of the service in this example is mysqld.
- Check for disk usage:
check device root with path / if SPACE usage > 90% then alert
With this check, we check the root file system. If the used space in percentage is over 90, monit will send out an alert via mail. It would also be possible to check against the used inodes of a partition as well. If you have more than just one partition, you have to create a check for each partition of want to monitor.
- Check for ram, swap and CPU usage:
check system my.machine.fqdn if memory usage > 90% then alert if cpu usage > 90% for 4 cycles then alert if swap usage > 95% for 4 cycles then alert
In this example we check the memory, CPU and swap usage by the system. This example is similar to the disk usage. If the memory usage is higher than 90% of the overall memory of this system, monit will send out an alert. If the CPU usage is over 90% for four cycles, monit will send an alert as well. The four cycles ensure that monit is not starting to report every little peak a CPU has. Same goes to SWAP. If 95% of the overall SWAP is used, monit will report this when this has happened four times / cycles in a row. In the first line you would have to change my.machine.fqdn to the real FQDN your system has.
- Check an external host (ping):
check host other.host.fqdn with address other.host.fqdn if failed icmp type echo count 3 with timeout 5 seconds 2 times within 3 cycles then alert
With this check, monit tries to ping the specified other.host.fqdn. With every ping command monit starts, it does three pings with a timeout of five seconds for each. If the ping fails two times within a three times cycle, monit sends out an alert that the host is unreachable / offline. In order to get this command up and running, you have to change other.host.fqdn to the desired host which you want to check.
For every check you change, add or remove, you have to restart the monit service:
user@machine:~$ sudo systemctl restart monit
After you have done this, you can see the status of the services with the help of the web interface or with the command line:
user@machine:~$ sudo monit status
If you want to get the status of one single check, you can append the name of the check at the end of the status command. The name you have to use is the one you defined within the configuration file for this check. For e.g. to get the status of the first check TeamSpeak we’ve configured in these examples:
user@machine:~$ sudo monit status TeamSpeak
mmonit: If you need a central web instance
So while monit offers a web interface which you could use in order to get an overview about the actual checked services, I understand than literally nobody wants to connect to each single monit web instance if you have 30 hosts or more.
Now, what you could do is to write a wrapper script (with bash, Python, etc.) which helps you to get the actual status of all services on all hosts. However, a more comfortable and easier solution is to use mmonit. mmonit is written by the official monit developers and gathers all information from each single monit instance and is showing the collected data on one single page.
Sadly, mmonit isn’t free. You can grab a 30 day trial if you want to, but at the end you have to pay a small one time fee in order to use the software. The prices are starting as low as 65 € for 5 hosts and is dropping sharply as more hosts you’re using. With 50 hosts you also get support for just 349 €. Again, this is a one-time pay license. There are no more additional costs coming up. If you compare this to other solutions like check_mk, mmonit is really cheap.
Sadly, I’m unable to tell you more about mmonit for now. I wasn’t in the need to have to use it for now as my own wrapper script is doing more than just fine for the +30 hosts I monitor with monit. But maybe the future will pushes me to get a mmonit license 😉
Is monit a full replacement for Nagios or Icinga? I’m unable to say if monit really fits into server farms with more than 100 servers, but if you want to have a easy monitoring solution which works with scripts (and Nagios plugins if you configure your checks correctly), you will be most likely happy with monit.
I’ve seen some talks recently on StackOverflow about monit and while a lot of people are saying that they wouldn’t use monit in bigger clusters, they use it on certain spots. For e.g. somebody talked about a customer with round about 20 servers. He rolled out monit there because of the fast and easy configuration. In order to check all 20 hosts at once, he created a bash script which connects via SSH and Public Key authentication to each host and issues the command monit status. In order to keep track if the host is still accessible from outside he just pings from another host with a ping check configured on another monit instance.
As you can see, even if monit looks like it’s limited or “not as powerful as Nagios”, there are no borders. A lot of people use and love monit due to it’s easy configuration and flexibility. If you’re looking for a monitoring solution or for an Nagios / Icinga alternative, you should give monit a try.
Last hint: If you want to monitor a single server (for e.g. home server or a Raspberry Pi) monit is would you should look up before Nagios or Icinga IMHO. In a setup like this, monit is definitely about to shine.