Why standardize on OpenTelemetry, and when is the instrumentation cost worth it?
Whether you treat telemetry as an architectural decision about lock-in and control, or as a tool checklist. They want to hear when the standardization payoff justifies the cost, and when it does not.
OpenTelemetry is the CNCF vendor-neutral standard for emitting traces, metrics, and logs through one set of SDKs and the OTLP wire format. I'd standardize on it for the architectural payoff: instrument once, then route anywhere from a central Collector, so swapping Datadog for Grafana, or sending to two backends at once, is a config change, not a re-instrumentation project. The cost is real, you rewrite instrumentation and run Collector infrastructure, so I justify it where I expect to outlive a vendor contract or run a polyglot fleet. For a single small service on a tool I'm happy with, I'd wait.
Instrument once, route anywhere.
- What does OTLP actually give you over a vendor protocol?
- Agent per host, sidecar, or gateway Collector?
- Are OTel logs production-ready, or stick with an existing pipeline?
In the book this question runs three pages: it adds a deep dive with a diagram, a decision framework, a pitfalls table and a worked answer to each follow-up.