Distributed monitoring in Checkmk connects a remote site to a central site so monitoring can run close to the hosts while operators work from one central interface. This is useful when remote networks, branch offices, or segmented environments should keep checks local but still report status to the central site.
The central site stores the shared configuration and queries remote monitoring state through Livestatus. When Push configuration to this site is enabled, the central site also sends configuration snapshots to the remote site over the remote web interface, so the remote site must expose both its web URL and its Livestatus TCP endpoint to the central site.
Use this flow after both Checkmk sites already exist and the central site can reach the remote site by name. The remote site's local configuration is overwritten when it is integrated into the central setup, so migrate or recreate any existing remote-only hosts before enabling central replication.
Central site: central Remote site: remote_dc1 Remote host: remote-monitoring.example.net Remote web URL: https://remote-monitoring.example.net/remote_dc1/
The remote site ID must match the actual Checkmk site name on the remote server.
$ sudo omd su remote_dc1 OMD[remote_dc1]:~$
OMD[remote_dc1]:~$ omd stop Stopping mkeventd...OK Stopping liveproxyd...OK Stopping mknotifyd...OK Stopping rrdcached...OK Stopping apache...OK Stopping redis...OK Stopping crontab...OK
Stopping the site interrupts monitoring from that remote site until it is started again.
OMD[remote_dc1]:~$ omd config set LIVESTATUS_TCP on
Livestatus is the status-data interface that the central site uses to read host and service states from the remote site.
OMD[remote_dc1]:~$ omd config set LIVESTATUS_TCP_PORT 6557
Use a different port only when the remote server already has another site or service using 6557.
OMD[remote_dc1]:~$ omd config set LIVESTATUS_TCP_TLS on
The central site must use the matching Encrypt data using TLS setting when the remote connection is added.
OMD[remote_dc1]:~$ omd config set PIGGYBACK_HUB on
Commercial sites that use piggyback data need the message broker path as well as Livestatus. The remote RABBITMQ_PORT value is used later in the central connection form.
OMD[remote_dc1]:~$ omd start Starting mkeventd...OK Starting liveproxyd...OK Starting mknotifyd...OK Starting rrdcached...OK Starting apache...OK Starting redis...OK Starting crontab...OK
OMD[remote_dc1]:~$ omd config show ##### snipped ##### LIVESTATUS_TCP: on LIVESTATUS_TCP_PORT: 6557 LIVESTATUS_TCP_TLS: on PIGGYBACK_HUB: on RABBITMQ_PORT: 5672 ##### snipped #####
Activate the setting before relying on cross-site piggyback forwarding because Checkmk restarts the affected site when the piggyback hub changes.
Use remote_dc1 as the Site ID when the remote site was created with that exact name.
https://remote-monitoring.example.net/remote_dc1/
Use the remote site's web interface URL for this field, not a copied browser URL from inside the check_mk/ application path.
Host name: remote-monitoring.example.net Port: 6557 Encryption: Encrypt data using TLS
Message broker port: 5672
Skip piggyback-specific broker settings only when the environment does not use distributed piggyback forwarding.
The central setup replaces the remote site's local configuration. Do not continue until any remote-only hosts or rules have been migrated or intentionally discarded.
The activation view should list the central site and the remote site, then synchronize and activate the selected sites.
Related: How to activate Checkmk pending changes
Online means the central site can query the remote site through Livestatus.
For a new host, create the host first and return to the same host properties page.
Related: How to add a host in Checkmk
Checkmk performs host access, service discovery, diagnostics, notifications, and similar monitoring actions from the site selected in Monitored on site.