3 ms·

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

renke1 3y ago
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-asynclocalstorage https://nodejs.org/api/async_context.html#class-asynclocalst... to be implemented in the browser.
- vmarchaud 3y ago
  You can follow [0] which is currently stage 2 to fix this [0]: https://github.com/tc39/proposal-async-context https://github.com/tc39/proposal-async-context
  - renke1 3y ago
    Thanks! I was only aware of a Zones proposal which was withdrawn I think.
  - no_wizard 3y ago
    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-management https://github.com/tc39/proposal-explicit-resource-managemen... [1]: https://www.totaltypescript.com/typescript-5-2-new-keyword-using https://www.totaltypescript.com/typescript-5-2-new-keyword-u...
pranay01 3y ago
Do check this doc from Otel https://opentelemetry.io/docs/instrumentation/js/getting-started/browser/ https://opentelemetry.io/docs/instrumentation/js/getting-sta... It is not completely solving the issue, but a starting point
- no_wizard 3y ago
  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
jauntywundrkind 3y ago
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?
- no_wizard 3y ago
  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
nijave 3y ago
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.
mikeshi42 3y ago
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-tracing-with-opentelemetry https://www.hyperdx.io/blog/browser-based-distributed-tracin...

renke1 3y ago

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-asynclocalstorage https://nodejs.org/api/async_context.html#class-asynclocalst... to be implemented in the browser.

vmarchaud 3y ago
You can follow [0] which is currently stage 2 to fix this [0]: https://github.com/tc39/proposal-async-context https://github.com/tc39/proposal-async-context
- renke1 3y ago
  Thanks! I was only aware of a Zones proposal which was withdrawn I think.
- no_wizard 3y ago
  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-management https://github.com/tc39/proposal-explicit-resource-managemen... [1]: https://www.totaltypescript.com/typescript-5-2-new-keyword-using https://www.totaltypescript.com/typescript-5-2-new-keyword-u...

pranay01 3y ago

Do check this doc from Otel https://opentelemetry.io/docs/instrumentation/js/getting-started/browser/ https://opentelemetry.io/docs/instrumentation/js/getting-sta... It is not completely solving the issue, but a starting point

no_wizard 3y ago
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

jauntywundrkind 3y ago

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?

no_wizard 3y ago
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

nijave 3y ago

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.

mikeshi42 3y ago

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-tracing-with-opentelemetry https://www.hyperdx.io/blog/browser-based-distributed-tracin...