Live data from Hacker News

DataDog asked OpenTelemetry contributor to kill pull request

github.com

41–50 of 107 posts

Re: DataDog asked OpenTelemetry contributor to kill pull request

#41
post #24
post #5

Earlier quoted context omitted.

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 tog…

you may want to check out https://github.com/SigNoz/signoz

I am one of the maintainers. We are building a DataDog alternative with native support for opentelemetry.

Re: DataDog asked OpenTelemetry contributor to kill pull request

#42
More vendor lock-in shenanigans.

Data dog has always been a proprietary POS. I don’t know why people use it, APM traces? How long before Grafana has these capabilities in OSS?

So annoying seeing a company like DD who cannot innovate at all, trying to lock in the average company.

Re: DataDog asked OpenTelemetry contributor to kill pull request

#43
post #3
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?

This comment highlights my problem with singular project tracking issues. Once they get so massive like this, people suddenly "can't follow along". Though not specific to GitHub but in this case the ui hampers readability and the comments are very much in-the-moment. This then leaves me to ask the questions, (a) should we stop writing such mammoth comments in issues or (b) should we leverage generative AI to summarize a weekly or monthly timeline of issue interaction. What is the point of having historical issues if it's too complex to follow along? This was a question I regularly asked at GitHub that usually resulted in blank stares.

GitHub's own answer to this is to force engineers to use a /slash command to post a summary of the week's updates. Clunky, but it works.

Re: DataDog asked OpenTelemetry contributor to kill pull request

#45
post #24

Earlier quoted context omitted.

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 tog…

you may want to check out https://github.com/SigNoz/signoz I am one of the maintainers. We are building a DataDog alternative with native support for opentelemetry.

I have seen it around, but didn't know it was open source. If you guys are working on correlation, then I will definitely be watching this. Consistent link urls that can be shared is also useful.

Hopefully someone else will contribute the notebooks feature. Those are very useful.

Something that DD is not careful about, is being able to consistently use UTC for all time labels in all graphs (and maybe a quick way to convert to a local time if we need to communicate with stakeholders).

(I don't know why your comment was downvoted).

Re: DataDog asked OpenTelemetry contributor to kill pull request

#46
post #45

Earlier quoted context omitted.

you may want to check out https://github.com/SigNoz/signoz I am one of the maintainers. We are building a DataDog alternative with native support for opentelemetry.

I have seen it around, but didn't know it was open source. If you guys are working on correlation, then I will definitely be watching this. Consistent link urls that can be shared is also useful. Hopefully someone else will contribute the notebooks feature. Those are very useful. Something that DD is not careful about, is being able to consistently use UTC for all time labels in all graphs (and maybe a quick way to c…

Yeah, we are actively working on correlation. We have metrics, traces and logs in a single app - so we should be able to provide a seamless correlation.

Thanks for the point about Notebooks, we have not thought in detail on how people use that. Is it primarily to collaborate between team members when an incident happens or even when there is no incident, and you are analysing stuff

Re: DataDog asked OpenTelemetry contributor to kill pull request

#48
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.

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 somet…

I won't speculate on the top-level strategies of companies competing with another, so take this as a grain of salt.

From my perspective (maintainer, employed by a vendor), all of us who work for these different companies collaborate very well together. We all recognize that it's both technically tractable and fundamentally user-friendly to make instrumentation be a common standard that anyone can use to point at any of the OSS and commercial tools in this space. There's plenty to differentiate on with telemetry backends, querying experiences, API capabilities, data analysis tools and UX, etc. We have a long way to go to see this vision fully realized, but it's quite far along and I have no doubt we'll arrive at the right outcome here.

Re: DataDog asked OpenTelemetry contributor to kill pull request

#49
post #39
post #24

Earlier quoted context omitted.

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 tog…

> negotiated annual contract Maybe we are too small but Datadog is one of the few vendors which we haven't been able to negotiate down in years. The price has always been whats on the website. I honestly don't even mind, with some vendors it feels like you are on a basar and they always tell you that their final discountns had to get approval by the CEO.

I always tell people looking at Datadog to remember "DDDD" or "DataDog Don't Discount".

Compared to most Enterprise vendors it is a lot harder to get a discount from Datadog. Most vendors will give you 1/3 off just for signing a contract and committing to a spend, Datadog is not like that.

Post reply on HN