Monitoring instances (sites)

In some cases it is also desirable to specify the user/group ID of the new user to be created. This is performed with the -u and -g options, e.g.:

An overview of the further options can be shown with omd create --help. The most important options are:

Those who don’t like the interactive mode, or prefer to work with scripts, can set the individual variables using commands. For this there is the omd config set command. The following example sets the CORE variable to cmc:

As always, this can be performed as root if the site’s name is added as an argument:

The current configuration of all variables can be viewed using omd config show:

There are numerous settings in omd config. The most important are:

If a large number of hosts are being monitored, the volume of data to be copied can be quite substantial. The greater part of this is the performance data which is stored in RRD-files. But the log files containing historic events can also produce larger data volumes. If the history is not required (for example, if only testing is being performed), these can be omitted from the copy. In such cases the following options can be added to omd cp:

The order of the options is important:

Renaming an instance is performed with the omd mv command. This functions similarly to the copy command and has the same prerequisites. The options to restrict the data volume are not available since the data is only being moved to another directory and is not being duplicated. For example:

Both operations will create new Linux-users in exactly the same way as create does, thus some of the options for omd create are also available for use:

The site management in Checkmk has a built-in mechanism for backing up and restoring Checkmk-instances. The omd backup and omd restore commands are the basics for packing all of an instance’s data into a tar archive, and respectively, extracting that data for a restore.

From Version 1.4.0 Checkmk additionally uses the Backup WATO-module which makes a backup and restore possible without the command line, and which also enables the setting-up of regular backup jobs.

Backing up an instance with omd backup does not require root-permissions. An instance user can perform this. Simply enter as an argument the name for the backup file to be created:

Please note however:

If the backup’s target directory is not writable for an instance user, the backup can otherwise be performed as a root-user. In this case an additional argument is always required specifying the name of the instance to be backed up:

The backup contains all of the instance’s data — except for the volatile data under tmp/. With the tar tzf command one can easily have a look at the file’s contents:

The lion’s share of an instance’s data is the performance data retained in the RRDs. The monitoring history can also be very large. If neither of these are absolutely required, with the following options the history data can be omitted, thus making the backup smaller and faster running. The options must be coded after the word ‘backup’:

Example:

A backup does not require the instance to be stopped, and therefore can be executed while the system is running. In order to ensure a consistent condition of the RRDs used for recording the performance data, the omd backup command automatically alters the Round-Robin-Cache to a mode with which the running updates are written only to the journal, and no longer to the RRDs. The journal files are the last to be backed up — thus it can be achieved that as much as possible of the performance data that has been generated during the backup is also included in the backup.

The restoring of a backup is as simple as the backup itself. The omd restore command restores an instance from a backup. This is even possible for a user. The instance must be stopped for this procedure. The instance will not be newly-generated (which would require root-permissions), rather it will be completely emptied and then refilled:

Following the restore the instance can be restarted:

A restore can also be performed by a root-user. If an instance with the same name already exists, this must first be deleted. This can be performed either with an omd rm, or by simply including the --reuse option. A --kill additionally ensures that the existing instance is first stopped. It is not necessary to use the instance’s name with the restore, since this is contained in the backup:

When operating as root, you can restore the instance with a different name from that in the backup. Include the desired alternative name as an argument following the restore command:

The long list of conversions found here has the same function as for the renaming of instances described earlier: The instance’s name is included in numerous configuration files, and with this these occurrences will be replaced automatically by the new name.

The omd backup and omd restore commands can — in the good old Unix tradition — instead of files, also work with the standard input/output. Instead of a data path for the tar file, simply enter a hyphen (-).

In this way a pipe can be constructed and the data ‘streamed’ directly to another computer without requiring intermediate files. The larger the backup, the more advantageous this will be since no temporary space in the backed up server’s file system will be needed.

The following command backs up an instance to another computer using SSH:

If you want to reverse the SSH-access — by which you prefer to log in TO the Checkmk-instance FROM the backup server — that is also possible, as shown in the following example. For this, first an SSH-Login as an instance user must be permitted:

If you are clever, and combine the above with an omd restore which reads the data from the standard input, you can copy a complete, running instance from one server to another — and without needing any additional space for a backup file:

And now, the same procedure with a reversed SSH-access — but this time from the source system to the target system: