Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
opentelemetry-collector-contrib
Contrib repository for the OpenTelemetry Collector (by boostchicken)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
signoz
SigNoz is an open-source observability platform native to OpenTelemetry with logs, traces and metrics in a single application. An open-source alternative to DataDog, NewRelic, etc. 🔥 🖥. 👉 Open source Application Performance Monitoring (APM) & Observability tool
Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
> 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], collecting it via its custom/proprietary trace/message format.
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 and send the messages off to another service.
DataDog's libraries don't seem to be OSS: https://github.com/DataDog/datadogpy/blob/master/LICENSE
0: https://github.com/boostchicken/opentelemetry-collector-cont...
Link to exact comment: https://github.com/open-telemetry/opentelemetry-collector-co...
> 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], collecting it via its custom/proprietary trace/message format.
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 and send the messages off to another service.
DataDog's libraries don't seem to be OSS: https://github.com/DataDog/datadogpy/blob/master/LICENSE
0: https://github.com/boostchicken/opentelemetry-collector-cont...
> 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], collecting it via its custom/proprietary trace/message format.
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 and send the messages off to another service.
DataDog's libraries don't seem to be OSS: https://github.com/DataDog/datadogpy/blob/master/LICENSE
0: https://github.com/boostchicken/opentelemetry-collector-cont...
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
you may want to check out https://github.com/SigNoz/signoz
We are building a DataDog alternative with native support for opentelemetry.
(PS: I am one of the maintainer)