# Assign Checkmk cluster-service rules to the nodes before discovery > Select cluster-service rules on the actual nodes and rediscover the complete participating host set. - Canonical URL: https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:46:54+00:00 - Modified: 2026-10-30T06:47:29+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Select cluster-service rules on the actual nodes and rediscover the complete participating host set. ## Potentially affected Checkmk cluster hosts and node hosts using check plug-ins with documented cluster support. ## DSE recommendation Validate the cluster prerequisites, node rule scope and discovery population together. ## Article Bottom line: Select clustered services through node-host rules, preserve same-site/data-source and plug-in support prerequisites, then rediscover the cluster and all nodes to reconcile service ownership. ## Source fact: what the authority says The [Checkmk cluster-service guide](https://docs.checkmk.com/latest/en/clustered_services.html) requires identical data-source configuration for the cluster and its nodes, with every participating host on the same Checkmk site in distributed monitoring. A check needs implemented cluster support, which the guide directs administrators to confirm in that plug-in’s manual page. Cluster-service rules must apply to the node hosts; applying such a rule to the cluster host is ineffective. After defining clustered services, discovery must run for the cluster and every node so those services move from the node listings to the cluster listing. ## What the source does not establish This article reconciles monitoring service ownership, not the application’s HA implementation or a guarantee of seamless failover. It does not qualify an unsupported plug-in or cover overlapping-cluster assignment rules. ## Applicability questions - Which node hosts and virtual cluster host form the monitored population? - Are their data sources and Checkmk site assignments consistent? - Which selected plug-ins explicitly support clustering? - What local and clustered service inventories should discovery produce? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends separating application-cluster design from the monitoring ownership map. Name the virtual cluster and every participating node, then classify the intended services as node-local or clustered. Have the application owner identify the actual service relationship rather than copying a broad regular expression from the example database cluster. Review the data-source, site and plug-in support prerequisites before creating the rules. Keep the exact installed plug-in manual with the selected service population. Stop on an unsupported or unclear check instead of assuming that any service can be moved to the virtual cluster simply because its name matches. Apply the intended rule scope to the node-host population and have another operator trace those conditions. Keep local hardware observations outside the clustered-service selection unless deliberately justified. Preserve the prior monitored-service inventory so an unexpectedly missing node entry can be explained against the intended relocation. Plan discovery for all participating hosts as one reconciliation task. Record which services should be listed on the cluster and which should remain local afterward. Leave automatic vanished-service deletion and overlapping clusters to their separately reviewed procedures, and avoid combining a monitoring change with an unplanned application failover. ## Verification and evidence Proposed verification: use an approved representative test cluster and a harmless service with confirmed plug-in support. Inspect the node and cluster configuration, rule scope and pre-discovery service inventory. Perform the planned discovery across the complete participating host set and retain actual results. Compare the cluster list and each node list with the written ownership map, including local control services. Investigate missing or duplicated entries before extending the rule. Any separately approved application-transition exercise should have its own service observations; correct monitoring placement alone does not establish application availability or failover quality. ## Official references - [Checkmk — Monitoring cluster services](https://docs.checkmk.com/latest/en/clustered_services.html) — official product documentation; confirm the installed release and configuration. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Checkmk — Monitoring cluster services - Authority: docs.checkmk.com - URL: https://docs.checkmk.com/latest/en/clustered_services.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign Checkmk cluster-service rules to the nodes before discovery,” DSE Security, https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.