Operations 18 min read

How to Use Nagios for Business-Level Service Monitoring: A Step-by-Step Guide

This article explains why traditional server and service monitoring (e.g., Zabbix) may miss business outages, then walks through setting up Nagios on Debian to monitor web page URLs, API health checks, and related services, including configuration files, plugins, and a desktop alert tool, Nagstamon.

Efficient Ops
Efficient Ops
Efficient Ops
How to Use Nagios for Business-Level Service Monitoring: A Step-by-Step Guide

Monitoring Considerations

Usually we deploy a monitoring system in the data center to watch servers and common services such as MySQL, set alert policies, and receive email or SMS when anomalies occur.

The monitoring focuses on two aspects:

Resource usage (CPU load, memory, disk space, etc.)

Service status (Nginx, MySQL replication, etc.)

Two main problems appear:

Lack of business‑level monitoring; servers and services may be healthy while the business is down.

Monitoring server and business servers share the same network environment, so network failures or congestion at the entry point may prevent alerts from reaching us.

How can we solve these problems?

Business‑level monitoring should directly reflect whether the business is normal or faulty. For a web project we first check the HTTP status of specific URLs (200 vs 404) and optionally verify that static resources and backend API responses are correct. In practice we assume static resources are served correctly by Nginx and focus on monitoring representative backend APIs.

We add a health‑check endpoint that queries all dependent services (MySQL, Redis, etc.) and returns a status, allowing a single check to cover the whole service chain.

Deploying the monitoring server in a different network segment (e.g., office network) mitigates the issue of alerts being blocked when the data‑center network fails.

Nagios Monitoring

We chose Nagios for its simple deployment and flexible configuration.

System environment: Debian 8

Architecture: nginx + Nagios

Deploy Nagios

1. Install basic packages

# apt-get update
# apt-get install -y build-essential libgd2-xpm-dev autoconf gcc libc6 make wget
# apt-get install -y nginx php5-fpm spawn-fcgi fcgiwrap

2. Download and extract Nagios

# wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.0.8.tar.gz
# tar -zxvf nagios-4.0.8.tar.gz
# cd nagios-4.0.8

# ./configure && make all

# make install-groups-users
# usermod -a -G nagios www-data

# make install
# make install-init
# make install-config
# make install-commandmode
# cd ..

After installing the core, the web interface cannot be accessed because the required plugins are missing.

3. Install Nagios plugins

# wget https://nagios-plugins.org/download/nagios-plugins-2.2.1.tar.gz
# tar -zxvf nagios-plugins-2.2.1.tar.gz
# cd nagios-plugins-2.2.1
# ./configure
# make
# make install
# cd ..

The plugins add commands such as

check_ping

and

check_http

, located in

/usr/local/nagios/libexec/

.

4. Create web‑access credentials

# vi /usr/local/bin/htpasswd.pl
#!/usr/bin/perl

use strict;

if ( @ARGV != 2 ){
    print "usage: /usr/local/bin/htpasswd.pl <username> <password>\n";
}
else {
    print $ARGV[0].":".crypt($ARGV[1],$ARGV[1])."\n";
}
# chmod +x /usr/local/bin/htpasswd.pl

# /usr/local/bin/htpasswd.pl nagiosadmin nagios@ops-coffee > /usr/local/nagios/htpasswd.users

The authentication configuration resides in

/usr/local/nagios/etc/cgi.cfg

. If an Apache httpd is present we could use

htpasswd

, otherwise we generate passwords with the Perl script.

5. Add an Nginx server block for Nagios

server {
    listen       80;
    server_name  ngs.domain.com;

    access_log /var/log/nginx/nagios.access.log;
    error_log /var/log/nginx/nagios.error.log;

    auth_basic "Private";
    auth_basic_user_file /usr/local/nagios/htpasswd.users;

    root /usr/local/nagios/share;
    index index.php index.html;

    location / {
        try_files $uri $uri/ index.php /nagios;
    }

    location /nagios {
        alias /usr/local/nagios/share;
    }

    location ~ \.php$ {
        include /etc/nginx/fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ ^/nagios/(.*\.php)$ {
        alias /usr/local/nagios/share/$1;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
    }

    location ~ \.cgi$ {
        root /usr/local/nagios/sbin/;
        rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;
        fastcgi_param AUTH_USER $remote_user;
        fastcgi_param REMOTE_USER $remote_user;
        include /etc/nginx/fastcgi_params;
        fastcgi_pass unix:/var/run/fcgiwrap.socket;
    }
}

6. Verify configuration and start services

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
# /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
# service fcgiwrap restart
# service php5-fpm restart

7. Access the Nagios web UI via the server IP or domain. Remove the default

localhost.cfg

service if not needed.

Nagios Configuration

The main configuration file is

/usr/local/nagios/etc/nagios.cfg

. Add a dedicated file for HTTP API checks, e.g.,

/usr/local/nagios/etc/objects/check_api.cfg

:

define service{
    use                     generic-service
    host_name               localhost
    service_description     web_project_01
    check_command           check_http!ops-coffee.cn -S
}

define service{
    use                     generic-service
    host_name               localhost
    service_description     web_project_02
    check_command           check_http!ops-coffee.cn -S -u / -e 200
}

define service{
    use                     generic-service
    host_name               localhost
    service_description     web_project_03
    check_command           check_http!ops-coffee.cn -S -u /action/health -k "sign:e5dhn"
}

Key directives:

define service

: defines a service; each page or API is a service.

use

: references a service template defined in

/usr/local/nagios/etc/objects/templates.cfg

.

host_name

: the host the service belongs to (here all are

localhost

).

service_description

: a human‑readable name shown in the UI.

check_command

: the command to run, defined in

/usr/local/nagios/etc/objects/commands.cfg

. For HTTPS checks add

-S

and ensure

libssl-dev

is installed.

The generic service template includes settings such as

max_check_attempts

,

check_interval

,

retry_interval

, and

contact_groups

(e.g.,

admins

).

Contact definition (e.g.,

admins

group) resides in

/usr/local/nagios/etc/objects/contacts.cfg

and specifies email and SMS notification commands.

After completing the configuration, restart Nagios to apply changes.

Nagstamon Plugin

Nagstamon is a desktop widget that monitors Nagios (and other systems) status, shows alerts in the system tray, and can emit sound notifications. Configuration options include the update interval (set to 1 s) and visual alert settings.

Conclusion

Business‑level monitoring complements process‑level tools like Zabbix but does not replace them.

Nagios was chosen for its focus on status monitoring and familiarity; despite many configuration files, the relationships are straightforward.

Deploying monitoring nodes in more locations improves coverage, but cost and network complexity must be balanced; commercial solutions may provide global nodes at higher expense.

monitoringopslinuxservice-monitoringnagiosBusiness Availability
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.