OpenTelemetry is free; the collector fleet, the retention policy and the on-call rota are not

A post on devops.com makes the case that OpenTelemetry's real cost lands after the SDKs are wired up, and then lands on a recommendation: ManageEngine's OpManager Nexus, which the post says ingests OTel traces, metrics and logs natively so teams do not run their own collector and storage layer ^[15][12]. The provenance is obvious, and the accounting is still the one to bring to next year's platform headcount conversation, because the free part of OTel is the framework and the expensive part is operating it ^[3].

The original problem was real. Before OTel, each APM vendor shipped a proprietary agent, so changing vendors meant re-instrumenting every service; OTel let teams emit traces, metrics and logs once and route them anywhere ^[1][2].

What that neutrality does not include is a place to put the data. OTel specifies how telemetry is generated and transported, not where it lives, so teams end up selecting and running a backend: typically a trace store, a time-series database for metrics, and a log index, plus the queries and dashboards that make any of it usable ^[5]. In front of that sits a collector deployment, usually per region or per cluster, with batch and memory limiter settings to tune and a real risk of the collector itself becoming the bottleneck under load ^[4]. That is at least four independently versioned operational surfaces to own and patch ^[1], and the post's own description of upgrades across that chain is "a coordination exercise" ^[6].

The part that most often gets budgeted as zero is correlation. Telemetry arriving in three systems does not by itself let an engineer move from a slow span to the log line or the query that caused it, and building that layer is continuous work as schemas evolve ^[7]. The post is specific about why this matters during an incident: a trace tells you which service is slow, not whether the cause was a missing database index, a downstream API timeout or a host resource constraint ^[11]. It reports that after two years the labor concentrates in three places, keeping collectors healthy under changing load, keeping storage and indexing performant as volume grows, and rebuilding correlation logic every time a service boundary moves ^[10], with initial instrumentation described as the easy part ^[16].

Two costs follow from that and are structural rather than optional. On-call moves inside: with a managed platform a vendor's SRE team is paged when ingestion breaks, and with a self-run stack it is usually the same engineers who were supposed to be using the telemetry ^[8]. And OTel semantic conventions and SDKs still move quickly, so staying current across every instrumented service, particularly in a polyglot estate, consumes hours every quarter that no headcount plan lists ^[9].

The post does not claim self-hosting is wrong. It says the architecture is legitimate for teams with the platform engineering capacity to run it, that the cost scales with services, languages and regions instrumented ^[13], and that self-hosting still wins with mature platform practices, a compliance reason to own the storage layer, or deep enough Kubernetes-native maturity ^[14].

Worth watching: whether your OTel line item has named engineers attached to collector health, retention policy and correlation upkeep, or whether those hours are being absorbed silently by the people meant to be fixing applications ^[8][10]. And if you take the managed trade, check which surface stays neutral. The instrumentation does; ingestion, correlation and root cause analysis move to the vendor ^[12].