The Midnight Nightmare: When Your Server “Passes Out”
Imagine this: it’s 3 AM, and your phone is vibrating uncontrollably. The website is down, and customers are calling non-stop. You groggily crawl out of bed, open your laptop, and SSH into the server just to type one single command: systemctl restart nginx. Everything is back online, but your sleep is gone.
Why do manually what a computer can handle in 5 seconds? While Prometheus or Zabbix are powerful for graphing and metrics collection, they tend to be more about post-mortem analysis. Monit is different. It’s like a security guard stationed right at the gate. If a service “faints,” it immediately performs CPR (restarts it) to bring it back to life instantly.
Monit’s biggest selling point is its footprint. It consumes less than 2MB of RAM and almost zero CPU, making it perfect even for the weakest VPS.
Deploying Monit in 5 Minutes
Here are the steps to get this “gatekeeper” running on Ubuntu/Debian or CentOS/RHEL.
1. Installation
# For Ubuntu/Debian
sudo apt update && sudo apt install monit -y
# For CentOS/RHEL
sudo yum install epel-release -y
sudo yum install monit -y2. Enable the Web Interface
The web interface allows you to monitor status quickly without typing commands. Open the configuration file /etc/monit/monitrc (Ubuntu) or /etc/monitrc (CentOS) and uncomment the following lines:
set httpd port 2812 and
use address 0.0.0.0 # Allow access from outside
allow admin:monit # You should change this user/pass immediately3. Activate the Service
sudo systemctl enable --now monit
# Check if Monit is alive
sudo monit statusWhy does Monit “Outclass” Systemd?
Many ask: “Systemd already has Restart=always, so why bother installing Monit?”.
In reality, Systemd only knows how to restart when a process completely disappears. Monit is smarter. It can check the actual health status of a service. For example, Nginx might still be running (the process exists) but is returning a 502 error or consuming 90% of the RAM. Systemd will just stand by, but Monit will intervene immediately based on your defined conditions.
From my personal experience: When managing a cluster of 20 servers, Monit acts as the first line of defense. It handles 90% of minor issues like RAM spikes or frozen services. Only when Monit fails to save the day do I need to receive a Telegram alert for manual intervention.
Configuring Monitoring for Essential Services
Don’t write everything in the main file. Create separate files in /etc/monit/conf-enabled/ for easier management.
Monitoring Nginx (Web Server)
Create the file /etc/monit/conf-enabled/nginx:
check process nginx with pidfile /run/nginx.pid
start program = "/usr/bin/systemctl start nginx"
stop program = "/usr/bin/systemctl stop nginx"
if failed port 80 protocol http then restart
if failed port 443 protocol https then restart
if 3 restarts within 5 cycles then alertThis script checks ports 80 and 443. If Nginx doesn’t respond correctly via HTTP/HTTPS protocols, Monit automatically restarts it. If it fails after 3 restarts within 5 cycles, it stops and sends you an alert.
Monitoring MySQL/MariaDB
check process mysql with pidfile /var/run/mysqld/mysqld.pid
if failed host 127.0.0.1 port 3306 protocol mysql then restart
if cpu usage > 80% for 5 cycles then alertMonitoring System Resources
Monit can even keep an eye on your virtualized hardware:
check system $HOST
if loadavg (1min) > 4 then alert
if memory usage > 85% then alert
check filesystem rootfs with path /
if space usage > 90% then alertAutomated Troubleshooting with Custom Scripts
This is a fantastic feature. Suppose an application’s log file grows too fast and fills up the disk. You can have Monit automatically run a cleanup script:
check file app_log with path /var/log/myapp.log
if size > 1 GB then exec "/usr/local/bin/cleanup_logs.sh"Vital Notes for Deployment
- Avoid cycles that are too short: By default, Monit checks every 2 minutes (
set daemon 120). Don’t set it to 5 seconds, as this can cause “false positives” if a service hasn’t finished starting up. - Always check syntax: Before reloading, run
sudo monit -t. A small error in the config file can take down the entire monitoring system. - Use M/Monit for multiple servers: If you manage more than 5 servers, consider using M/Monit to aggregate everything into a centralized dashboard.
Monit isn’t a replacement for in-depth monitoring systems. It is the final layer of insurance, sitting locally on the server and silently fixing issues. If you want a “set it and forget it” solution to keep your server healthy, Monit is the top choice.
