Where are the three existing, successful solutions it is trying to abstract over?
It doesn’t know what it is because it’s violating the Rule of Three.
Where are the three existing, successful solutions it is trying to abstract over?
It doesn’t know what it is because it’s violating the Rule of Three.
https://opentelemetry.io/docs/specs/semconv/general/attribut...
https://opentelemetry.io/docs/specs/semconv/hardware/common/
https://opentelemetry.io/docs/specs/semconv/system/container...
https://opentelemetry.io/docs/specs/semconv/system/k8s-metri...
https://opentelemetry.io/docs/specs/semconv/http/http-metric...
https://opentelemetry.io/docs/specs/semconv/cloud-providers/...
APM products in general.
How to send StatsD data to Datadog: https://docs.datadoghq.com/developers/dogstatsd/?tab=hostage...
Places like datadog and posthog are selling you their ability to ingest your existing data. I call bullshit. It’s a problem looking for a solution. It’s an excuse for engineers to build moats around a moderately difficult problem by making it inscrutable.
It's the exact opposite.
I can export traces (or metrics or logs) to whatever backend I want, and change easily.
If you look up how to send traces to any popular vendor the options are either a) use our proprietary for at and proprietary agents and SDKs, or b) use otel
Iirc metrics in OTEL are very similar to Prometheus. Haven't looked at logging but realistically logging becomes an afterthougt with a good tracing setup.
For the backend?
Datadog, New Relic, Grafana, Sentry, Azure Monitor, Splunk, Dynatrace, Honeycomb
Am I detecting sarcasm or did I just bring my own?