Comment by no_wizard | Hacker News Reader

Comment by no_wizard | Hacker News Reader

The OTEL official project libraries don't work well on the web frontend yet. No way of correlating errors to source-maps for instance, at least out of the box.

The web browser collector published by the OTEL project uses Zone.js to hijack just about everything in the browser into contexts. If you used modern Angular before, you may recognize zone.js, its a real pain sometimes, and messes with globals, which isn't great, as it can create situations where behavior isn't predictable.

I don't know that OTEL has any standard around things like session replays either. Lots of telemetry platforms support this (Sentry, Rollbar, DataDog etc)

I think alot of backend teams have really like it. I do like the cross boundary nature of spans where you can follow them by a unique tag across your entire system.

I personally find its extremely verbose at times, in terms of the payload it generates, some logging platforms are more compact in this regard, but in practice, I haven't noticed it to be an issue

I think with native Promises (and async/await?) there is currently no way to implement something like Zone.js properly. I've tried to instrument my code manually, but it's really error-prone and verbose. We really need something like https://nodejs.org/api/async_context.html#class-asynclocalst... to be implemented in the browser.

You can follow [0] which is currently stage 2 to fix this

[0]: https://github.com/tc39/proposal-async-context

Thanks! I was only aware of a Zones proposal which was withdrawn I think.

In addition to this, is the new (stage 3 even!)explicit resource management proposal[0], supported by TypeScript version >= 5.2[1]

Though I agree that async context is better fit for this generally, the ERM should be good for telemetry around objects that have defined lifetime semantics, which is a step in the right direction you can use today

[0]: https://github.com/tc39/proposal-explicit-resource-managemen...

[1]: https://www.totaltypescript.com/typescript-5-2-new-keyword-u...

We've found that across most platforms, Otel is more of a starting point to building good instrumentation libraries. We've been building on top of Otel/Splunk's browser SDK implementation for our package [1] which does roll in session replay, and also adding on better exception tracking, etc. None of which remotely comes out of the box unfortunately.

Being able to connect frontend sessions -> backend trace/logs has been a huge DX change though imo.

[1] https://www.hyperdx.io/blog/browser-based-distributed-tracin...

Do check this doc from Otel https://opentelemetry.io/docs/instrumentation/js/getting-sta...

It is not completely solving the issue, but a starting point

this is exactly what I referencing, its not really a starting point. I read through all the docs quite thoroughly, these are missing features and design choices

DataDog's front end instrumentation (Real User Monitoring) is also notably unrefined. Playing with Duplo blocks level of finesse.

Does anyone have an even part way start at doing front end tracing?

As with most of the DataDog platform, I have found that once you go underneath the sheen it leaves alot to be desired.

I've had better runs with Bugsnag for pure error reporting and more recently Sentry, which can do RUM / Session Replay collections.

None are what you expect though. If you want really good user behavior analytics FullStory is still top notch

Have you come across Grafana Faro at all? You can have it send to Grafana Agent which is OSS and can store traces in other locations.

Reply on news.ycombinator.com