OTel has been slow as hell since release. we tried using it for tracing last week and the app was significantly slower.

We just use prometheus+grafana now. Yes, this technically also slows the app down, but OTel was unbearably slow.

I'm sure im doing a million and one things wrong, but i can't be arsed to set something up just to see some performance metrics. Deadlocks can be found using transaction metrics, that's all you need.

Edit: I now read in the comments the JS ver is a bad impl, I guess this might be part of the reason.

You might be able to use big telemetry vendor libraries for instrumentation. Iirc you can use ddtrace Python library and have it send to otel collector which will convert from DD span format to otel.

I haven't tried but it's probably possible to do the same with JS

I think Sentry was also expanding into tracing--might be worth a look to see if they're doing something that works better in their library

Would be curious about this in more detail since I’ve not normally seen a JS app be significantly slower due to adding autoinstrumentation over the years. There’s obviously an overhead but aside from the occasional bug I’ve never seen it be significant to impact user experiences or cost to serve.

That said if your goal is basic performance metrics and nothing more, then tracing is overkill. Don’t even need an SDK, just monitor the compute nodes async with some basic system metrics. But if your goal is to narrow down behaviors within your app on a per-request basis there really is no way around tracing if you value your sanity.

Say more about what you did to instrument? I am willing to bet architectural choices are that slowness, not OTel itself.