Datadog support is hot garbage, and for the amount of money I've sent them over the years they ignore feature requests and just DGAF about customers.
They're very hot on licensing though.
DataDog asked OpenTelemetry contributor to kill pull request
101–107 of 107 posts
Re: DataDog asked OpenTelemetry contributor to kill pull request
#102Re: DataDog asked OpenTelemetry contributor to kill pull request
#103Earlier quoted context omitted.
> It makes it easy to switch to a cheaper or better service with minimal lock-in 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.
Check out telemetryhub.com (admittedly I work here). We offer a free trial and don't charge per a seat.
I understand the need to charge money for things, but the $150 per month pretty much rules out any bootstrapped startups.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#104Earlier quoted context omitted.
Check out telemetryhub.com (admittedly I work here). We offer a free trial and don't charge per a seat.
I understand the need to charge money for things, but the $150 per month pretty much rules out any bootstrapped startups.
I wish I knew the right answer between "spin up a cloud VPS Linux server and run your own with Docker compose" and pay $150/mo for something like DataDog
Re: DataDog asked OpenTelemetry contributor to kill pull request
#105Earlier quoted context omitted.
When we switched off of AppSignal, since our instrumentation as deeply intertwined with our code, it took a while to change that over to Otel. But at least now, being Otel, theoretically if we want to change it to a different vendor, we can. If we were to change off of DD, and there is an otel collector that can accept DD APM spans, then we can switch now, refactor later. In practice, DD has a lot going for it that I…
Why sample otel spans and miss out on the important ones?
You can sorta have your cake and eat to too.
Firstly, not all spans are interesting. When 99.99% of your traffic is just going to serve up an HTTP 200 within your acceptable latency threshold, you don't need every one of those. You probably do want to keep 100% of error spans, or those where the root has a duration beyond a configured threshold. There's tools to be able to sample that way.
Secondly, there's ways to also attach your effective sample rate as metadata to spans, and if there's a backend that supports re-weighting counts based on that, you can still get accurate all-up counts of overall traffic.
Admittedly, OTel and many other backends don't have the best story for this yet. But it's getting better.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#106Earlier quoted context omitted.
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
> It makes it easy to switch to a cheaper or better service with minimal lock-in 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.
Add another exporter to the `otel-config.yaml` and if they support it properly that should literally be all it takes. That said, "if they support it properly" is exactly what otel is working on. It's super stable for a <v1 release but is still missing some features and polish imho that prevents it from getting the official v1 tag.
Re: DataDog asked OpenTelemetry contributor to kill pull request
#107Earlier quoted context omitted.
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 summariz…
but if you're actively working on a problem you're in it, and the comments probably make sense. coming in from outside via web search or shared link, yeah, it's probably hard to jump in without full context of the lead up to it. once the problem is fixed, do you really care that much after the fact and have moved on?
How do you manage historical context ?