Letzte Aktualisierung: 08. Oktober 2012
Distributed WATO allows you to manage several monitoring sites through a logically
centralized WATO. The topology in distributed WATO knows two kinds of omd sites, slaves and master.
All configuration is done through the master site.
Slave sites only receive the configuration from its master. Therefore it is disadvised
that you make any changes onto the slaves site. It is possible to make changes, but they are getting
reverted as soon as a new configuration from a master is replicated into this site.
3. Replicated Configuration
The entire WATO configuration is a collection of files and folders. Therefore, a replication of
this data requires nothing more than to archive these into a tarball (also called snapshot) and
sent the data to a remote site where it is unpacked again. As of Version 1.2.0 the following site files/directories are replicated
Contains WATO related configurations.
- Host configurations: hosts.mk and .wato files
- Definitions of hosts and services rules: rules.mk
- Timeperiods: timeperiods.mk
- WATO related global settings: global.mk
- Definitions of contacts: contacts.mk
- Definitions of contact groups: groups.mk
Contains Multisite related configurations.
- Definitions of host tags: hosttags.mk
- Definitions of multisite users: users.mk
- Multisite related global settings: global.mk
Contains several subdirectories with user specific settings
- Various visibility information:
bi_treestate.mk buttonscounts.mk help.mk
transids.mk treestates.mk viewoptions.mk
- BI assumptions: bi_assumptions.mk
- User defined views: views.mk
Contains user credentials for the site-apache
Contains multisites authentification secret
The distributed WATO configuration can be accessed via the WATO menu "Distributed Monitoring"
Setting up distributed WATO is rather simple since you only have to configure the master.
Slave sites do not need any further configuration, in truth, they do not actually know that
they operate in slave-mode. Their configuration is updated via an automation function which
receives the snapshot from the master and unpacks it into its working directory.
In the following example we create a monitoring setup consisting of one master and two slave sites.
We are going to create three connections in the "Distributed Monitoring" menu, two slaves and one master.
4.1. Create new site configuration
A new connection can be created by pressing the "New connection button" which lead to the following page.
The purpose of the edit site connection formular isn't solely the configuration of the distributed WATO settings,
but also the configuration of the sites general settings, like the accessibilty of multisite and livestatus.
The name of the omd site
An alias or description of the site
Livestatus (and Multisite) settings
How to connect to this omd site. Choices involve TCP and UNIX socket connections or no connection at all.
When connecting to remote site please make sure that Livestatus over TCP is activated there.
The UNIX socket is used connect to foreign sites on the localhost.
This sets the time that Multisite waits for a connection to the site to be established before the site is considered to be unreachable. If not set, the operating system defaults are being used and just one login attempt is being performed.
If you enable persistent connections then Multisite will try to keep open the connection to the remote sites. This brings a great speed up in high-latency situations but locks a number of threads in the Livestatus module of the target site.
The URL prefix will be prepended to links of addons like PNP4Nagios or the classical Nagios GUI when a link to such applications points to a host or service on that site.
By specifying a status host for each non-local connection you prevent Multisite from running into timeouts when remote sites do not respond. You need to add the remote monitoring servers as hosts into your local monitoring site and use their host state as a reachability state of the remote site.
If you disable a connection, then no data of this site will be shown in the status GUI. The replication is not affected by this, however.
Configuration Replication (Distriuted WATO)
Here you can choose if this site is used as slave or not replicated at all.
The local site is always set to "No replication with this site" since it doesn't make sense to replicate data with itself.
Multisite-URL of remote site
URL of the remote Check_MK including /check_mk/. This URL is in many cases the same as the URL-Prefix but with check_mk/ appended, but it must always be an absolute URL. Please note, that that URL will be fetched by the Apache server of the local site itself, whilst the URL-Prefix is used by your local Browser.
This might be needed to make the synchronization accept problems with SSL certificates when using an SSL secured connection.
4.2. Setup the master site
The master site is accessible on the localhost, which leads to the following configuration
As you see, there are no changes required within the "Configuration Replication" topic, only the basic and livestatus settings require some input. Replication is only of interest for the slave sites, since they get their configuration from this master.
4.3. Setup the slave sites
Our slaves sites are running on the remote systems at 10.1.1.84 (slaveSite1) and 10.1.1.87 (slaveSite2).
In the picture above you can see the configuration for the slaveSite1.
The "Replication method" attribute is set to "Slave:", which is the indicator for the master site, that the slaveSite1 should receive the configuration from the master.
5. Using distributed WATO
This is simply. Any changes, except the inventory call, can be done on the master site.
Since WATO knows which of the slave sites are affected by the latest changes, only these are receiving an updated configuration snapshot. Follwing the snapshot update their configuration is rewritten and the monitoring system restarts.