Bottom line: For the documented Checkmk Ultimate 2.5.0 backend, account for remote-site metric silos and retention of fourteen days rather than assuming central forwarding or ordinary RRD handling.
\nThe Checkmk metric-backend guide describes a ClickHouse-based backend introduced for OpenTelemetry metrics in Checkmk Ultimate 2.5.0. The guide requires an enabled metric backend for OpenTelemetry metrics, while forwarding OpenTelemetry logs to the Event Console does not require it. In the documented distributed setup, native backend data and custom graphs stay at their source site; the guide separately permits special-agent-fed data in distributed monitoring. The documented telemetry retention is fourteen days and cannot be configured through Checkmk.
\nThis article follows the guide’s Checkmk Ultimate 2.5.0 native backend and custom-graph scope, not a promise about future versions or every metric-processing route. It does not establish a long-term archive, a capacity guarantee or legal retention suitability.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a metric-routing map naming the collector, receiving backend and intended operator view. Record the actual Checkmk edition and release with that map. Keep this design tied to the documented Ultimate 2.5.0 behavior and recheck the installed-release guidance rather than projecting the same restrictions onto every future version.
\nHave the monitoring and network owners choose the receiving site deliberately. Review whether the required view is local to that site or central, and resolve a mismatch before submitting important operational data. Do not describe multiple remote backends as a unified historical store without separate evidence of the intended architecture.
\nWrite the required historical interval beside the documented retention boundary. If the requirement is longer, obtain a separate supported data-retention design rather than promising that an undocumented configuration edit will extend this backend. Keep long-term evidence preservation and any licensing assessment under their own reviewed requirements.
\nSeparate metrics from log-forwarding requirements when reviewing the deployment. Confirm that the intended backend setting and site population fit the actual metric path. Use harmless representative inputs for the first trial and keep production rollout on hold while the viewing location or historical coverage remains unresolved.
\nProposed verification: in a representative approved test deployment, send an identifiable benign metric through the intended managed pipeline. Inspect its actual receiving site and the agreed operator view, preserving timestamps, site identity and observed labels. Check a remote and central view separately where they are part of the design.
\nCompare the observed placement with the routing map and the required historical interval with the current documented retention. Record an unperformed long-duration observation as unperformed; do not simulate historical retention by changing production clocks. Retain configuration and actual metric evidence without claiming universal forwarding, complete archival coverage or a measured capacity guarantee.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: For the documented Checkmk Ultimate 2.5.0 backend, account for remote-site metric silos and retention of fourteen days rather than assuming central forwarding or ordinary RRD handling.\nSource fact: what the authority says\nThe Checkmk metric-backend guide describes a ClickHouse-based backend introduced for OpenTelemetry metrics in Checkmk Ultimate 2.5.0. The guide requires an enabled metric backend for OpenTelemetry metrics, while forwarding OpenTelemetry logs to the Event Console does not require it. In the documented distributed setup, native backend data and custom graphs stay at their source site; the guide separately permits special-agent-fed data in distributed monitoring. The documented telemetry retention is fourteen days and cannot be configured through Checkmk.\nWhat the source does not establish\nThis article follows the guide’s Checkmk Ultimate 2.5.0 native backend and custom-graph scope, not a promise about future versions or every metric-processing route. It does not establish a long-term archive, a capacity guarantee or legal retention suitability.\nApplicability questions\n\nDoes the deployed edition and version match the guide’s Ultimate 2.5.0 scope?\nWhich site receives the intended OpenTelemetry metrics?\nWhere must operators view the resulting metrics and custom graphs?\nDoes retention of fourteen days meet the separately approved observation requirement?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a metric-routing map naming the collector, receiving backend and intended operator view. Record the actual Checkmk edition and release with that map. Keep this design tied to the documented Ultimate 2.5.0 behavior and recheck the installed-release guidance rather than projecting the same restrictions onto every future version.\nHave the monitoring and network owners choose the receiving site deliberately. Review whether the required view is local to that site or central, and resolve a mismatch before submitting important operational data. Do not describe multiple remote backends as a unified historical store without separate evidence of the intended architecture.\nWrite the required historical interval beside the documented retention boundary. If the requirement is longer, obtain a separate supported data-retention design rather than promising that an undocumented configuration edit will extend this backend. Keep long-term evidence preservation and any licensing assessment under their own reviewed requirements.\nSeparate metrics from log-forwarding requirements when reviewing the deployment. Confirm that the intended backend setting and site population fit the actual metric path. Use harmless representative inputs for the first trial and keep production rollout on hold while the viewing location or historical coverage remains unresolved.\nVerification and evidence\nProposed verification: in a representative approved test deployment, send an identifiable benign metric through the intended managed pipeline. Inspect its actual receiving site and the agreed operator view, preserving timestamps, site identity and observed labels. Check a remote and central view separately where they are part of the design.\nCompare the observed placement with the routing map and the required historical interval with the current documented retention. Record an unperformed long-duration observation as unperformed; do not simulate historical retention by changing production clocks. Retain configuration and actual metric evidence without claiming universal forwarding, complete archival coverage or a measured capacity guarantee.\nOfficial references\n\nCheckmk — The Checkmk metric backend — 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: For the documented Checkmk Ultimate 2.5.0 backend, account for remote-site metric silos and retention of fourteen days rather than assuming central forwarding or ordinary RRD handling.\n\n## Source fact: what the authority says\n\nThe [Checkmk metric-backend guide](https://docs.checkmk.com/latest/en/metric_backend.html) describes a ClickHouse-based backend introduced for OpenTelemetry metrics in Checkmk Ultimate 2.5.0. The guide requires an enabled metric backend for OpenTelemetry metrics, while forwarding OpenTelemetry logs to the Event Console does not require it. In the documented distributed setup, native backend data and custom graphs stay at their source site; the guide separately permits special-agent-fed data in distributed monitoring. The documented telemetry retention is fourteen days and cannot be configured through Checkmk.\n\n## What the source does not establish\n\nThis article follows the guide’s Checkmk Ultimate 2.5.0 native backend and custom-graph scope, not a promise about future versions or every metric-processing route. It does not establish a long-term archive, a capacity guarantee or legal retention suitability.\n\n## Applicability questions\n\n- Does the deployed edition and version match the guide’s Ultimate 2.5.0 scope?\n\n- Which site receives the intended OpenTelemetry metrics?\n\n- Where must operators view the resulting metrics and custom graphs?\n\n- Does retention of fourteen days meet the separately approved observation requirement?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a metric-routing map naming the collector, receiving backend and intended operator view. Record the actual Checkmk edition and release with that map. Keep this design tied to the documented Ultimate 2.5.0 behavior and recheck the installed-release guidance rather than projecting the same restrictions onto every future version.\n\nHave the monitoring and network owners choose the receiving site deliberately. Review whether the required view is local to that site or central, and resolve a mismatch before submitting important operational data. Do not describe multiple remote backends as a unified historical store without separate evidence of the intended architecture.\n\nWrite the required historical interval beside the documented retention boundary. If the requirement is longer, obtain a separate supported data-retention design rather than promising that an undocumented configuration edit will extend this backend. Keep long-term evidence preservation and any licensing assessment under their own reviewed requirements.\n\nSeparate metrics from log-forwarding requirements when reviewing the deployment. Confirm that the intended backend setting and site population fit the actual metric path. Use harmless representative inputs for the first trial and keep production rollout on hold while the viewing location or historical coverage remains unresolved.\n\n## Verification and evidence\n\nProposed verification: in a representative approved test deployment, send an identifiable benign metric through the intended managed pipeline. Inspect its actual receiving site and the agreed operator view, preserving timestamps, site identity and observed labels. Check a remote and central view separately where they are part of the design.\n\nCompare the observed placement with the routing map and the required historical interval with the current documented retention. Record an unperformed long-duration observation as unperformed; do not simulate historical retention by changing production clocks. Retain configuration and actual metric evidence without claiming universal forwarding, complete archival coverage or a measured capacity guarantee.\n\n## Official references\n\n- [Checkmk — The Checkmk metric backend](https://docs.checkmk.com/latest/en/metric_backend.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/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/", "url": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Choose the Checkmk metric-backend site before sending OpenTelemetry metrics", "item": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/#article", "identifier": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/", "url": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/", "headline": "Choose the Checkmk metric-backend site before sending OpenTelemetry metrics", "description": "Preserve the Checkmk Ultimate 2.5.0 backend’s site and retention limits when planning OpenTelemetry metrics.", "abstract": "Preserve the Checkmk Ultimate 2.5.0 backend’s site and retention limits when planning OpenTelemetry metrics.", "articleBody": "Bottom line: For the documented Checkmk Ultimate 2.5.0 backend, account for remote-site metric silos and retention of fourteen days rather than assuming central forwarding or ordinary RRD handling.\nSource fact: what the authority says\nThe Checkmk metric-backend guide describes a ClickHouse-based backend introduced for OpenTelemetry metrics in Checkmk Ultimate 2.5.0. The guide requires an enabled metric backend for OpenTelemetry metrics, while forwarding OpenTelemetry logs to the Event Console does not require it. In the documented distributed setup, native backend data and custom graphs stay at their source site; the guide separately permits special-agent-fed data in distributed monitoring. The documented telemetry retention is fourteen days and cannot be configured through Checkmk.\nWhat the source does not establish\nThis article follows the guide’s Checkmk Ultimate 2.5.0 native backend and custom-graph scope, not a promise about future versions or every metric-processing route. It does not establish a long-term archive, a capacity guarantee or legal retention suitability.\nApplicability questions\n\nDoes the deployed edition and version match the guide’s Ultimate 2.5.0 scope?\nWhich site receives the intended OpenTelemetry metrics?\nWhere must operators view the resulting metrics and custom graphs?\nDoes retention of fourteen days meet the separately approved observation requirement?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a metric-routing map naming the collector, receiving backend and intended operator view. Record the actual Checkmk edition and release with that map. Keep this design tied to the documented Ultimate 2.5.0 behavior and recheck the installed-release guidance rather than projecting the same restrictions onto every future version.\nHave the monitoring and network owners choose the receiving site deliberately. Review whether the required view is local to that site or central, and resolve a mismatch before submitting important operational data. Do not describe multiple remote backends as a unified historical store without separate evidence of the intended architecture.\nWrite the required historical interval beside the documented retention boundary. If the requirement is longer, obtain a separate supported data-retention design rather than promising that an undocumented configuration edit will extend this backend. Keep long-term evidence preservation and any licensing assessment under their own reviewed requirements.\nSeparate metrics from log-forwarding requirements when reviewing the deployment. Confirm that the intended backend setting and site population fit the actual metric path. Use harmless representative inputs for the first trial and keep production rollout on hold while the viewing location or historical coverage remains unresolved.\nVerification and evidence\nProposed verification: in a representative approved test deployment, send an identifiable benign metric through the intended managed pipeline. Inspect its actual receiving site and the agreed operator view, preserving timestamps, site identity and observed labels. Check a remote and central view separately where they are part of the design.\nCompare the observed placement with the routing map and the required historical interval with the current documented retention. Record an unperformed long-duration observation as unperformed; do not simulate historical retention by changing production clocks. Retain configuration and actual metric evidence without claiming universal forwarding, complete archival coverage or a measured capacity guarantee.\nOfficial references\n\nCheckmk — The Checkmk metric backend — 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:52+00:00", "dateModified": "2026-10-30T06:47:29+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/" }, "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/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Choose the Checkmk metric-backend site before sending OpenTelemetry metrics" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 533, "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 — The Checkmk metric backend", "url": "https://docs.checkmk.com/latest/en/metric_backend.html" } } ] } }