The base Nagios / Icinga installation uses files for all configuration and data storage. When the service starts, it reads the configuration from .cfg files listed in the Main Configuration File paths. Once the service has read and processed the configuration, it begins to collect and process data, with the results output to log files. Everything is file-based and the administrator may read the log files with a text editor or process them using log file analysis.
Nagios – Broker Module – Database Integration
Log files work well for small installations. However, they are too slow for large installations; they are not even used for more complex add-ons such as advanced web-based interfaces, visualizations and web-based graphical configuration tools. Scalable and utilitarian deployments require database integration.
Database integration is not limited to the Nagios / Icinga service. One example is the Icinga-Web advanced interface (as opposed to the Classic Icinga interface). Icinga-Web stores its configuration data in a database – named icinga_web on Debian Wheezy – and maintains data there. A second example is the NConf Nagios / Icinga configuration web-based configuration tool. NConf stores configuration information in its own database and outputs Nagios- / Icinga-compatible .cfg files that may be deployed to a server. These databases and tools may be deployed without integrating the Nagios / Icinga service with a database.
Database integration with the Nagios / Icinga process provides the previously stated scalability and utilitarian capabilities. The NagVis visualization package (to be discussed in another article) requires this integration. Thus, the administrator should enable it early in the installation and configuration process.
First, a simplified description of how these processes work is warranted. As previously described, the base Nagios / Icinga services read and write all configurations and output data to files. When integrated with a database, Nagios / Icinga still read the initial configuration information from .cfg files,just as before. However, output is no longer sent to files. The Main Configuration file specifies a broker module to output the data to the database. However, data is also protected from loss due database connection problems by first sending it to a temporary storage file. If the database is unavailable or a remote collector server can not reach the database server, the information is held locally until the connection is restored. The database contains all of the configuration information in tables and this is linked to output results tables. Keep in mind Nagios and Icinga do not use the database for startup configurations – this is still maintained in .cfg files – but that information is stored in the database to provide relations to the results.
Integrating with a database requires installing packages – ndoutils for Nagios and idoutils for Icinga. At installation, these packages create the requisite databases (ndoutils for Nagios and Icinga for Icinga) and provide the necessary modules. However, they are not enabled. The administrator must edit the Main Configuration file to enable database services. Once restarted, the broker module sends the configuration and output results information to the database.
The video below demonstrates and illustrates the process. In it:
- Commence with a base Icinga installation
- Illustrate the default MySQL Databases
- Install the Icinga idoutils and Icinga-Web advanced web interface packages
- Illustrate the MySQL database additions.
- Modify the /etc/default/icinga configuration file and copy the broker module from /usr/share/doc/icinga-idoutils/examples/idoutils.cfg-sample to /etc/icinga/modules/idoutils.cfg to enable the database broker module
- Restart Icinga
- Illustrate the host table database changes upon enabling idoutils
- Install configuration files defining 11 hosts and 250+ services
- Illustrate the host table database changes
No comments :
Post a Comment