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.
\nThe Checkmk cluster-service guide 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nReview 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.
\nApply 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.
\nPlan 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.
\nProposed 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.
\nCompare 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe Checkmk cluster-service guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich node hosts and virtual cluster host form the monitored population?\nAre their data sources and Checkmk site assignments consistent?\nWhich selected plug-ins explicitly support clustering?\nWhat local and clustered service inventories should discovery produce?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nReview 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.\nApply 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.\nPlan 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.\nVerification and evidence\nProposed 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.\nCompare 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.\nOfficial references\n\nCheckmk — Monitoring cluster services — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which node hosts and virtual cluster host form the monitored population?\n\n- Are their data sources and Checkmk site assignments consistent?\n\n- Which selected plug-ins explicitly support clustering?\n\n- What local and clustered service inventories should discovery produce?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nReview 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.\n\nApply 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.\n\nPlan 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.\n\n## Verification and evidence\n\nProposed 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.\n\nCompare 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.\n\n## Official references\n\n- [Checkmk — Monitoring cluster services](https://docs.checkmk.com/latest/en/clustered_services.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/", "url": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Business Continuity", "item": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "ListItem", "position": 3, "name": "Assign Checkmk cluster-service rules to the nodes before discovery", "item": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/#article", "identifier": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/", "url": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/", "headline": "Assign Checkmk cluster-service rules to the nodes before discovery", "description": "Select cluster-service rules on the actual nodes and rediscover the complete participating host set.", "abstract": "Select cluster-service rules on the actual nodes and rediscover the complete participating host set.", "articleBody": "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.\nSource fact: what the authority says\nThe Checkmk cluster-service guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich node hosts and virtual cluster host form the monitored population?\nAre their data sources and Checkmk site assignments consistent?\nWhich selected plug-ins explicitly support clustering?\nWhat local and clustered service inventories should discovery produce?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nReview 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.\nApply 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.\nPlan 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.\nVerification and evidence\nProposed 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.\nCompare 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.\nOfficial references\n\nCheckmk — Monitoring cluster services — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:46:54+00:00", "dateModified": "2026-10-30T06:47:29+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/assign-checkmk-cluster-service-rules-to-the-nodes-before-discovery/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Assign Checkmk cluster-service rules to the nodes before discovery" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 522, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Checkmk — Monitoring cluster services", "url": "https://docs.checkmk.com/latest/en/clustered_services.html" } } ] } }