# Choose the Checkmk metric-backend site before sending OpenTelemetry metrics > Preserve the Checkmk Ultimate 2.5.0 backend’s site and retention limits when planning OpenTelemetry metrics. - Canonical URL: https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:46:52+00:00 - Modified: 2026-10-30T06:47:29+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Preserve the Checkmk Ultimate 2.5.0 backend’s site and retention limits when planning OpenTelemetry metrics. ## Potentially affected The Checkmk Ultimate 2.5.0 metric-backend behavior described by the current official guide. ## DSE recommendation Review the receiving site, usable views and required retention before sending operational metrics. ## Article 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. ## Source fact: what the authority says The [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. ## What the source does not establish This 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. ## Applicability questions - Does the deployed edition and version match the guide’s Ultimate 2.5.0 scope? - Which site receives the intended OpenTelemetry metrics? - Where must operators view the resulting metrics and custom graphs? - Does retention of fourteen days meet the separately approved observation requirement? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE 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. Have 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. Write 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. Separate 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. ## Verification and evidence Proposed 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. Compare 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. ## Official references - [Checkmk — The Checkmk metric backend](https://docs.checkmk.com/latest/en/metric_backend.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 — The Checkmk metric backend - Authority: docs.checkmk.com - URL: https://docs.checkmk.com/latest/en/metric_backend.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose the Checkmk metric-backend site before sending OpenTelemetry metrics,” DSE Security, https://update.dsesecurity.com/updates/choose-the-checkmk-metric-backend-site-before-sending-opentelemetry-metrics/ 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.