I got OpenTelemetry to work. But why was it so complicated?

Re:I got OpenTelemetry to work. But why was it so complicated? by ljm on Friday January 10, 2025 @12:53PM (#42657962)

The biggest barrier to setting up oTel for me is the development experience. Having a single open specification is fantastic, especially for portability, but the SDKs are almost overwhelmingly abstract and therefore difficult to intuit.

I used to really like Datadog for being a one-stop observability shop and even though the experience of integrating with it is still quite simple, I think product and pricing wise they've jumped the shark.

I'm much happier these days using a collection of small time services and self-hosting other things, and the only part of that which isn't joyful is the boilerplate and not really understanding when and why you should, say, use gRPC over HTTP, and stuff like that.

[ Parent | on HN ]

Re:I got OpenTelemetry to work. But why was it so complicated? by mdaniel on Friday January 10, 2025 @11:02PM (#42663178)

And having to rebuild a golang binary based on this horseshit just to get a bugfixed collector is some horseshit: https://github.com/open-telemetry/opentelemetry-collector/tr... which is required (as best I can tell) because they text/template in the deps https://github.com/open-telemetry/opentelemetry-collector/bl...

Heaven help you if it's a contrib collector bugfix

[ Parent | on HN ]

Re:I got OpenTelemetry to work. But why was it so complicated? by pdimitar on Saturday January 11, 2025 @02:21PM (#42668261)

You are generally correct but I've used https://github.com/openobserve/openobserve for several projects for dev-only complete OTel stack (dashboards included) and I liked it. There are better dashboards out there for sure, but for what I needed locally it did the job fantastically well. Zero complaints.

It's extremely easy to self-host, either on a dev machine, a VPS, or in any Docker-based PaaS.

[ Parent | on HN ]