There is an un-marketed reality: OTel is not simple. The learning curve is steep, the documentation can be a maze of specs, and the SDKs (especially for metrics and logs) can feel over-engineered. You will get frustrated.

▲

pas 2 days ago | parent | next [-]

the problem is not simple either, and the same (or very similar) SDKs are used by the very fancy platforms too, no?

compared to dumping logs to a file (or a single instance Prometheus scraping /metrics) everything is frustrating, because there are so many moving parts anyway, you want to query stuff and correlate, but for that you need to propagate the trace id, and emit and store spans, and take care to properly handle async workers, and you want historical comparisons, and downsampling for retention, and of course auto-discovery/registration/labeling from k8s pods (or containers or whatever) and source code upload and release tagging from CI, and ...

▲

arccy 2 days ago | parent [-]

nearly all the sdks are wild pieces of overengineering designed to conform to a design-by-committee api that's native to no language.

half the things you list aren't even part of the sdks, they're part of the collector.

	▲	pas 2 days ago \| parent [-]
		yes, and that's why it's usually better to put the spans where you actually need them instead of depending on monkey patching. still, it's the same whether you use DataDog or Sentry (or OTel).

▲

secondcoming 2 days ago | parent | prev [-]

The C++ SDK is a masterpiece of over-engineering.

	▲	pan69 2 days ago \| parent [-]
		So is the JavaScript/TypeScript one. Very steep learning curve, very fragmented but clearly also very powerful once you know how to use it.