How to commit a Nagios configuration

Any change made within Nagios Monitoring is not effective and does not become part of your monitoring system production environment until the change is committed with the Commit option.

Pre flight test , Backup, Commit

Other components of the process include Pre flight test and Backup.

preflight commit

Pre flight test

Before performing a commit operation, your are advised to run a Pre flight test which will check the configuration for possible warnings and will not implement any changes into the Nagios configuration.

A Pre flight test checks to see if there are any warnings that you might want to fix before putting the whole setup into production.

No changes are made to the production setup when running a Pre flight test and any warnings or errors will be listed in the Nagios Pre flight test window.

  1. From the Configuration menu option, choose Nagios Monitoring > Control > Pre flight test.
  2. Select Continue to complete. 

    • Pre flight test data is stored in the directory: /usr/local/groundwork/monarch/workspace

Example workspace directory files:

user@demo:~/gw8$ docker-compose exec monarch bash
root@9d50a7b24cd7:/usr/local/groundwork/monarch/workspace# ls
cgi.cfg                escalation_templates.cfg             host_escalations.cfg  resource.cfg                      services.cfg
check_commands.cfg     extended_host_info.cfg               host_templates.cfg    service_dependencies.cfg          time_periods.cfg
config-current.log     extended_host_info_templates.cfg     hostgroups.cfg        service_dependency_templates.cfg
contact_groups.cfg     extended_service_info.cfg            hosts.cfg             service_escalations.cfg
contact_templates.cfg  extended_service_info_templates.cfg  misccommands.cfg      service_groups.cfg
contacts.cfg           host_dependencies.cfg                nagios.cfg            service_templates.cfg

Commit and backup operations

A Commit operation is used to update configuration changes to the Nagios configuration files which are stored in the /usr/local/nagios/etc directory. This operation will overwrite the active Nagios configuration and restart Nagios.

A Backup of the Nagios configuration files (.cfg) and a database dump of the monarch configuration database (.tar) will automatically be initiated every time a successful commit operation takes place. Backup configuration files are stored in a /usr/local/groundwork/monarch/backup/<timestamp> directory. In addition to the Nagios configuration files and the database file the backup directory also contains the monarch annotation (.annotation) file which holds an optional backup description added at the time of backup.

  1. From the Configuration menu option, choose Nagios Monitoring > Control > Commit.
  2. In the Nagios Commit screen, you have the option to add an Annotation describing what the backup represents (which is typically either a save point before a set of changes or a full final set of changes).
    • It is strongly encouraged to be very descriptive when you enter annotations which can be very helpful if you need to restore a configuration.
  3. Next, you have the option to Lock the backup which allows it to be saved indefinitely.
    • Unlocked backups are subject to being automatically deleted when too many accumulate.
  4. Select Commit to overwrite the active Nagios configuration, restart Nagios, and create a backup.
    • Select Abort if you do not want to follow through with the commit process.

Example Nagios configuration files:

ubuntu@demo:~/gw8$ docker-compose exec nagios bash
root@69631577e50d:/usr/local/nagios/etc# ls
bronx.cfg                            host_templates.cfg
cgi.cfg                              hostgroups.cfg
check_commands.cfg                   hosts.cfg
config-current.log                   misccommands.cfg
contact_groups.cfg                   nagios.cfg
contact_templates.cfg                resource.cfg
contacts.cfg                         send_nsca.cfg
escalation_templates.cfg             service_dependencies.cfg
extended_host_info.cfg               service_dependency_templates.cfg
extended_host_info_templates.cfg     service_escalations.cfg
extended_service_info.cfg            service_groups.cfg
extended_service_info_templates.cfg  service_templates.cfg
host_dependencies.cfg                services.cfg
host_escalations.cfg                 time_periods.cfg

Example backup <timestamp> directory files:

ubuntu@demo:~/gw8$ docker-compose exec monarch bash
root@9d50a7b24cd7:/src# cd /usr/local/groundwork/monarch/backup
root@9d50a7b24cd7:/usr/local/groundwork/monarch/backup# ls
2020-02-24_19-25-37  2020-02-24_19-33-25
2020-02-26_22-04-06  2020-02-26_22-14-44  
root@9d50a7b24cd7:/usr/local/groundwork/monarch/backup# cd 2020-02-26_22-14-44
root@9d50a7b24cd7:/usr/local/groundwork/monarch/backup/2020-02-26_22-14-44# ls
cgi.cfg                   extended_host_info_templates.cfg     hosts.cfg                               service_dependency_templates.cfg
check_commands.cfg        extended_service_info.cfg            misccommands.cfg                        service_escalations.cfg
contact_groups.cfg        extended_service_info_templates.cfg  monarch-2020-02-26_22-14-44.annotation  service_groups.cfg
contact_templates.cfg     host_dependencies.cfg                monarch-2020-02-26_22-14-44.sql.tar     service_templates.cfg
contacts.cfg              host_escalations.cfg                 nagios.cfg                              services.cfg
escalation_templates.cfg  host_templates.cfg                   resource.cfg                            time_periods.cfg
extended_host_info.cfg    hostgroups.cfg                       service_dependencies.cfg

Related articles