Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DataDog asked OpenTelemetry contributor to kill pull request

github.com

Post reply on HN
Print view View original

21–30 of 107 posts

Re: DataDog asked OpenTelemetry contributor to kill pull request

#21

Post by cmeacham98 »

judge2020 wrote: post #12
AYBABTME wrote: post #7

Tentative 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 h…

> DataDog's libraries don't seem to be OSS: https://github.com/DataDog/datadogpy/blob/master/LICENSE

Is that not a verbatim the 3-clause BSD license (which is an FSF/OSI approved OSS license)?

Re: DataDog asked OpenTelemetry contributor to kill pull request

#22

Post by [deleted] »

judge2020 wrote: post #12
AYBABTME wrote: post #7

Tentative 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 h…

[deleted]

Re: DataDog asked OpenTelemetry contributor to kill pull request

#24

Post by hosh »

xen2xen1 wrote: post #5
icepat wrote: post #3

Earlier quoted context omitted.

Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?

Wondered the same. Assume this is a threat to their business? An open source competitor can do something cool so they want to kill the functionality?

We use DD, and we have to use Otel for our Elixir apps to ingest spans into DD because there are no DD SDKs for Elixir or Erlang.

From the perspective of a customer, I can tell you that DD already has quite a bit of a moat. Their main competitive advantage, and what got us into using it, is being able to correlate data across APM, custom metrics, and logging through the use of tagging. They then densely link data together across the platform. There is also a built-in Jupyter-style notebooks. By correlating data like that, you get more value out of ingesting as much data into DD as you can. There are some additional services we're not using, such as auto-correlation with ML (and alerting for anomaly detection), and security monitoring that also looks across the entire platform using their ML tech.

Like AWS/GCP/Azure, it can get expensive, quite fast, using on-demand pricing, so there are negotiated annual contracts. Right now, our team is small, and to replicate the functionality we do use, using self-hosted open-source tooling, we might as well hire another engineer for just setting up and maintaining such a platform.

I get it that, you want to defend the moat and that eroding the little things can lead to eroding the big things. As I see it though, if you need those correlations, you'll need a certain scale and team size before it makes sense to build out something like that for yourself.

Re: DataDog asked OpenTelemetry contributor to kill pull request

#25

Post by aeyes »

judge2020 wrote: post #12
AYBABTME wrote: post #7

Tentative 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 h…

The library you linked is just for sending metric data (gauges, counters etc), the relevant library for APM is called ddtrace and its dual licensed with Apache2 and BSD3.

https://github.com/DataDog/dd-trace-py/blob/1.x/LICENSEe

Re: DataDog asked OpenTelemetry contributor to kill pull request

#26

Post by blibble »

judge2020 wrote: post #12
AYBABTME wrote: post #7

Tentative 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 h…

that LICENSE of theirs is literally 3 clause BSD?

Re: DataDog asked OpenTelemetry contributor to kill pull request

#28

Post by judge2020 »

benatkin wrote: post #20
xen2xen1 wrote: post #10

Earlier quoted context omitted.

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

Not really - the script it gives you in-app is

  DD_API_KEY= DD_SITE="datadoghq.com" bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"
They tell you to sign in because installing without a key leads to non-working agents and support tickets.

As for the libraries themselves, they're all on the regular package manager for that language, eg. pypi.

Re: DataDog asked OpenTelemetry contributor to kill pull request

#30

Post by ren_engineer »

icepat wrote: post #3
raybb wrote: post #2

Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...

Not sure I entirely follow what's going on here. Is there some context behind this that's useful to know?

OpenTelemetry basically allows for vendor neutral instrumentation for your metrics, logs, and traces. It makes it easy to switch to a cheaper or better service with minimal lock-in, which is obviously bad for DataDog and other companies business model
Post reply on HN