OpenTelemetry solved a real problem. Before it, every APM vendor had you install a proprietary agent, which meant switching vendors meant re-instrumenting everything. OTel gave engineering teams a vendor-neutral way to generate traces, metrics, and logs once and send them wherever they wanted.
That part of the pitch is true, and open-source deserves credit for it. What gets left out of most OTel adoption conversations is what happens after the SDKs are wired up. The framework is free. Running it well is not.
The Pain Points That Show Up After Rollout
Collector sprawl. A production OTel deployment usually means running collector instances per region or per cluster, tuning batch and memory limiter settings, and watching for the collector itself becoming a bottleneck under load. This is the infrastructure your team now owns and patches, on top of the infrastructure it was supposed to help you monitor.
Storage and retention decisions become your job. OTel defines how telemetry is generated and transported, not where it lives. Teams end up choosing and operating a backend, commonly a trace store, a time-series database (TSDB) for storing and querying metrics over time, and a log index, then building the queries and dashboards to make that data usable. Every version upgrade across that chain is a coordination exercise.
Cross-signal correlation requires continuous engineering. Traces, metrics, and logs arriving in three different systems does not automatically mean an engineer can jump from a slow span to the exact log line or the query that caused it. Building that correlation layer, and keeping it working as schemas evolve, is ongoing engineering work, not a one time setup.
The on call burden shifts internally. With a managed platform, a vendor’s SRE team is paged when ingestion breaks. With a self-run OTel stack, it’s usually the same engineers who were supposed to be using the telemetry to fix application problems, not maintaining the pipeline that delivers it.
Upgrade churn. OTel semantic conventions and SDKs still move quickly. Staying current across every instrumented service, especially in a polyglot environment, is recurring work that never shows up in a headcount plan but consumes real hours every quarter.
None of this means self-managed OTel is a bad choice. For teams with the platform engineering capacity to run it well, and a real need for full control over the pipeline, it’s a legitimate architecture. The honest accounting is that free software still has a labor cost, and that cost scales with the number of services, languages, and regions you’re instrumenting.
Where the Labor Actually Goes
Ask any team that’s run this for two years and the pattern is consistent. Initial instrumentation is the easy part. The ongoing cost lives in three places, keeping collectors healthy under changing load, keeping the backend’s storage and indexing performant as volume grows, and rebuilding correlation logic every time a service boundary changes.
That last one matters most for incident response. A trace showing high latency in one service tells you where. It doesn’t tell you whether the cause was a missing database index, a downstream API timeout, or a resource constraint on the host. Getting from where to why usually requires stitching context across systems that weren’t designed to talk to each other, which is exactly the work a managed backend takes off your plate.
What a Converged Platform Changes
ManageEngine’s OpManager Nexus accepts OpenTelemetry data natively. Teams keep their existing OTel instrumentation and export traces, metrics, and logs directly to the platform without operating a separate collector and storage layer. The platform handles ingestion, correlation, root cause analysis, real user monitoring, and anomaly detection on top of that same OTel data, so the instrumentation investment a team already made doesn’t get thrown away.
That’s the actual trade being made. You keep the vendor-neutral instrumentation layer that makes OTel valuable in the first place. You hand-off the operational weight of running collectors, tuning storage, and building correlation logic, which is the part that consumes engineering hours long after the initial rollout is done. But that trade isn’t free of its own limits.
Where Self Hosting Still Wins
Teams with mature platform engineering practices, a specific compliance reason to own the storage layer, or deep enough Kubernetes native maturity that a collector fleet is just another workload they already know how to run, will find a managed backend more constraining than a stack they built themselves. Sampling logic, retention policy, and pipeline level customization go deeper in a self-hosted setup than any managed platform will expose. The community exporter and processor ecosystem around OpenTelemetry is also larger than what a single vendor surfaces natively, simply because it’s not bounded by one company’s roadmap.
So the decision isn’t open-source versus managed, it’s where you want your engineering hours to go. Every team instrumenting with OTel already made the right call on the instrumentation layer. The question worth revisiting is whether the collector, storage, and correlation work sitting underneath that instrumentation is still the best use of the team’s time, or whether it’s become a second job nobody signed up for.
If you’re already running OTel instrumentation and want to see what happens when that same data feeds into a platform that handles ingestion, correlation, and root cause analysis for you, setup OpManager Nexus within minutes without re-instrumenting anything you’ve already built.
from DevOps.com https://ift.tt/S6pomcB
Comments
Post a Comment