Configuring and using the Appliance

At this point you should have set up the appliance on a rack or installed and started it in a virtual machine, either VirtualBox or VMWare ESXi.

During the first start there will be a message for specifying the desired language:

The selected language will be set for the whole device. Afterwards, a message appears prompting you to initialise the data volume:

Confirm this dialogue and wait for device startup to be resumed and to complete. The status view will now be displayed on the local console:

This view shows you general status information and the most important configuration options for your device.

From the status view you can get to the configuration menu by pressing the F1 key:

To put the device into operation, you now need to set up the network configuration and specify the device password.

Once you have enabled access to the web interface through the previous configuration, you can now access the web interface via a web browser on a computer connected to the device via the network. To do this enter the appliance URL in the address bar of the browser, in this case http://192.168.178.60/. Here you can see the web interface’s login screen:

When you have logged in with the previously-set device password, the main menu will open. From here you can access all of the features in the web interface.

Select Device Settings to view the most important device settings and to change these if necessary:

By clicking on the parameter name you will be taken to the respective page for editing the respective setting.

If you have DNS servers available in your environment you should now configure one or more of these so that the resolution of host names can be used. If you have one or more NTP servers for time synchronisation available in your environment, enter these as IP addresses or host names under NTP Servers.

If emails are to be sent from your device – such as notifications in case of problems – you must configure the Outgoing Emails option. To do this enter the SMTP relay server responsible for this device and any access data required. All emails generated on the device will be sent to this server. Under this setting you can also configure all emails generated by the device’s operating system (e.g. in the case of critical errors) to be sent to a particular email address.

This completes the basic device configuration and you can proceed with the installation of the Checkmk software and the setup of the first monitoring site.

In the main menu of the web interface, click on Site Management. On this page you have access to all of the monitoring sites on this device. You can configure, update and delete sites, as well as create new ones.

The first time you open the page it will be empty. To create your first site, click on the Create New Site button. On the following page you can specify the initial site configuration.

Start by entering a site ID which serves to uniquely identify the site. The ID may only contain letters, numbers, hyphens (-) and underscores (_), must start with a letter or underscore and may be a maximum of 16 characters in length.

Now select the Checkmk version with which to create the site. You will be offered all versions that are installed in the administration of Checkmk software versions.

Finally, you define the user name of the Checkmk administrator with password. You can leave all other settings as they are for the time being. If necessary, you can edit these later via the site editing page.

Click Create Site to create the site. This may take a few seconds. Once the site has been created and started you will be taken to the list of all sites:

The list is short and currently only shows the site just created with the ID mysite and its status, here running. With the button on the far right in the Control column you can stop or start the site. On the far left in the Actions column, symbols are shown for the possible actions you can apply to the site, from left to right: Edit, Update, Rename, Clone, Delete and Login.

You can now log in to the site that has been started, either by clicking on the site ID or by calling up the URL of the site in the address bar of your web browser, in our example: http://192.168.178.60/mysite. In the site’s login dialogue, enter the access data you specified when creating the site.

Once you have logged in you can set up Checkmk in the usual manner — the first steps are described in the article on Getting started with monitoring.

The snapin Checkmk Appliance is available in all sites and for all administrators. You will find it in the sidebar:

The entries in this snapin will take you from your sites directly to the appliance’s web interface.

When updating a site, it is updated with a new Checkmk software version. First install the desired new version as described in the chapter on administration of Checkmk software versions.

Then list the sites on the appliance’s web interface (Main Menu > Site Management):

Make sure that the site is not running, i.e. if the Status is currently running, stop the site (Control > Stop). Then, under Actions, click on the update icon.

The following page lists the possible target versions for the update:

Select the Target Check_MK version and then click on Update now. After a short time, the update messages are displayed:

With the Back button you can return to the list of sites in which the new Checkmk version is now shown in the Version column. You can now restart the site.

Note: The update of a site in the appliance follows the same principle as the update on a Linux server. In the event of problems, error messages or conflicts, you can obtain detailed information on the update process in the article Updates and Upgrades.

It is a commonly required to migrate existing sites from other Linux systems to a Checkmk appliance. The Checkmk appliance offers a page for this purpose with which you can carry out this migration.

The following requirements need to be met:

Open the main menu of the web interface and click on Site Management. Then click on the Migrate Site button, which will take you to the below menu:

On this page under Source Host you first need to configure the host address (host name, DNS name or IP address) of the source system which you want to migrate the site from. Next under Source site ID you need to enter the site ID of the site you want to migrate.

The migration of the site is done via SSH. To get access to the source site, you need to provide the credentials of a user which is able to connect to the source system and access all of the source site’s files. You can use the root user of the source system or, if you have configured a password for the site user, you can use the site user credentials.

Optionally you can choose to let the migration create the site with a new site ID on your device, or carry the original ID unchanged over to the new device.

Youa additionally have the option to skip the carrying-over of performance data (measurements, graphs) and historical data during the migration. This can be useful if you don’t need an exact copy of the source site and only want to duplicate it – e.g. for testing purposes.

After you have filled in the parameters and confirmed with Start, the progress of the migration will be displayed:

Once the migration has completed you can finalise the migration by clicking on Complete. You will be returned to the site management where you can start and manage the newly-imported site in the usual way.

During the basic configuration you specified the language for your device. You can change this at any time, either via the console configuration or via the device settings in the web interface. Like all other settings in this dialog changes will be effective immediately when saved.

During the basic configuration you specified the network configuration of your device. You can change this at any time, either via the console configuration or via the device settings in the web interface. If you made an error when specifying the network configuration and the device is no longer accessible via the network you can only correct the settings on the console.

Host and domain names serve to identify a computer in the network. When sending emails for example, these names are used to form the sender address. In addition, the configured host name is added as a source host to all log entries that are sent to a syslog server. This makes it easier to assign the entries.

In most environments DNS servers are used to translate IP addresses into host names and vice versa. Host names or FQDNs (Fully Qualified Domain Names) are frequently used for monitoring instead of IP addresses.

In order to use the name resolution on your device, you must configure the IP addresses of at least one DNS server in your environment. It is recommended to enter at least two DNS servers.

Only when you have configured this option can you use host and domain names (in the configuration of NTP or mail servers for example).

The system time of the device is used for many purposes, such as for recording measurement data or writing log files. A stable system time is therefore very important. This is best ensured by using a time synchronisation service (NTP).

To activate the synchronisation enter the host address of at least one time server under NTP server.

Log messages are generated on the device by the operating system and some permanently running processes. They are initially written into a local log via syslog.

You can also send these entries to a central or higher-level syslog server where they can be evaluated, filtered or archived.

Select the item Syslog to configure the forwarding.

In the dialogue box that appears next you can configure which protocol you wish to use for forwarding. Syslog via UDP is more widely used, but not as reliable as via TCP. So if your syslog server supports both protocols it is recommended to use TCP.

You also need to configure the host address of the syslog server that is to receive the log messages.

If you access the host address of the device directly via the web browser without entering a path by default you will be taken to the device’s start page. However it is also possible for you to be forwarded directly to a monitoring site of your choice.

You can configure this using the setting HTTP access without URL. Via this setting, select the monitoring site to open instead of the web interface. The Appliance home page can then be reached via the URL along with the path – for example 192.168.178.60/webconf.

So that you can send emails from the device (in the case of events during monitoring for example), the forwarding of emails to one of your mail servers must be configured using Outgoing Emails.

In order for the sending of emails to work you must have at least configured the host address of your mail server as an SMTP relay server. This server will then receive the emails from your device and forward them.

However configuring the SMTP relay server is only sufficient as long as your mail server accepts emails via anonymous SMTP. If your mail server requires authentication, then you need to activate the appropriate login method under the Authentication item and indicate the access data of an account that can log onto the mail server.

If you do not even receive any emails after the configuration it is worth taking a look at the device’s system log. All attempts to send emails are logged here.

The device itself can send system emails if there are critical problems (e.g. a job cannot be executed or a hardware problem has been detected). In order to receive these emails you must configure an email address to which these emails are to be sent using Send local system mails to.

A Checkmk agent is installed on the device and in the basic setting can only be queried by the device itself. You can use it to create an site on the device and directly add the device to the monitoring.

It is also possible to make the Checkmk agent accessible from another device, meaning the device can also be monitored by another Checkmk system (e.g. in a distributed environment by a central server). For this purpose, you can configure a list of IP addresses that are allowed to contact the Checkmk agent.

You can activate various access types for the SSH remote management protocol. Basically

are supported. Access with the system user root is possible but not recommended or supported, because with that it is pretty easy to damage configurations or software.

You can activate access to the command line of the individual monitoring sites, enabling you to view and control the entire environment of the site.

This access is controlled via the site management. In the settings dialogue of each individual site you can activate and deactivate access as well as set a password to protect access.

It is possible to activate access to the console of the device via the network, enabling you to view and adjust the basic configuration of the device even without direct access to the device.

You can enable access via the configuration dialogue of the console. To do this, select the menu item Activate console via SSH.

When you activate this option, you will be asked to enter a password. You must enter this password if you are connecting as a setup user via SSH. Access will be automatically enabled directly after confirming this dialogue.

You can now connect to the device as a setup user using an SSH Client (e.g. PuTTY).

You can check whether access is currently enabled by looking at the Access box of the console’s status screen.

It is possible to activate access to the device as a root system user. Once the device has initialised however this access will be deactivated. Once activated you can log onto the device as a root user via SSH.

Commands you execute on the device as root can cause lasting alteration or damage, not only to your data, but also to the delivered system. The manufacturer shall accept no liability for alterations you make in this way. Only activate and use the root user if you are sure what you are doing and only for diagnostic purposes.

You can enable access via the configuration dialogue of the console. To do this, select the menu item Root access via SSH.

Then set the option to enable.

When you activate this option you will be asked to enter a password. You must enter this password if you are connecting as a root user via SSH. Access will be automatically enabled directly after confirming this dialogue.

You can now connect to the device as a root user using an SSH Client (e.g. PuTTY).

You can check whether access is currently enabled by looking at the Access box of the console’s status screen.

By default the web interface of your device is accessed via HTTP in plain text. You can protect this access via HTTPS (TLS), so that data is transferred including encryption.

You can open the configuration by pressing the Web access type button in the device settings.

In order to encrypt data traffic the device next needs a certificate and a private key. There are several ways available for you to install these.

You can choose one of the options above that fits your requirements and possibilities. Certificates signed by certification authorities generally have the advantage that clients can automatically verify the authenticity of the host (device) at the time of access. This is normally the case with official certification authorities.

If a user accesses the web interface via HTTPS and the certificate is either self-signed or signed by a certification authority not trusted by the user, this will cause a warning to appear in the user’s web browser first.

Once you have installed a certificate you can now configure the access types according to your requirements.

If you wish to protect access to your device via HTTPS you are recommended to select the HTTPS enforced (incl. redirect from HTTP to HTTPS) option. The device will only respond via HTTPS, but will redirect all incoming HTTP requests to HTTPS. This means that users who inadvertently access the web interface via HTTP, either directly or via bookmarks, will automatically be redirected to HTTPS.

If it is very important that not a single request goes over the net in plain language, you can select the option HTTPS only. This setting will cause users accessing via HTTP to receive an error message.

You can also have a simultaneous configuration of HTTP and HTTPS. However this setting is only recommended in exceptional cases, for migration purposes or for testing.

If you ever want to deactivate HTTPS, you can do this by selecting the HTTP only option.

On the access type configuration page you can see the types of access currently active as well as information regarding the current certificate.

You can restart or shut down the device over both the web interface and the console.

In the web interface you will find the menu items Reboot device and Shutdown device under the point Control device in the main menu. The device will execute the action immediately after the command has been selected.

In the console you can open the device control menu by pressing F2.

You should only shut down your rail2 appliance if you have physical access to the system, since you can only restart the device by disconnecting and restoring the power.

You can reset your device to its factory settings. This means that any changes you have made to the device (e.g. your device settings, monitoring configuration or recorded statistics and logs) will be deleted. When resetting the settings the firmware version currently installed will be retained – the firmware installed with the device as delivered will not be restored.

You can perform this action on the console. To do this press the F2 key on the status screen and select Factory Reset in the dialogue box that follows. Confirm the next dialogue box by clicking on yes. Your data will now be deleted from the device and the device then restarted immediately. The device will now start with a fresh configuration.

In order to preserve your monitoring data in case of a hardware failure or similar destruction, a backup of your data can be configured via your appliance’s web user interface.

To be certain the data really is backed up it must be saved to another device – a file server for example. For this, via mount management, first configure the network file sharing to be used for the backup. This will be defined as the target when configuring the data backup. Once this is completed a backup job can be created that at predefined intervals saves a backup of your system to the shared network.

The full backup includes all of the configurations defined on the system, installed files, and likewise your monitoring sites.

The backup is executed (online) during active operations. This can however first be fully-realised when all monitoring sites on the appliance use Checkmk 1.2.8p6, 1.4.0i1 or a Daily-Build from or newer than 22.07.2016. Active sites using older versions will be stopped before, and restarted after the backup.

To set up an automatic data backup, configure one or more backup jobs. A backup data set must be created on the target system for each backup job. When each new backup is completed, the previous backup will be deleted – meaning that on the target system double the storage allocation will be temporarily required.

The backup does not manage multiple generations. If you require more copies over an extended time frame to be retained, you will need to create these yourself.

With help from the file system management first configure your network sharing. In our example a network sharing is configured under the file path /mnt/auto/backup.

Next, select the Device backup item in the web interface’s main menu, and in the next menu open the Backup target. Then create a New backup target. The title and the ID have a free syntax. Under the Target directory for backup item configure the mounted network sharing’s data path - in this case /mnt/auto/backup. The Is mountpoint option must be active if you are backing up to a network file sharing – this verifies to the backup that the file sharing really is mounted.

Once the backup target has been created, return to the Device backup page and from there select New job. Here again you can choose an ID and a title. Next, select the newly-created backup target and define the desired periods for running the backup.

After saving you will see an entry for your new backup job on the Appliance backup page. The scheduled time for the next execution will be shown at the end of this line. As soon as the job has started, or respectively, completed, its status will be shown in this view. Here you can also manually start, or if needed interrupt running backups.

To test your newly created job, click on the Play-icon. You will see in the table that your job is currently running. By clicking on the Log-icon you can display the job’s progress in the form of a log output.

As soon as the backup has completed this will also be shown in the table.

Every backup job creates a directory on the backup target. This directory’s name conforms to the following schema:

In the wildcard character fields, any - (minus) characters are replaced by + so as not to be confused with the field separators.

During the backup the directory will be saved with the suffix: -incomplete. Once completed the directory is renamed and the suffix changed to: -complete.

A data set mkbackup.info containing the meta information pertaining to the backup is saved in the directory. Alongside this file a number of archives are saved to the directory.

The archive named system contains the appliance’s configuration, system-data contains the data file system’s data – excluding that of the monitoring sites. The monitoring sites are saved in separate archives that use the site-[SITENAME] naming schema.

Depending on the backup’s mode, these data sets are saved with the .tar file extension for uncompressed and unencrypted, .tar.gz for compressed but unencrypted, and .tar.gz.enc for compressed and encrypted archives.

If you want to encrypt your backup you can configure this directly from the web user interface. Your backed-up data will then be completely encrypted before being transferred to the backup target. The encryption is achieved using a predefined encryption key. This key is protected by a password defined when creating the key, and with which the key must be securely retained, as only with these is it possible to retrieve the backed up data.

To this end, open the Device backup page and from there select the Backup keys page. Here you can create a new encryption key. When entering the password be sure to use a sufficiently complex character string – the longer and more complex your password, the harder it is for an attacker to decrypt your key and thus your backup.

Once you have created your key, download it and retain it in a secure location.

An encrypted backup can only be restored with the encryption key and its corresponding password.

Now, from the Device backup edit the backup job that is to create the encrypted backups – there activate the Encryption item and select the freshly-created encryption key.

Once you have confirmed the dialogue, the next backup will be automatically encrypted.

It is possible to compress the data during the copy procedure. This can be useful if you need to save bandwidth or if space on the target system is limited.

But please be aware however that the compression requires noticeably more CPU time and therefore the backup procedure will take longer. As a rule it is advisable not to activate compression.

Uncompressed backups are first supported from Checkmk-version 1.2.8p5. If you run monitoring sites with older versions, you must activate compression for the complete backup.

Using the web user interface’s built-in functions you can only make a complete restore. Restoring individual data sets via the web interface is not provided. This is nevertheless possible via the command line and by manually unpacking from the backup.

If you wish to restore a complete backup on a currently running appliance, select the Restore item on the Device backup page, and on the next page select the backup target from where you want to source the backed-up data. Once the backup target has been selected a list of all of its available backups will be shown.

Next, click on the arrow beside the backup data you wish to use and the restore will initiate – and following confirmation of a security query the restore will start.

While the restore is running you can view its progress by refreshing the Restore page that will be automatically displayed.

At the end of the restore the appliance will automatically restart – following this new start the restore will be complete.

From Checkmk version 1.4.0i1, for every configured backup job the Service Discovery on the appliance has a new service: Backup [JOB-ID]. This service notifies of potential problems with the backup, and displays useful values such as size and duration.

The complete configuration of the backups, including the encryption keys will be synchronised between the cluster nodes. The cluster nodes run the backups separately, and likewise save separate directories for their backups on the backup target.

The active cluster node backs up the complete appliance including the data from the data file system and from the monitoring site. The inactive cluster node saves only its local appliance configuration.

Thus, when restoring a backup, only an active cluster node’s backup can restore the monitoring sites.

If for example, you wish to make a backup on a shared resource, you must first configure the required network file system.

The network file system (NFS Version 3), the Windows Shared Resources (Samba or CIFS) and SSHFS (SFTP) are currently supported.

In the web user interface’s main menu select the item Manage mounts and from here create a new file system. Enter an ID that will later be used in devices to identify the file system.

Next select if and how the file system is to be mounted. Recommended is automatic mounting when accessed and, respectively, automatic unmounting when inactive.

Next configure the type of share to be mounted, and finally, depending on this, the necessary settings for mounting the share - for example the file server’s network address and the exported file path in the case of NFS.

Once saved the newly-configured file system and its current status can be viewed in the file system management. By clicking on the plug icon you can manually mount the file system to test that the configuration is correct.

If there are problems you may possibly find error messages in the system log.

You can combine two Checkmk appliances into a failover cluster. All configurations and data are synchronized between the two devices. The devices that are connected as a cluster are also called nodes. One of the nodes in the cluster assumes the active role, i.e. performs the tasks of the cluster. Both nodes continuously exchange information about their status. As soon as the inactive node recognizes that the active node can no longer fulfill its tasks – due to a failure for example – the inactive node takes over the tasks and becomes the active node.

The failover cluster is there to increase the availability of your monitoring installation by protecting a device or individual components against hardware failures. The clustering is not a substitute for data backups.

The cluster ensures a shorter downtime in the following situations:

In order to build a cluster you will first need two compatible Checkmk appliances. The following models can be clustered with one another:

In addition, the two devices must use a compatible firmware, and at least version 1.1.0.

The devices must be wired with at least two mutually-independent network connections. It is recommended to use as direct a connection as possible between the devices, and to make a further connection over your LAN.

To increase the availability of network connections, you should – instead of using two connections via individual network connectors – create a bonding configuration that uses all four of the Checkmk rack1’s network connectors. Use the LAN1 and LAN2 interfaces for the connection to your network, and the LAN3 and LAN4 interfaces for the direct connection between the devices.

Virtual machines: If you want to perform the cluster function with two ‚Checkmk virt1’ appliances and VirtualBox, for example for testing, you should do without the bonding configuration and with a total of four network interfaces - this becomes a gamble under VirtualBox, if it works at all. Even if both VMs run on the same machine and thus there are no multiple hardware lines, you still need two virtual network interfaces to be able to set up a separate channel to synchronize the data later. You can easily add these in the VirtualBox management interface of the virt1 machine.

So instead of setting up the bonding as shown below, simply activate the unused second network interface - but not for your normal LAN subnet (e.g., 192.168.178.0/24) – but a separate subnet (e.g. 192.168.100.0/24). For the actual clustering you simply select your two individual interfaces instead of the bundled bonding interfaces.

Devices that were delivered and initialised with the firmware version 1.1.0 or higher can be clustered without migration.

Devices initialised with earlier firmware must first be updated to version 1.1.0 or higher. The device’s factory settings then need to be restored, preparing the device for clustering. Please note that, in order to prevent data loss during this procedure, you must first back up your data from the device and then restore it.

This guide assumes that you have already pre-configured both devices so that the web interface can be opened with a web browser.

Before actually setting up the cluster you must first prepare both devices. This mainly involves adapting the network configuration to fulfill clustering requirements (see prerequisites).

The configuration of a cluster with two Checkmk rack1 is shown in the following. A cluster is built which looks as shown in the diagram below.

The interface designations LAN1, LAN2 etc., used in the diagram correspond to the designations of the physical interfaces on the device. In the operating system, LAN1 corresponds to the device eth0, LAN2 to the device eth1 etc.

This configuration complies with the recommendations for the clustering of two Checkmk rack1s. You can of course use IP addresses suitable for your environment. Make sure however that the internal cluster network (bond1 in the diagram) uses a different IP network to the ‚external‘ network (bond0 in the diagram).

When the first synchronisation is complete, your cluster will be fully operational. You can view the state at any time on the cluster page.

Using the status screen on the console you can also view the current state of the cluster in a summarised form in the Cluster box. The role of the respective node is shown after the current status with (M) for the main host und (S) for the subordinate host.

It is possible to disband the nodes from a cluster and continue running them separately. When doing so you can continue using the synchronised configuration on both devices, or reset one of the devices to factory settings and reconfigure it for example.

You can remove one or both nodes from the cluster during operation. If you wish to use both nodes, you must ensure that the data synchronisation is in good working order beforehand. You can verify this on the cluster page.

In order to disband a cluster, click on Disband Cluster on the cluster page of the web interface. Read the text of the confirmation prompt that follows. In the different situations, this text contains information as to the state the respective device is in following the disconnection.

The disconnection of the devices must be carried out on both nodes separately, so that both devices can be run separately in future.

If you only wish to use one of the devices in future, disconnect the cluster on the device you intend to continue using and then restore the factory settings on the other device.

Once you have disconnected a node from the cluster the monitoring sites will not be started automatically. If you wish to start the monitoring sites, you will need to do so via the web interface.

It is possible to attach a GSM modem to the device in order to have SMS notifications sent over it by Checkmk (in the event of critical problems for example).

At the moment it is not possible to order a UMTS/GSM modem together with your appliance nor later as an accessory. But there are several modems like the MTD-H5-2.0, which are compatible to the appliance.

In order to put the modem into operation you must insert a functioning SIM card, attach the modem to a free USB connector on your appliance using the enclosed USB cable, and connect the modem to the mains using the enclosed power adapter.

As soon as this has been done the device will automatically detect the modem and set it up. Open the device’s web interface and select the Manage SMS module. The current state of the modem as well as the connection with the mobile phone network will be displayed on this page.

If you need to enter a PIN to use your SIM card, you can specify this PIN under SMS settings.

If sent messages do not reach you, you can view all sent or non-sent messages and messages awaiting sending on the page Manage SMS. The entries in these lists will be kept for a maximum of 30 days and then automatically deleted.

It is possible, via the menu item Send test SMS, to send a test SMS to a number of your choice. The telephone number must be entered without leading zeros and without a leading plus sign, e.g. 491512345678 for a mobile phone number in Germany.

You will find further information on possible SMS sending errors in the SMS Log.

Your rack has two hard drive bays on the front. These are marked with numbers 1 and 2. The hard disks installed here are interconnected in a RAID-1 array (mirror) so that your data is stored redundantly on both hard disks. If one of the hard disks fails the data is still available on the second hard disk.

You can view the state of the RAID in your device’s web interface. To do this select the item RAID-Setup in the main menu of the web interface. This screen also gives you the option to repair the RAID if necessary.

If a hard drive is detected as being defective, this will be displayed in the web interface with defective. On the actual device – depending on the nature of the error – this will be shown by a blue flashing LED at the hard drive bay.

Moving the small lever on the left-hand side of the bay will unlock the fixing mechanism, enabling you to pull the frame out of the housing together with the hard drive. You can now loosen the screws on the underside of the frame and remove the defective hard drive. Now mount the new hard drive into the frame and push the frame back into the free bay of the device.

If the device is switched on while you are exchanging the hard drive, the RAID rebuild will start automatically. You can view this procedure’s progress in the web interface.

Failsafe operation is only restored once the RAID has been completely repaired.

The hard drive must be at least the same size as the RAID itself. You can verify this in the RAID status view.

If the device detects that both hard drives are defective or have been removed from the device a restart is automatically triggered.

Despite careful tests, it cannot be altogether ruled out that unexpected errors may occur, which are difficult to diagnose without looking at the operating system.

One option is to have the log entries that are generated on the system sent via syslog to a syslog server. However the log entries of the individual monitoring sites are not processed via syslog, meaning they are not forwarded and can only be viewed on the device.

In order to make diagnostics on the device easier there is a view that displays the device’s various log files. You can go to this view by clicking on the Log Files menu item in the web interface’s main menu.

You can select the device’s logs and view their current content here.

The system log is reinitialized each time the device is started up. If you would like to keep the log entries you must send them to a syslog server.

It is also possible to view the system log on the local console. The latest entries from the system log are displayed on the second terminal. You can access this terminal via the key combination CTRL+ALT+F2. All kernel messages are displayed on the third terminal. In the case of hardware problems, you will find the relevant messages here. This terminal can be accessed via the key combination CTRL+ALT+F3. The key combination CTRL+ALT+F1 will take you back to the status screen.

The system memory of the device is available to your monitoring sites, reduced by the amount of memory which is needed by the system processes of the Checkmk appliance.

To provide a stable system platform a fixed amount if memory is reserved for the mandatory system processes. The exact amount of reserved memory depends on your device configuration:

If you want to know exactly how much memory is available to your monitoring sites and how much is currently being used, you can monitor your device using Checkmk. After a service discovery the host automatically monitors a service User_Memory which shows you the current and historical values.

In case your you monitoring sites are trying consume more memory than available, one of the processes of the monitoring sites is automatically killed. This is done by standard mechanisms in the Linux Kernel.

If you encounter any problems during start-up or operation please consult this manual first.

You can get up-to-date support information from our website. You will find the latest version of the documentation here as well as general information which is regularly updated and more detailed than this manual.

You will find the latest firmware versions on our website. You can access this firmware using the access data for your current support contract.

In the event of hardware failure please contact us by email at cma-support@checkmk.com, or call us on +49 89 99 82 097 - 20. The problem will be handled by the distributor directly and in accordance with the maintenance agreed upon.

In the case of a software fault – whether firmware or Checkmk monitoring software – please contact us via your company’s own support address. Support will be provided based on the agreed support contract.