TL;DR: You gain one instrumentation API, shared semantic conventions and a neutral collector that becomes your chokepoint; you lose dashboard parity during migration and gain a new piece of critical infrastructure. Keep vendors by making them replaceable: SDKs emit OTLP to your collectors, backends compete at the export hop.
How to approach it
Frame what OpenTelemetry actually standardises (API, SDK behaviour, OTLP wire format, semantic conventions) versus what it does not (backends, dashboards, pricing). Then answer the three parts in order: gains, breakage, vendor strategy. The middle part is where credibility lives.
A strong answer
What consolidation buys. Instrumentation converges on one API across traces, metrics and logs, so adding a library means learning it once. Semantic conventions mean http.server.request.duration (server) and http.client.request.duration (client) means the same thing in all forty services, which is what makes cross-service queries possible at all; today every agent renames the same concepts. The collector gives you a vendor-neutral processing tier: receive OTLP, batch, tail-sample, redact, then export anywhere. Switching backends becomes a config change at the exporter rather than a forty-repo re-instrumentation project. That reverses the lock-in direction: today switching costs are paid in application code, afterwards they are paid in pipeline configuration.
What breaks, concretely.
-
The collector becomes critical infrastructure. Its outage silences telemetry fleet-wide, so it ships as an agent (per node or per pod, buffered to disk) plus optional gateway tiers for sampling and enrichment. Teams that deploy one central collector with no buffering learn this lesson during their first incident.
-
Auto-instrumentation coverage is uneven. Vendor agents ship years of framework-specific magic; OTel auto-instrumentation covers common libraries but your internal RPC layer gets manual spans, and someone must write them.
-
Cardinality surprises. Unified conventions meeting high-label defaults (user IDs as metric labels being the classic) can inflate backend bills mid-migration. Metric naming review belongs in the rollout.
-
Dashboards regress before they improve. Every team's existing boards query vendor-specific fields. Until semantic conventions land, golden dashboards break quietly. Plan equivalent populations and histogram resolution before comparing p99 and error counts; semconv migration can change attributes and units.
-
Version churn across forty repos. SDK APIs evolve; without a shared platform library (one module teams import), you will run six SDK generations simultaneously and debug version-specific behaviour.
Migration shape that works. Pilot two services, one easy and one gnarly. Prefer one instrumentation pipeline exporting to both backends, or isolate pilot cohorts. Running two auto-instrumentation agents can create duplicate spans or conflicting hooks. Compare metric names, units, temporality, semantic-convention versions and sampling before interpreting parity differences. Then flip services in batches, keeping dual-shipping only where the numbers disagree. Budget honestly: dual-shipping costs money, so time-box it per batch rather than leaving everything doubled indefinitely.
The vendor question deserves cynicism handled politely. Backends now ingest OTLP natively because refusing stopped being viable. Your negotiating position improves specifically because export is now configuration; renewals become real competitions. Keep whatever proprietary capability earns its place (a specific APM UI, RUM, profiling) as a conscious purchase rather than an accident of instrumentation. The failure mode to avoid: rebuilding vendor lock-in inside collector processors with proprietary transforms nobody else can read.
What interviewers probe next
"Why not skip agents entirely and send straight to the backend?" Then sampling, enrichment and provider choice re-enter application config, which is the coupling you just removed. The collector is the architecture; the backend is a detail.
"Who owns the collector tier?" Platform, with an SLA like any Tier-1 dependency, because forty teams' blind spots trace to it otherwise.
"What about logs?" Same pattern: SDK log bridge to OTLP works, but many shops keep logging where it is initially and converge later. Sequencing beats completeness.
Common mistakes
Lifting vendor-specific processors into your gateway unchanged. You inherit the cost and keep the lock-in, just relocated.
Boiling the ocean: forty services converted before parity proof. The first silent dashboard regression ends executive patience.
Treating semantic conventions as documentation. They are the actual interoperability layer; enforcing them in CI is what makes cross-service queries real.
References