Hacker News Reader

Comment by paulddraper | Hacker News Reader

The point of OTel is interoperability.

For example the author of the software instruments it with OTel -- either language interface or wire protocol -- and the operator of the software uses the backend of choice.

Otherwise, you have a combinatorial matrix of supported options.

(Naturally, this problem is moot if the author and operator are the same.)

View on HN

This is worthy of a bookmark. (If HN supported bookmarks.)

https://news.ycombinator.com/item?id=42658095#:~:text=favori... and then https://news.ycombinator.com/favorites?id=PeterCorless&comme...

Thanks! TIL.

You can favorite comments. (And posts.)

Interoperability with what?

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.

Interoperability with the other things your Otel Vendor is selling you. No two implementations are even remotely compatible, but they can all mostly scrape data from your Prometheus endpoints, so it's easy to migrate from useful software to their walled garden.

> to their walled garden

Am I detecting sarcasm or did I just bring my own?

I don't think there's any sarcasm there; Perhaps a wistful hope that behind one of those walls somebody's actually got a garden instead of just a seedbed of false promises.

Yarp.

Application Insights, Data Dog, New Relic, etc…

APM products in general.

How to send Prometheus data to New Relic: https://docs.newrelic.com/docs/infrastructure/prometheus-int...

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 simplifies the issue for applications and libraries that can support Otel and quickly integrate with whatever is being used to collect the data.

The whole idea of OTel is not to be a moat.

It's the exact opposite.

I can export traces (or metrics or logs) to whatever backend I want, and change easily.

You’re talking about a data moat, I’m talking about intellectual moats and intentional complexity, as opposed to accidental or essential complexity.

You're ignoring the oldest and most mature part of OTEL which is traces.

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.

interoperability between vendors, so your business isn't stuck with a vendor who can raise prices because their SDKs are deeply embedded in your codebase, so open source libraries / products have a common point to hook into without needing to integrate with each vendor.

> Interoperability with what?

For the backend?

Datadog, New Relic, Grafana, Sentry, Azure Monitor, Splunk, Dynatrace, Honeycomb

Aside from what others have mentioned (being interop on the send and receive side of things) I find a great deal of value in the interop schema, so you don't have to re-learn what every joker wants to name their special unicorn flavor of kubernetes pod name or container id or http response code when exploring metrics or making dashboards

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/...

Reply on news.ycombinator.com