Datadog is stupidly expensive for what it provides. Don't recommend and I hope something open kills it soon.
DataDog asked OpenTelemetry contributor to kill pull request
11–20 of 107 posts
Re: DataDog asked OpenTelemetry contributor to kill pull request
#12Tentative TLDR: It seems like DD pressured a contributor into not shipping a feature that would have made DD just another telemetry vendor. It seems like right now, data can flow IN datadog libraries/agents but not out. This PR would sort of allow data to flow OUT of datadog's libs/agents? And DD doesn't want that because it removes their lock-in power? Is this correct? This would be extremely crappy of Datadog.
> This PR would sort of allow data to flow OUT of datadog's libs/agents?
Yes.
This allows you to expose a Telemetry collector on the datadog agent port 8126[0], allowing you to collect Application Performance Monitoring (APM) traces from any APM-enabled datadog library[1].
If I had to guess, DataDog's argument is that they don't want you using the engineering hours they invest into their libraries to have DD do the heavy lifting of collecting APM traces and send the messages off to another service.
0: https://github.com/boostchicken/opentelemetry-collector-cont...
1: https://docs.datadoghq.com/tracing/#send-traces-to-datadog
Re: DataDog asked OpenTelemetry contributor to kill pull request
#13Tentative TLDR: It seems like DD pressured a contributor into not shipping a feature that would have made DD just another telemetry vendor. It seems like right now, data can flow IN datadog libraries/agents but not out. This PR would sort of allow data to flow OUT of datadog's libs/agents? And DD doesn't want that because it removes their lock-in power? Is this correct? This would be extremely crappy of Datadog.
None of the APM providers like New Relic, Data Dog, or Azure App Insights want a truly open ecosystem.
The only reason they support "Open" Telemetry is because they're worried about lock-in at the data sources.
For example, App Insights supports rich/structured telemetry via its proprietary SDK and various APIs. No open-source developer in their right mind would ever hard code such a proprietary dependency into something published under a truly open license.
Now that rich telemetry instead of simple text logging is starting to become an increasingly popular approach, the proprietary APM vendors got nervous that they would get "locked out" of the entire open source ecosystem, to be replaced by a data source that is open and not compatible with their proprietary sinks.
Hence Open Telemetry.
It was always about making the source open, not the sink.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#14Earlier quoted context omitted.
Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?
If I understand correctly, this is a receiver — which means you can take your existing DD instrumentation in their format and have it translated to OTel using this code. It lowers the switching cost to get off of DD.
They want to keep their agent secret.
Secret Agent Man...
Re: DataDog asked OpenTelemetry contributor to kill pull request
#15Datadog is stupidly expensive for what it provides. Don't recommend and I hope something open kills it soon.
[deleted]
Re: DataDog asked OpenTelemetry contributor to kill pull request
#16Datadog is stupidly expensive for what it provides. Don't recommend and I hope something open kills it soon.
Likewise for New Relic. Unfortunately OTel and everything similar doesn't remotely come close to the usability and ease of configuration that New Relic does. Not yet, anyway...
Re: DataDog asked OpenTelemetry contributor to kill pull request
#17Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
Thanks for the link. I didn't see it in first skim through. It was in hidden comments, and I had to go back and click a few before i found it.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#18Tentative TLDR: It seems like DD pressured a contributor into not shipping a feature that would have made DD just another telemetry vendor. It seems like right now, data can flow IN datadog libraries/agents but not out. This PR would sort of allow data to flow OUT of datadog's libs/agents? And DD doesn't want that because it removes their lock-in power? Is this correct? This would be extremely crappy of Datadog.
[deleted]
Re: DataDog asked OpenTelemetry contributor to kill pull request
#19Related, from Feb 2022, on what this is and why it's important: https://twitter.com/mipsytipsy/status/1494861690059759616
Re: DataDog asked OpenTelemetry contributor to kill pull request
#20Earlier quoted context omitted.
If I understand correctly, this is a receiver — which means you can take your existing DD instrumentation in their format and have it translated to OTel using this code. It lowers the switching cost to get off of DD.
Protect the moat at all costs!
It's worse than that, they want security through obscurity too. They feel like someone is inappropriately tinkering with the agent they want customers to install. It's open source: https://github.com/DataDog/datadog-agent ...but the downloads are behind a login: https://github.com/DataDog/datadog-agent#datadog-agent