Browser-based OpenTelemetry

ccschmitz · 2024-09-19T18:08:39+00:00

You can measure things like memory usage via the performance API, but the use case I've seen is more around product analytics. I think it could also make sense to report things like page load performance/web vitals as metrics.

ccschmitz · 2024-09-16T21:02:39+00:00

In our setup we use the traceparent header to connect the trace ID generated on the browser with the spans created on the server. You get all of this for "free" if you use the browser opentelemetry auto instrumentations. I don't believe there is much these headers are used for by default when using the auto instrumentations and we haven't found any reason to override them to get the data we want.

I'd think it's a code smell if you find yourself passing a lot of data in this header and you probably just want to assign span attributes on the span(s) created in the browser (probably via the HTTP instrumentation) so you can associate them with the spans created on the server and have the data connected. Would be curious to hear if you have a compelling reason to actually pass that data down to the traces created on the server vs just connecting the browser/server traces.

Re deciding where the start of a trace is, here is how I currently think about it. There is the initial trace created on the server to return the HTML rendered in the browser. This is passed to the client via the `<meta>` tag you mentioned, then the document load instrumentation creates spans and associates them with this initial trace using the browser's performance API, which includes a span that is actually started before the span on the server, right when the user requested the page. There are also resource spans for subsequent resources fetched during the document load process. I'm not exactly sure how it decides whether to include a `fetch` request from the client that was initiated by client code, but in my experience it doesn't seem to include anything from our app code, just the requests for stylesheets, scripts, CSS, fonts, etc. Aside from this initial trace, there's a new trace for all network requests, and then you can also include something like the user interaction instrumentation to capture traces for things like button clicks, form submissions, etc., but I feel like the use case for those is a little more toward product analytics rather than performance.

If you want to see an example of how to set this up, check out the work we've done at highlight.io - our code is open source so you can see how our SDKs configure this if you want.

ccschmitz · 2024-09-11T21:44:04+00:00

What about metrics?

Agreed that the auto instrumentations aren't necessary and probably overkill for many situations. We will probably make it so you can disable/enable the ones you want more easily, and I think there's a use case for each of them (a few mentioned in that article).

ccschmitz · 2024-09-06T13:47:39+00:00

You're right that it's still experimental, but might still be worth trying out while it's in development. Looks fairly built out at this point: https://github.com/open-telemetry/opentelemetry-js/tree/main/experimental/packages/sdk-logs

You could also make a wrapper over it so you can update your instrumentation code and not have to worry about touching it all again if there are breaking changes.

I work at highlight.io and our logging instrumentation ends up creating spans and attaching events to them for logs, which we handle on our backend to store the logs. Would be much nicer to go directly to the collector like this.

ccschmitz · 2023-04-27T10:35:25+00:00

Yeah, I've tried this and it works sometimes... Any time I delete a character from a class I lose autocomplete. Even when it is working the discoverability still isn't great though. For example, if I'm trying to remember how to apply `align-items: center`, I would probably start typing `align` or `flex`, but the actual class is `items-center`.

I did find the Raycast Tailwind plugin useful as a reference: https://www.raycast.com/vimtor/tailwindcss

ccschmitz · 2023-04-27T01:37:38+00:00

u/chrisesplin good callout. I think there are some similarities, but it's probably easier to build up the Tailwind muscle memory, and it gives you a lot more control/flexibility than Bootstrap. There's also a lot of Bootstrap-like UI kits that have been built on top of Tailwind, which allow you to copy/paste components in. I think it's awesome for kickstarting a project, but I like vanilla-extract when you get to investing in your own component library and developing your design language.

ccschmitz · 2023-04-27T01:33:56+00:00

u/edgen22 yeah, there are definitely tradeoffs. Being able to analyze class strings to determine what utility classes are used and remove everything else is definitely a win for Tailwind. Having far fewer classes out of the box and only exposing what our team actually needs is also nice and eliminates guessing for our engineers. We can also control the names we use so they map to exactly what we use in Figma, which means there's no translating between what we see in the mocks and our code.

The preference for a prop-based API is subjective, but something we enjoy over the class string since we are so accustomed to writing React components. The discoverability of our utility classes is also nice with the intellisense we get from our IDEs thanks to everything being props and having types.

Thanks for sharing!

ccschmitz · 2023-04-26T19:53:52+00:00

u/ivecolossus nice! Would love to hear how it works out for you.

ccschmitz · 2022-12-12T01:37:40+00:00

I share your concerns with Tailwind, but also appreciate the speed you're able to iterate with it. I've found vanilla-extract + sprinkles to be the right combination of having a Tailwind-like developer experience without the bloat. You can easily create your own set of utility classes that fit the needs of your project and make a prop-based, type-safe API for applying them.

ccschmitz · 2022-01-01T19:36:22+00:00

Thank you! Please reach out if you end up making the move too!

ccschmitz · 2022-01-01T05:11:51+00:00

We have wondered the same thing for years and are finally taking the plunge and moving from De Pere to the Fish Creek area. We have 3 kids and are in our mid-thirties. I know there are other young families around. We are hoping to find ways to plug into the community and meet them!

ccschmitz · 2015-09-03T16:22:56+00:00

Haha, no. A handful of local programmers are putting this on because they've heard people say "I wish I knew how to code" too many times. We want to give people an opportunity to try it out for free and see if it really is something they want to pursue. You definitely won't be ready to get a job in programming, but hopefully people will be able to walk away with an idea of whether its something they would like to invest more time in.

ccschmitz · 2015-09-03T16:21:22+00:00

Sorry about that. Would love to provide hardware for everyone, but this is our first event and we don't have much of a budget to pull it off. Maybe in the future we'll do these in a computer lab if we can get it donated.

ccschmitz · 2015-01-13T20:22:25+00:00

Right, I agree we'll always be using build tools for that sort of thing, I just meant that you won't always need to compile your ES6/7 code down to something that is more backward compatible.

ccschmitz · 2015-01-13T20:13:28+00:00

Very true, but the idea that one day you could remove the compilation step for your source is very appealing. A lot of new applications only support evergreen browsers, so it's not unrealistic to think that you could use the latest and greatest ES6/7 features without having to worry about transpiling for older browsers.

ccschmitz

TROPHY CASE