Example Configurations
Prev | Chapter 3. Examples | Next

## Example Configurations

### Single Server, Single Instance Setup

The easiest configuration occurs when you have a single Nagios instance running on your network. In this case, installing and configuring the various components of the NODUTILS addon is fairly straightforward.

The following diagram illustrates how the various components can fit together in a single server, single Nagios instance setup....

Figure 3.1. Single Server, Single Instance Setup

Here's a description of what's happening at each point in the diagram:

1. The NDOMOD module is configured with an instance name of "default" since there is only one instance of Nagios that is running on the network.

2. While the Nagios daemon is running and performing its usual business of monitoring the network, the NDOMOD module is sending configuration data and event information to the TCP or Unix domain socket that was created by the NDO2DB daemon.

3. The NDO2DB daemon reads data that is coming into the socket from the NDOMOD module.

4. The NDO2DB daemon processes and transforms data that has been received from the NDOMOD module.

5. The processed data is stored in a database for later retrieval and processing.

This example assumes that:

1. Nagios is configured to load the NDOMOD module at startup.

2. The NDO2DB daemon (which is a separate process from the Nagios daemon) is running.

### Single Server, Multiple Instance Setup

Another simple configuration can be used when you have a multiple Nagios instances running on a single server. Installing and configuring the various components of the NODUTILS addon is similar as to what was shown in the previous example.

The following diagram illustrates how the various components can fit together in a single server, multiple Nagios instance setup....

Figure 3.2. Single Server, Multiple Instance Setup

You'll notice that the diagram above is similar to the one for the single-server, single instance configuration. The main difference is that there are now three (3) different Nagios daemons instead of just one.

1. Each Nagios daemon loads the NODMOD module at startup with a unique instance name. In this example the instances are simply named "nagios1", "nagios2" and "nagios3".

2. Each NDOMOD module sends configuration data and event information for its specific instance of the Nagios daemon to the TCP or Unix domain socket that was created by the NDO2DB daemon.

3. The NDO2DB daemon reads data that is coming into the socket from the three NDOMOD modules.

4. The NDO2DB daemon processes and transforms data that has been received from the NDOMOD modules.

5. The processed data is stored in a database for later retrieval and processing. Data from each instance of Nagios is kept separate (using the instance names as unique identifiers) in the database.

### Single Server, Single Instance Log File Import

There are two reasons you'll probably want to import your Nagios log files into the same database that Nagios configuration and event data is stored in:

1. Historical log file data isn't imported into the database by default and having a record of events that occurred before you implemented the NDOUTILS addon is probably desireable.

2. The NDOMOD module is not able to process realtime log entries from the time right after the Nagios daemon starts to the time that the NDOMOD module is loaded by the Nagios daemon. This "blackout period" is unavoidable and causing log entries such as "Nagios 2.0 starting..." to be missed by the NDOMOD module. Thus, importing day-old Nagios log files on a daily basis (via a cron job) is recommended.

Figure 3.3. Single Server, Single Instance Log File Import

Here's a description of what's happening at each point in the diagram:

1. Historical Nagios log files are read by the LOG2NDO utility.

2. The LOG2NDO utility processes the contents of the log files and tags them with an instance name of "default". This instance name must match the same instance name used by the NDOMOD module in the Nagios daemon.

3. Historical log file data is sent to the TCP or Unix domain socket in a format that the NDO2DB daemon can understand.

4. The NDO2DB daemon reads the log file data from the Unix domain socket.

5. The NDO2DB daemon processes the log file data.

6. Historical log file data is stored in a database for later retrieval and processing. The NDO2DB daemon will perform some checks to make sure it doesn't re-import duplicate historical log entries, so running the LOG2NDO utility on the same historical log file multiple times shouldn't have any negative side effects.

That's it! Pretty simple.

Prev | Up | Next
Chapter 3. Examples | Home | Chapter 4. Installation

© 2009 Nagios Development Team, http://www.nagios.org