Table of Contents
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)
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.
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.
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.
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.
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
Main URL for Nagios Core 3 documentation: http://nagios.sourceforge.net/docs/nagioscore/3/en/toc.html
Main URL for Nagios Core 4 documentation: http://nagios.sourceforge.net/docs/nagioscore/4/en/toc.html
NagiosXI related documents (related to importing of configuration files)
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