I tried to introduce OTel in a greenfield system at a large Canadian bank. Corporate IT pushed back hard because they'd heard a lot of "negative feedback" about it at a Dynatrace conference. No surprises there.
Corporate IT were not interested in reducing vendor lock-in; in fact, they asked us to ditch the OTel Collector in favour of Dynatrace OneAgent even though we could have integrated with Dynatrace without it.
It's not uncommon to see misalignment in large corporations like that. A year or so ago, Datadog field teams were explicitly creating FUD over OTel ("it's unstable, unusuable" all the same crap) while at the same time ramping up some of their efforts to contribute to OTel and make their own product experiences with OTel data better. They (and perhaps also Dynatrace) have an entire field org trained on the idea that their proprietary tech is inherently better and nothing in the open will be able to compete with it.
Also, to say OTel threatens these proprietary agents would be an understatement. The OTel Java agent comes with 100+ OOTB integrations right now. If I were a Dynatrace sales leader and I know that we sunk a ton of cost into creating our own stuff, I'd be casting FUD into the world over OTel too.
Similarly, this article starts with this weird disclaimer:
>We realize, however, that [vendor] neutrality can have its limits when it comes to real-world use cases.
Dynatrace is a leading contributor to the OpenTelemetry project. It supports OTLP traces, metrics, and logs and offers a supported OpenTelemetry Collector distribution with receivers for signals like StatsD and Prometheus. By investing in OpenTelemetry, Dynatrace can focus more on analytics and less on data collection. This is Dynatrace's long-term strategy.
In the short term (at least the next 18 months), data collection decisions remain important, especially for vendors like Dynatrace that provide added value beyond standard trace views, golden signals, alerting, and dashboards. Organizations need to think about these instrumentation choices on a workload-by-workload, and team-by-team basis.
Choosing between OneAgent and OpenTelemetry instrumentation is pretty straightforward. Teams use OpenTelemetry to send observability signals to more than one backend. Teams use OneAgent for its added value, such as deep code-level insights in the context of traces or performance anomalies.
Over time, these decisions will become less critical as data collection becomes more of a commodity.
Full disclosure: I am a Dynatrace Product Manager.
> they'd heard a lot of "negative feedback" about it at a Dynatrace conference
It's funny because Dynatrace fully support OpenTelemetry, even having a distribution of the OpenTelemetry Collector.