Nagios Core Configuration

Preface

The configuration of Nagios Core is maintained in several files. In the case that you are from old UX/Linux school you will get familiar with this kind of application configuration really fast.

Files based configuration is providing great integration possibility of Nagios Core with another tools.

In this document I will try to provide you a global overview of the way how Nagios Core is configured. At one document it is not possible to describe all the possibilities provides at Nagios Core. According to this I’ll describe it in details later in documents that will focus on particular subject.

Before we’ll start

I would like to present you a nice (high level) scenario why and how to use the Nagios Core:

Probably each IT department is using some kind of CMDB (CMDB is not an excel on SharePoint) for storing information related to the IT infrastructure. In the case that the CMDB is flexible enough, it shall be possible to create object related to monitoring tools. In this way all components of IT infrastructure that need to be monitored can be linked to the monitoring object at CMDB. This shell provide us the possibility to run scheduled script that will dump all relevant data from CMDB and automatically configure Nagios Core.

It can look really difficult to implement this kind of integration. To be honest I need to say that if you know what you are looking for and you understand the way how Nagios Core is working and how to get the data it is not so difficult.

To summarize the example based on common economical way:
- Capex (Capital Expenditure) – Is increasing as the integration need to be developed and configured
- Opex (Operational expenditure) – Is decreasing as the integration is able to do routine tasks for us without human interruption. On another hand it is not zero as it is a technology and it will still require some maintenance.


According to this in the case that you are going to maintain large environment it is in long term highly beneficial for you to use some kind of integration.

NagiosXI

In the case that you are using NagiosXI and you would like to use information from this document it is required to understand the differences between Nagios Core and NagiosXI monitoring instance.

NagiosXI is commercial version of Nagios project. It is build up on top of Nagios Core, including several additional components.

In the case that you will go deeper in to NagiosXI you will see that:
- Monitoring is done at Nagios Core.
- It is including as well Nagios Plugins.
- Nagios Core is using MySQL database as backend.
- NgiosQL is used for configuration management (as web interface).
- PostgeSQL is used to store user accounts.
- ….

In the case that you are going to do some configuration change at NagiosXI it is common to use the web browser, as this will happen:

User → configuration change at NagiosQL → Update of MySQL database for NagiosQL → Export of the change in to file → Reload of Nagios Core → Update of MySQL database for Nagios Core

1.) You will log in to web GUI. In default configuration your account is stored at PostgeSQL database. In this case you are not accessing directly the web GUI of Nagios Core but only the web interface of NagiosQL.
2.) After logging in to NagiosXI Web GUI it is possible to do configuration change of monitoring (for example to add or remove a host).
3.) After you have committed the change it will be saved in to MySQL database instance used at NagiosQL.
4.) To take effect of changed data, it is required to export this information in to standard configuration file used at Nagios Core. According to this mentioned data will be exported in to file.
5.) Nagios Core will reload the configuration based on the updated configuration files.
6.) The information in MySQL database instance used at Nagios Core as backend will be updated.

According to the described way how the NagiosXI is working it is possible to use all information mentioned in this document.

To keep the integrity of NagiosXI components in the case that you’ll upload file based configuration. It is required to update NagiosQL instead of Nagios Core.

As NagiosXI is out of scope of this document I would propose to you to check the official documentation:
http://assets.nagios.com/downloads/nagiosxi/docs/Importing-Core-Configuration-Files-Into-Nagios-XI.pdf
http://assets.nagios.com/downloads/nagiosxi/docs/Using_The_XI_ Config_Import_Prep_Tool.pdf_old

Main config. file "nagios.cfg"

The main configuration file of Nagios Core is called “nagios.cfg”. In the case that you have followed steps mentioned at installation of the Nagios Core document at this web page it is located at “/opt/nagios-<VERSION>/etc/nagios.cfg” .

Mentioned configuration file will be used at start of Nagios Core demon. It is including the configuration of Nagios Core, as well it is possible to define additional files that can provide particular configuration used at Nagios Core.

According to this it is common to split the configuration across several files. It is possible to create file system hierarchy that will provide the possibility to logical grouping of the configuration objects.

In the case that you are going to do any configuration change.

Please:
- Backup the file before you will change it. In case that you will need to do roleback it really hand.
- After you has done the change validate the configuration integrity with:

# /opt/nagios-<VERSION>/bin/nagios -v /opt/nagios-<VERSION>/etc/nagios.cfg                   # -v is for Validation
.
.
.
Total Warnings: 0                                                                            # you'll get this!!!
Total Errors:   0

Things look okay - No serious problems were detected during the pre-flight check

Configuration Objects

It is possible to split Nagios Core configuration across several files. It is possible to say that the smallest entity that can be included in one configuration file is definition of an Object.

Nagios Core is able to handle several Configuration Object types. Each object type has his specific purpose and definition (of values that it need to include).

It is possible to define Configuration Object with including another Configuration Object. In this way it is possible to build the relation between objects.

We can say that Nagios Core is using Object based configuration, as almost anything need to be defined as an object. On another hand it is really handy, as it is preventing duplicity of configuration and providing some kind of central management of the values.

General example of Object configuration:

define object-type {
        Parameter    value
        Parameter    value
        …
}

host

Host object definition need to include information related to the monitored node. Probably the most important are IP and FQDN of the monitored node.

At host object definition it is possible to specify as well command that will be used for host up/down monitoring. Usual for this purpose standard ping monitoring is used (if the node is not reachable, polling of the related service will be skipped)

hostgrop

Hostgroup object definition is including several:
- Hosts
- Another Host Groups

In this way it is possible to create logical grouping of hosts. All nodes related to one hostgroup object will be presented at Web GUI as members of this hostgroup.

It is possible to include command in to hostgroup object definition. According to this, it is possible to define same monitoring for all hosts includes at hostgroup definition.

hostdependency

Hostdependency object is used to define relation between several hosts to prevent flooding of the support team with temporary alarms.

Example:

It is possible to configure dependency between several routes on the network path. In the case that the one router will be down it is pointless to report that the whole infrastructure behind this router is unreachable.

According to this:
- it is time saving to report the root cause (issue related to the router that is down)
- instead of the temporary issue (related to the unreachable infrastructure)

I know that this is not the best example as it is common to use redundant network paths. On another hand it’s only use case example

hostescalation

Hostescalation object is used to configure automated escalation for some issue.

Example 1:

In the case that Nagios Core has detected an issue it will send notification to 1st level support team. In the case that the issue is persistent for longer time Nagios Core is able to send “escalation” message to 2nd level support team or to Manager responsible for escalations.

To be honest I’m not sure if described process can help to anyone. In the case that 1st level and 2nd level team do not know about each other and they do not share information related to this issues. The 2nd level team will need to do same investigation as the 1st level team has already done. According to this please prevent this scenario.

Example 2:

In the case that Nagios Core has detected an issue it will start script that will try to fix the issue. In the case that the issue is persistent for longer time Nagios Core is able to send “escalation” message to 1st level support team.

In this case Nagios Core will try to fix the issue. In the case that the issue will be still present for longer time it will send a notification to support team. This an nice example where it is possible to use mentioned configuration object

service

Service object configuration is including monitoring configuration of particular service related to host. It is possible to configure more as one service with same name until each of them is related to another host. Each service need to belong to a host.

servicegroup

Servicegroup object is including more:
- Services objects.
- Servicegroup objects

Service grouped in to one servicegroup object will be present together at one service group as well at Web GUI. This can be used for logical grouping of the objects.

servicedependency

Servicedependency object is used to define relation between several services to prevent flooding of the support team with alarms.

Example:

It is possible to configure dependency between database and application. In the case that the database will be down it is pointless to report as well that the application is not working.

According to this:
- it is time saving to report the root cause (database issue)
- instead of the temporary issue (related to the application)

serviceescalation

Serviceescalation object is used to configure automated escalation for some issue.

Example 1:

In the case that Nagios Core has detected an issue it will send notification to 1st level support team. In the case that the issue is persistent for longer time Nagios Core is able to send “escalation” message to 2nd level support team or to Manager responsible for escalations.

To be honest I’m not sure if described process can help to anyone. In the case that 1st level and 2nd level team do not know about each other and they do not share information related to this issues. The 2nd level team will need to do same investigation as the 1st level team has already done. According to this please prevent this scenario.

Example 2:

In the case that Nagios Core has detected an issue it will start script that will try to fix the issue. In the case that the issue is persistent for longer time Nagios Core is able to send “escalation” message to 1st level support team.

In this case Nagios Core will try to fix the issue. In the case that the issue will be still present for longer time it will send a notification to support team. This an nice example where it is possible to use mentioned configuration object

command

Command object is used to integrate external scripts in to Nagios Core. In this way are integrated all monitoring scripts in to Nagios Core.

contact

Contact object is used as definition of Nagios Core user. It is used in multi-tenant configuration of Nagios Core it is possible to specify who is allowed to see particular object at Web GUI

contactgroup

Contactgroup object is used as definition of group for multiple:
- Contsct objects.
- Contactgroup objects.

It is used at:
- In multi-tenant configuration of Nagios Core it is possible to specify who is allowed to see particular object at Web GUI
- It is possible to use it in event notification process.
- It is possible to use it in escalation process.

timeperiod

Timeperiod object is used to define time slots. Based on service level agreement (SLA) it is sometime required to customize the monitoring of the infrastructure.

As an example I will take standard office, where out of working hours the printer is turned off. In standard 24/7 monitoring model it would be reason for plenty of alarms. According to this it is possible to specify time slots, when it is need to monitor mentioned printer to prevent false positive alarms.

CGI configuration "cgi.cfg"

In the “cgi.cfg” configuration file it is possible to configure parameters related to Web GUI and CGI scripts. In most case you will not really need to change it. On another hand in the case that you would like to play with your Nagios Core web interface here are the configuration parameters.

In the case that you have followed steps mentioned at installation of the Nagios Core document at this web page it is located at “/opt/nagios-<VERSION>/etc/cgi.cfg”.

Resource configuration "resource.cfg"

The “resource.cfg” configuration file is including all paths (on file system) that are used at Nagios Core. It is possible to define 32 different paths.

In the case that you have followed steps mentioned at installation of the Nagios Core document at this web page it is located at “/opt/nagios-<VERSION>/etc/resource.cfg”.

Example:

# grep -v -e "^$" -e "^#" /opt/nagios-4.0.7/etc/resource.cfg
$USER1$=/opt/nagios-4.0.7/libexec                                        # Path to monitoring scripts used at Nagios Core

URL's

Navigation
Print/export
QR Code
QR Code wiki:infrastructure_tools:nagios:nagios_core_configuration (generated for current page)