31–40 of 107 posts
Datadog is stupidly expensive for what it provides. Don't recommend and I hope something open kills it soon.
Earlier 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.
They want to keep their agent secret. Secret Agent Man...
Earlier quoted context omitted.
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.
Edit: I missed the environment variable before "curl". The .sh is downloaded without the API key but the rest could be done using the API key, since it is passed to the script.
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?
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
Got any examples?
I tried running my own "stack" for a project I wanted alerting on. I landed on Jaeger all-in-one (wasted time on Zipkin, the UI just was nowhere near as good as it ought to be) Docker container in docker-compose with COLLECTOR_OTLP_ENABLED.
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…
In practice, DD has a lot going for it that I don't see in New Relic. There are also some key features in DD that is not in OTEl -- for example, we can't use DD's APM ingestion controls for controlling sampling rates for OTEL spans, and DD has no incentive to add such a feature. I'm actually working on adding in Otel sampling into our project right now. (In our case, we have to use Otel because DD does not have SDKs for Elixir)
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…
datadogs APM traces are the one thing that locks companies into Datadog. If this is merged it makes it a lot easier to move out of datadog into something else.
Switching APM providers isn't hard at all. Maybe the Open Telemetry ecosystem lacks a good agent but my understanding is that their APM agent is pretty much already a copy of the Datadog agent.
I think New Relic would be a more interesting agent to use because their approach to APM isn't primarily to do sampled traces.
Datadog 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...
As it stands, this was/is trying to use DataDog's existing APM libraries to turn them into OTel for ingest into other providers.
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…
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.
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.