Nagios Monitoring for Servers

By Kokil Thapa | Last reviewed: August 2026

Nagios monitoring for servers remains the industry-standard approach for teams needing transparent, self-hosted infrastructure observability without recurring SaaS fees. While modern observability platforms offer convenience, many Nepal-based businesses and global SMEs still require direct control over their monitoring stack due to budget constraints or data sovereignty requirements. This guide covers the practical reality of deploying and maintaining Nagios Core on Ubuntu 24.04 LTS in 2026, focusing on configuration patterns that actually survive production use.

How do you install Nagios Core on Ubuntu 24.04 for server monitoring?

Installing Nagios Core from source on Ubuntu 24.04 LTS provides the latest stable release (4.5.x series) and avoids outdated repository packages. Before starting, ensure your server has at least 2GB RAM and PHP 8.2+ installed, as the web interface depends on it. For teams managing server security in Nepal, always run Nagios on a dedicated management host isolated from public-facing application servers.

Prerequisites and dependency installation

Nagios Core compiles against Apache, PHP, and several development libraries. Install all build dependencies in one command to avoid mid-build failures:

sudo apt update && sudo apt upgrade -y
sudo apt install -y apache2 php8.2 libapache2-mod-php8.2 \
    php8.2-gd php8.2-mysql php8.2-xml php8.2-mbstring \
    build-essential libgd-dev openssl libssl-dev \
    unzip wget curl autoconf automake pkg-config

Create the nagios user and group before compiling. The web interface also requires membership in the nagcmd group for external command execution:

sudo useradd -m -s /bin/bash nagios
sudo groupadd nagcmd
sudo usermod -a -G nagcmd nagios
sudo usermod -a -G nagcmd www-data

Compiling and installing Nagios Core 4.5

Download the latest verified tarball from the official GitHub releases page. Never compile from unverified mirrors. As of mid-2026, version 4.5.9 is the current stable release:

cd /tmp
wget https://github.com/NagiosEnterprises/nagioscore/releases/download/nagios-4.5.9/nagios-4.5.9.tar.gz
tar xzf nagios-4.5.9.tar.gz
cd nagios-4.5.9

./configure --with-httpd-conf=/etc/apache2/sites-available
make all
sudo make install
sudo make install-init
sudo make install-commandmode
sudo make install-config
sudo make install-webconf

The install-config step places sample configurations in /usr/local/nagios/etc/. These are templates only — never deploy them unmodified to production. Enable the Apache site and restart services:

sudo a2ensite nagios.conf
sudo systemctl enable apache2 nagios
sudo systemctl restart apache2 nagios

Verifying the installation

Confirm Nagios started correctly and the web interface responds. Check for configuration errors before trusting any output:

sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
sudo systemctl status nagios
curl -u nagiosadmin:YOUR_PASSWORD http://localhost/nagios/cgi-bin/status.cgi

If the verification step reports warnings about deprecated directives, address them immediately. Nagios 4.5 removed several legacy options that older tutorials still reference silently.

How do you configure host and service checks in Nagios?

Nagios uses flat-file configuration organized by object type. The most common mistake I've seen on client projects is putting everything in nagios.cfg directly. Instead, create separate directories for hosts, services, contacts, and commands. Edit /usr/local/nagios/etc/nagios.cfg to include these paths:

cfg_dir=/usr/local/nagios/etc/hosts
cfg_dir=/usr/local/nagios/etc/services
cfg_dir=/usr/local/nagios/etc/contacts
cfg_dir=/usr/local/nagios/etc/commands

Defining monitored hosts

Create a host definition for each server. Use templates to reduce repetition across similar machines. Here's a production-ready template for Laravel application servers running on Ubuntu 24.04:

# /usr/local/nagios/etc/hosts/templates.cfg
define host {
    name                    linux-app-server
    use                     generic-host
    check_period            24x7
    check_interval          5
    retry_interval          1
    max_check_attempts      3
    notification_period     24x7
    notification_options    d,u,r
    contact_groups          admins
    register                0
}

# /usr/local/nagios/etc/hosts/prod-laravel-01.cfg
define host {
    use                     linux-app-server
    host_name               prod-laravel-01
    alias                   Production Laravel App Server
    address                 192.168.10.21
    hostgroups              laravel-apps, production
}

The max_check_attempts directive prevents false positives during brief network hiccups. Setting it to 3 means Nagios must see three consecutive failures before marking the host DOWN. On unreliable networks common in some Nepal regions, increasing this to 4 or 5 reduces alert fatigue significantly.

Configuring service checks with realistic thresholds

Service definitions specify what to monitor on each host. Avoid using default warning/critical thresholds blindly — they rarely match real workload characteristics. For a WooCommerce store handling 200 concurrent users, disk space warnings at 80% may be too aggressive if nightly backups temporarily consume space:

# /usr/local/nagios/etc/services/prod-laravel-01-services.cfg
define service {
    use                     generic-service
    host_name               prod-laravel-01
    service_description     Root Disk Space
    check_command           check_local_disk!20%!10%!/
    check_interval          10
    retry_interval          2
}

define service {
    use                     generic-service
    host_name               prod-laravel-01
    service_description     PHP-FPM Process Count
    check_command           check_nrpe!check_procs_php_fpm
    check_interval          2
    retry_interval          1
    max_check_attempts      4
}

Custom NRPE commands belong in /etc/nagios/nrpe.cfg on the remote host. Define meaningful thresholds there rather than hardcoding values in the Nagios server config. This keeps tuning localized to the machine being monitored.

What are the essential Nagios plugins for production server monitoring?

The official Nagios Plugins package covers basics, but production environments need additional checks tailored to actual workloads. Install the standard set first, then add specialized plugins as needed:

cd /tmp
wget https://nagios-plugins.org/download/nagios-plugins-2.4.12.tar.gz
tar xzf nagios-plugins-2.4.12.tar.gz
cd nagios-plugins-2.4.12
./configure --with-nagios-user=nagios --with-nagios-group=nagios
make && sudo make install

Critical plugins beyond basic ping and disk

• check_mysql_query: Validates database responsiveness by executing a lightweight SELECT. More reliable than TCP port checks for detecting locked tables or connection pool exhaustion on Laravel applications.
• check_http with regex: Confirms application responses contain expected content, not just HTTP 200 status. Catches blank pages from PHP fatal errors that return success codes.
• check_cert_expiry: Monitors SSL certificate expiration. Let's Encrypt renewals occasionally fail silently; catching expiry 14 days early prevents outages.
• check_systemd_service: Verifies systemd units are active and not in failed state. Essential for PHP-FPM, Nginx, Redis, and queue workers.
• check_queue_length: Custom plugin for Laravel/Symfony queue backlogs. A growing queue often indicates worker crashes before users notice delayed emails or processing.

Writing custom plugins safely

Custom plugins must follow the Nagios plugin API contract exactly: exit 0 for OK, 1 for WARNING, 2 for CRITICAL, 3 for UNKNOWN. Always output human-readable text after the pipe character for performance data parsing. Here's a minimal bash plugin checking Laravel queue backlog:

#!/bin/bash
# check_laravel_queue.sh
QUEUE_COUNT=$(php /var/www/app/artisan queue:monitor --format=json | jq '.pending')
WARN_THRESH=${1:-100}
CRIT_THRESH=${2:-500}

if [ "$QUEUE_COUNT" -ge "$CRIT_THRESH" ]; then
    echo "CRITICAL - Queue backlog: $QUEUE_COUNT jobs | pending=$QUEUE_COUNT;$WARN_THRESH;$CRIT_THRESH"
    exit 2
elif [ "$QUEUE_COUNT" -ge "$WARN_THRESH" ]; then
    echo "WARNING - Queue backlog: $QUEUE_COUNT jobs | pending=$QUEUE_COUNT;$WARN_THRESH;$CRIT_THRESH"
    exit 1
else
    echo "OK - Queue backlog: $QUEUE_COUNT jobs | pending=$QUEUE_COUNT;$WARN_THRESH;$CRIT_THRESH"
    exit 0
fi

Test every custom plugin manually before adding it to Nagios configuration. Run it as the nagios user to catch permission issues that won't appear when testing as root.

How does Nagios compare to Prometheus and Zabbix for server monitoring in 2026?

Choosing between monitoring systems depends heavily on team expertise, infrastructure scale, and operational preferences. Teams evaluating DevOps automation in Nepal should weigh these trade-offs carefully before committing to a platform.

Nagios wins when you have fewer than 50 servers, stable topology, and limited DevOps staff. Its configuration-as-code approach means version control works naturally. Prometheus excels for dynamic cloud environments where services appear and disappear frequently. Zabbix offers a middle ground with better auto-discovery than Nagios but lower resource overhead than full Prometheus stacks.

How do you maintain and troubleshoot Nagios in production?

Nagios deployments degrade silently without disciplined maintenance. Configuration drift, stale objects, and unchecked log growth cause more outages than software bugs. Budget-conscious teams exploring website maintenance costs in Nepal should factor monitoring upkeep into annual planning.

Routine maintenance checklist

1. Weekly configuration validation: Run nagios -v nagios.cfg after every change. Automate this in CI/CD pipelines if configs live in Git.
2. Monthly log rotation audit: Verify /usr/local/nagios/var/nagios.log rotates properly. Unrotated logs consume disk and slow CGI performance.
3. Quarterly threshold review: Compare alert frequency against actual incidents. Chronic warnings without action indicate misconfigured thresholds, not real problems.
4. Biannual plugin updates: Security patches for plugins arrive independently of Nagios Core. Subscribe to the nagios-plugins announce list.
5. Annual disaster recovery test: Restore Nagios from backup to a fresh VM. Documented procedures that haven't been tested are fiction.

Common production issues and fixes

Stale host states after restart: Nagios retains state in retention.dat. If this file corrupts, all hosts reset to PENDING. Back it up alongside configs. Enable retain_state_information=1 and use_retained_program_state=1 in nagios.cfg.

Slow web interface: CGI performance degrades with large status.dat files. Enable the NDOUtils broker module to offload status queries to MySQL. Alternatively, migrate read-heavy dashboards to Grafana connected via the Nagios API.

False critical alerts during maintenance: Use scheduled downtime windows via the web UI or API. Never disable checks entirely — this hides real failures occurring during the maintenance window.

NRPE connection refused: Usually firewall or allowed_hosts misconfiguration. Test connectivity with check_nrpe -H hostname from the Nagios server before editing nrpe.cfg. Remember that NRPE binds only to interfaces specified in its config.

Implementing Reliable Nagios Monitoring for Servers

Nagios monitoring for servers delivers predictable, auditable infrastructure visibility when configured with discipline. Start with core host and service checks, validate thresholds against real traffic patterns, and establish maintenance routines before scaling to hundreds of checks. The initial configuration investment pays dividends through reduced incident response time and eliminated surprise outages. If your team needs hands-on assistance setting up Nagios or migrating from an existing monitoring solution, reach out to discuss your infrastructure monitoring requirements.