Coming soon to a browser near you: OpenTelemetry panel recap

Ted Young

On the challenge of modeling sessions and understanding user behavior: “I think that it just comes down to correlations. At the end of the day, what we’re trying to do when we’re observing things is you have something you care about, something that’s taking way too long or an error or some problem. You’re starting with a problem and then you want to know what correlated with that problem. […] There’s one way of framing it is like we’re just trying to reconstruct everything the user might ever do. And that’s a very complicated thing. That’s why it’s hard to figure out. But if you look at it from the perspective of, like, we’re trying to find correlations from the perspective of an operator trying to improve the product. I think that gives us maybe the right scoping for what we’re trying to solve.”

On OpenTelemetry’s goal of a unified system of telemetry: “Traditionally, RUM, client observability, browser, mobile, like these are all separate things. And then even on servers, you know, like tracing, metrics, and logs were like totally separate siloed systems. All of these things were totally separate products that were kind of end-to-end unified. And what we’re trying to do is rearrange that and say you have a unified telemetry system. So it’s the same data model across everything. So you could take all of this browser data and shovel it into any kind of backend system. It doesn’t need to go into some kind of specialized RUM product to be useful.”

Martin Kuba

On what the Browser SIG will be working on: “We know that we have issues or constraints with the size of the [OpenTelemetry JS SDK] package and some performance issues potentially. So that’s one thing. But I think we want to focus on getting something out there fairly quickly and get feedback from the community, and then iterate on that. So I think that would include building some core instrumentations that are missing, that have been missing, that maybe prevent users from jumping in and trying things out.”

On the challenge of modeling user sessions: “I think one thing that’s challenging about sessions is that we have been talking about how do we model sessions? Sessions are something that applies, it’s almost like a resource that applies to all signals that are being collected in the browser. And the session is something that ties like many different events and many different traces or spans together. So we want to think about sessions as a resource. And it’s also interesting because sessions span page loads. When a page loads, the SDK initializes. And typically, on the backend, the lifetime of the SDK is constrained to last a long time.”

Purvi Kanal

On how the browser’s event-driven system is different from a distributed tracing system: “What’s challenging with the browser is instead of going from this distributed tracing system, you go to an event-driven system with multiple inputs. So here we don’t just have one input. You kind of have multiple. You have the user is doing something. You’re clicking around in the browser. You’re scrolling. Users are creating hundreds and hundreds of events, even like hundreds of events per second. […] And then you just have, like, whatever is going on in the browser itself. So there’s many, different inputs that are not totally related to each other in a perfect way through a trace ID, especially as we go into, like, asynchronous JavaScript. And browsers are all about just an event loop, just responding to all of the event listeners that these inputs are. So it’s not super well designed to be perfectly traced because where does the trace start and where does the trace end is one of the first things that I think like we got stuck on as we were talking about it.”

On the challenge of context propagation across async boundaries in the browser: “If you are thinking about context propagation across something like an async boundary, you will have to use a library called zone.js to do that, which I think is a tough sell because it’s huge. It comes in at like a megabyte by itself. And it’s also not super well-maintained. And it doesn’t work for async-await anyway. So it might be better to kind of let that go and tie things together through sessions instead of these perfect traces that encompass an entire session, which is the world we want to move towards anyway. And so I think it is possible. You can get in there and play around with it. There is some instrumentation. There’s network request instrumentation, document load stuff. And there is going to be more stuff coming out.”

Jared Freeze

On the challenge of measuring the user’s experience on a website: “How do people think about this? If, again, you’re going to the same domain over and over again, should that be included in the experience? Or how do you put these things together? How do they map across the real world, how people are really using stuff? Because it’s not just going to be, I’m on a page, measure everything, I navigate, and then I start over. It’s not how a person would think about it. So how do you measure that?”

On why web developers should use OpenTelemetry’s console exporter: “Yeah, I was going to say one thing that really helped me while I was getting familiar with the space was the console exporter. So you could run the libraries and not need an endpoint. You don’t have to start there. You can run in the browser. You can see everything that’s emitted in a well-structured way and be, like, OK, cool, I have the right attributes. I did the right thing. I named this properly. Or I’m doing punctuation correctly for naming keys, whatever it might be. And you can not have to necessarily go and worry about the backend, like right out of the gate.”

Favorite answer on what’s challenging about using OpenTelemetry in the browser

Martin Kuba: “One of the challenges is that there are many different types of web applications out there, and they have different needs. So some applications might be okay with maybe a little bit bigger bundle size if they want to care about more signals or getting more data.

“Whereas some applications just really care about the smallest bundle size as possible because the speed of the page load is the most important thing. So I think, from my perspective, is as we’re moving away a little bit from span-based instrumentations to event-based instrumentations, I’m hoping that can make the bundle size smaller.

“Or at least give users the option of, if they want to collect only certain events, they don’t have to include the tracing SDK. They can just include the log SDK. The tracing is challenging as far as bundle size, because the API and SDK is larger and more complex, but also because there is context management that needs to help.

“That needs to happen, and we use a third-party library for context management that also adds to the size of the bundle. I think just again, I think from my perspective, giving users the flexibility to choose what they want to include in their bundle is one part. And then the other part is making updates to the existing JavaScript SDK to make it possible to do some tree shaking.”

Favorite answers on why web developers should try out OpenTelemetry

Purvi Kanal: “Right now, OpenTelemetry really connects your browser traces to your backend traces like no other system does. And that in itself is a pretty useful thing to do. So even if you only use it for that, it’s a good place to get your feet wet and try it out. Then just getting involved by being really vocal about the things that you want to see in a unified browser telemetry SDK, like OpenTelemetry is really a good place to get involved as well. I feel like we don’t really hear from end users as much as we hear from observability vendors. So I always like to encourage folks to talk to the SIG about it.”

Martin Kuba: “I think it’s definitely possible right now to just include the log SDK and generate your own events from different parts of your application. Some of the events are not difficult to capture. You can start with that. And then as we build official instrumentations, you can just replace that easily. We are working on semantic conventions right now for some of those events. So I think you could start by generating custom events with those semantic conventions and then just replace that with official instrumentation when it’s available.”

Favorite answers on what gets you excited to work on OpenTelemetry

Ted Young: “I love this project. I mean, it might be a sappy answer, but I really truly love the community around OpenTelemetry. I like how chill and friendly the community is. Like I’ve been working in open source, like, for 30 years. And there’s always a lot of open source drama and posturing and stuff that kind of comes around the scene and being the cool kids. Maybe it’s just because if you’re caring about observability and operations and all of this stuff, you’re already a bit grizzled or something. You’ve been through the fire and that’s why you want to work on this stuff. I just think it’s a very friendly community. I just enjoy showing up to work because I get to hang out with all these people.”

Purvi Kanal: “I’m excited to see people adopt them [the OpenTelemetry standards] and have success with adopting them. And like really, I’ve seen that over the last few years. I’ve also been involved with OpenTelemetry for the last three years. And I feel like there’s been a bit of a wave in the last year and a half where, before that it was still just like, ‘Should I use OpenTelemetry? Should I not?’ And now I’m really seeing that it’s really becoming more of the industry standard. So it’s been very cool to see that shift happen. And now it’s coming to the browser space as well, because everybody just should be demanding better from their observability vendors and not having to worry about what the data, like compete on what the data emitted is, I think is a really, really big deal, which will lead to much better observability tools in general for folks.”

Resources about OpenTelemetry

• Cloud Native Computing Foundation Slack community
• OpenTelemetry website
• OpenTelemetry JS SDK
• OpenTelemetry Browser SDK
• OpenTelemetry Demo
• OpenTelemetry JS console exporter

Another option for web developers to try out OpenTelemetry is to use the Embrace Web SDK. It’s open source, built on OpenTelemetry, and connects to any OTel-compatible tooling, so it’s an alternative to using the OpenTelemetry JavaScript SDK for web apps.

Full transcript

Colin Contreary: All right. Hello everyone. And welcome to today’s event, “Coming soon to a browser near you, OpenTelemetry.” I’m Colin Contreary. I’m the head of content at Embrace, and I will be today’s moderator. We’ve got a wonderful panel with several members of OpenTelemetry’s new Browser Special Interest Group who are here to share what they’re working on in terms of getting OTel to shine on the biggest of screens, the browser. That’s right.

We’re here with ridiculous OTel movie posters behind us because improved browser observability is the movie we’ve always wanted to see. And now it’s finally coming to theaters. So grab your popcorn, and panelists, if you have popcorn, perhaps eat it quietly away from your microphone. And it’s time for lights, camera, action on OTel for web. So we will cover the first phase of the Browser SIG’s plan, including how they’re approaching the problem of improving browser support for OTel, what they’re planning to build, and also how the community can help.

We will dive into some challenges in adapting OpenTelemetry for the frontend, such as modeling user sessions, dealing with resource-constrained environments, and overall just looking at how client applications are different than servers. And we will also cover what developers need to know who want to try OTel in the browser today, including what’s available now, what you can use, and what will be available in the near future.

Finally, we would love to answer as many questions as you have. So please ask them using the Q&A function at the bottom and we will answer them either during the panel or during the dedicated Q&A section at the end. So with all of that out of the way, let’s dive in, and we will start with a poll question as we meet our fantastic panelists. So if you wouldn’t mind answering that poll question, and panelists, while we give the audience some time to get their answers in, let’s go around, have everyone introduce themselves, say what your role in OpenTelemetry is, what your role in the new Browser SIG is, and share your favorite movie snack that I know you brought with you. I brought Reese’s. So let’s start our intros with Ted.

Ted Young: I’m muted. Hello, hello. Yeah, my name is Ted Young. I’m one of the co-founders of the OpenTelemetry project. And yeah, my favorite movie snack, I actually grew up in Hawaii. And my favorite movie snack is popcorn mixed with this kind of Japanese rice cracker called arare. It’s a super common thing in Hawaii. They sell it at movie theater, you dump them both together.

I could not find arare at my local Safeway in Portland, Oregon, where I live now, but they did have this cool ramen snack, which this thing doesn’t want to show you, which sounded like something I would like. So that’s what I grabbed.

Colin Contreary: Does it fit the bill, Ted? Is it close to what you remember?

Ted Young: It’s, it’s, it’s a different kind of snack, but, we did also eating at home, I guess, if I was in the movie theater, taking a bag of ramen and, like, crunching it up and just eating it dry basically was like another weird thing we did in Hawaii. Maybe people did that elsewhere.

Colin Contreary: Nice, all right. Well, thank you, Ted. Let’s do Purvi. Can you go next?

Purvi Kanal: Sure. Hello, everyone. My name is Purvi. I’m a software engineer at Honeycomb. And my movie snack that I brought today are Nerd’s gummy clusters. They’re my current favorite candy. I love eating them at all times, including on long runs. These are way better than gel packs. And I love the browser. I love frontend stuff, I’ve been doing it for a really long time, and I’m excited that we’re trying to have this standardized format for emitting our browser telemetry data because we have so many different ways to do that today and I’m hoping we start converging on the same way of doing it. Also with me is a full fat Coke, which is the superior, is a superior drink. Yeah, thanks.

Colin Contreary: Nice. I have a Coke Zero, but Coke is the best thing to drink at a movie. Martin, would you like to go next?

Martin Kuba: Hello, everyone. My name is Martin. I’m a software engineer at Grafana Labs. I’ve also been doing frontend browser work for a long time, observability for a long time. I’ve been involved with OpenTelemetry for a few years now, mostly focused on JavaScript SDK.

I’m an approver at the JavaScript SDK. And I’ve also been involved in the Client Instrumentation SIG for a few years, where we have been discussing browser-related stuff and mobile-related stuff, mostly around spec. And I’m very excited about finally making actual progress, implementing things and getting things out to users. I brought with me popcorn. I’m not very exciting.

It’s very basic, but I don’t, I’m not a big snack person, so I just brought what I would probably get at a movie theater anyway.

Colin Contreary: So nice. Did you have that popcorn container at home or did you go by it?

Martin Kuba: No, I went and bought it.

Colin Contreary: Like at a theater?

Martin Kuba: No, no, it’s it’s just grocery store.

Colin Contreary: OK, OK, gotcha, gotcha, gotcha. I was going to say, wow, you went above and beyond. I’d like to go buy this at the movie theater to go, please. I’ll eat it at home. Awesome. Thank you so much, Martin. And Jared, can you round us out?

Jared Freeze: Yeah. Hey, everyone. I’m Jared. I am a software developer at Embrace. I’m on the web SDK team. So I’ve been doing frontend long, long time as well. Yeah, just getting started with OTel. So I’ve worked in the sort of measurement space for a long time. yeah, looking forward to contributing to the SIG. I will be writing code and just grabbing tickets and trying to contribute where we can. And yeah, I also brought popcorn. I don’t normally eat at the movie theater, but if I had a choice, that’s where I go to.

Colin Contreary: Nice. Awesome. Well, thank you so much, Jared. And here, let me wrap up the poll. Let’s see what happens. All right. So the audience says the best thing to do at a movie is something savory with the drink. Did any of us have that combo? Herbie, you and I were sweets with a drink. Ted, I don’t know if we saw your drink. I forget. But you had a savory. We had a few savories. I don’t know if we had savories with drink here, but interesting. People love the popcorn in the drink, I guess. All right. Thank you all for helping out with that poll and giving some great intros. And so now let’s dive into the discussion. So our first topic is going to be what is phase one of the browser SIG franchise? So let’s learn a little bit about how the browser SIG was formed, how it changes OTel project management, and what we are excited to work on in this first phase. So maybe we start with Ted, can you give us some context on how the Browser SIG came to be?

Ted Young: Yeah, so OpenTelemetry has had a JavaScript implementation for a long time, and that JavaScript implementation can run in the browser, but is primarily focused in a production setting for running in Node.js. So you can use it to do some rudimentary things in the browser, but it’s not really something that we consider like a professional product that stacks up against the other things that are out there. But it did work. But in terms of just resource management, the browsers, mobile, everything like that, it’s so different from server-side stuff. We knew that we needed to tackle it very intentionally. It wasn’t something we could just kind of like pick away at, because there’s a bunch of, like, fundamental pieces that you need that just aren’t really present or relevant with server-side development. And we finally got to a point where we had cleared through the rest of our major backlog in OpenTelemetry of traces, metrics, logs, and all of that, that it felt like we now had the bandwidth to tackle client observability. So that’s kind of the background of why now, why we’re doing it now.

Colin Contreary: Okay, okay. So working through and now we have the bandwidth to actually, like, invest in this dedicated approach. Okay, gotcha. And let’s talk about what is in store for the first phase of work for the Browser SIG. I don’t know if someone else wants to share, maybe Martin, do you want to share, like, what are we tackling in the first phase of work?

Martin Kuba: Yeah, I think the idea is to work on a few things. We have, we’re still kind of trying to… define the exact scope. We started thinking about, OK, we know there are challenges with the existing instrumentation. So maybe we should step back and look at the API and the SDK and how that compares to other solutions out there. We know that we have issues or constraints with the size of the package and some performance issues potentially. So that’s one thing. But I think we want to focus on getting something out there fairly quickly and get feedback from the community, and then iterate on that. So I think that would include building some core instrumentations that are missing, that have been missing, that maybe prevent users from jumping in and trying things out. There is more. I think we’re also looking at the data modeling, trying to define semantic conventions. But that’s in summary, I think.

Colin Contreary:  Yeah. Okay, nice. And Purvi, what are you most excited to work on in this first phase of the Browser SIG?

Purvi Kanal: Yeah, a lot of overlap with what Martin said, I’m particularly interested in the instrumentation side of things, as well as the semantic conventions. They kind of go hand in hand, I think, for me, because it’s hard to build out good robust instrumentations without good semantic convention standards. So seeing the first round of semantic conventions roll in for browser-specific stuff is really, really exciting and really, really exciting for me because we have a few things right now, but as we were also building out a vendor version of this at Honeycomb, we realized how much just depth and breadth there is to cover in the browser and how many different things from just breaking down a user agent to all of the page location information. There are just so many conventions to define about how we want to communicate those. Even with Web Vitals, there’s just like lot of rich data and we don’t have any semantic convention standards there.

So I’m excited to see that come together, especially in a world where we’re using more and more like LLM tooling to potentially like analyze this data. Standards are more and more important because those tools can understand telemetry data better if it is standard across lots of different things. So I’m excited to see that. And then while there is a little bit of browser instrumentation, there’s some core stuff missing like Web Vitals, error instrumentation, page view instrumentation. So I feel like getting some of these core instrumentations in there will make it a much more robust product to use, and we can deliver that in the iterative way that Martin was talking about.

Colin Contreary: Okay, gotcha. And just to clarify, when you talk about the landscape of semantic conventions needed for the browser, is it just they’re way more needed there as opposed to the backend? Or is it just that the primary focus of OTel forever has been backend, so you’ve slowly chipped away at all that? Or is it even comparing them, like is the stack of browser just way bigger?

Purvi Kanal: I don’t know off the top of my, it’s more like the second one. It’s like we’ve had the chance to go deep for all of the server stuff. So you see all of these amazing semantic conventions around like database things or even like cloud practices and like Redis or all of these different areas. And then for the browser, we have a couple that are stable now, but they’re very just like browser.name, like which browser you’re using kind of thing. You actually jump into all of the data in the browser and you’re like, wow, it’s a whole, whole new world in there.

Colin Contreary: Nice, okay. And Jared, what are you most excited to work on in this first phase?

Jared Freeze: So one of the things that I’ve been focused on so far is how some of the things that are sort of for Node from the JS side will get bundled, how they’ll actually function in the browser, how people put things together, right? Because there’s a few different ways to do that. And so making sure that people can use the parts that they want and sort of providing everything someone might need for older browser, newer browser, you know, mobile, you know, file size, all of it.

Colin Contreary: Nice. And can we clarify, because I know we’re going to get into some of the specific challenges more in detail, but what is some of the first steps, like first pieces of work? So we’ve talked about there is semantic convention work, like data modeling work. There is this OTel JS SDK that is for Node. But are we building a SDK out of the gate for the browser, or is that a later concern? Can we walk through some of those decisions? Maybe Ted, I see you nodding your head.

Ted Young: Yeah, sure. So this is actually like a real important fork in the road that we were looking at. Node.js in the browser, like JavaScript is the same all around, but the runtimes are very different from each other. And you have different facilities available to you in the browser than from Node.js.

And some of those are really important around things like context propagation and stuff like that. So one open question that we had is, is it possible to have a shared implementation and even a shared API that works in both environments, but is like so totally optimized for the browser that it is, you know, best in class there, or is it on the path to optimizing our browser implementation to the point that, you know, it’s like top shelf industry implementation.

Do we end up having to abandon sharing a lot of stuff with Node in order to specialize? And our initial thought was that we were going to have to have two separate implementations around some of these things. But Daniel Dyla, who’s one of the maintainers of the current JS implementation, has been working on some prototypes that kind of proved out pretty well that like actually that may not be the case, and we could just make something that works better everywhere.  So, so we’re actually pretty bullish on that idea right now that we could just continue to like have one shared implementation.

Colin Contreary: Wow, all right, that sounds awesome. Very cool. so I know so we’ve talked a little bit about broadly some of the initial work, some of the gaps there that need to be fleshed out. So let’s dive in a little bit more in detail there. So the next thing I’d like to dive in the weeds, we’re calling this question, what’s challenging about casting the movie OpenTelemetry for web? And for you JavaScript developers out there, I’m not talking about typecasting or type coercion or all that nonsense, talking about movie casting. So let’s dive into some of these challenges in a bit more depth in adapting OTel for the browser. So I know Purvi, previously you’d share with me that idea that OTel is really designed for tracing through distributed systems as opposed to the browser. Can you share a little bit more about what are some of the challenges with getting this to work in the browser?

Purvi Kanal: Yeah, that’s a great question and something a lot of us have been thinking about, which I also think is one of the challenges that we’ve had kind of getting this off the ground over the last few years, especially when you think about distributed tracing, right? Like you kind of have like an entry point. Let’s say you have an HTTP request that originates from a server and then it like goes through a bunch of places. You can trace that all the way through your system, through a cache, through a database, through something else. And it’s kind of this one line that you can make. It might meander. It might go to different places. But you’re kind of tracing that line through. And there’s one input. I think what’s challenging with the browser is instead of going from this distributed tracing system, you go to an event-driven system with multiple inputs. So here we don’t just have one input. You kind of have multiple. You have the user is doing something. You’re clicking around in the browser. You’re scrolling. Users are creating hundreds and hundreds of events, even like hundreds of events per second. Like browser apps are pretty complicated these days. So the user input, you have your application code input. So as the user is doing things, the application is potentially reacting to some of those things, but it also might be doing other things like fetching resources in the background or doing some other kind of background tasks, prefetching other resources.

And then you just have, like, whatever is going on in the browser itself. So there’s many, different inputs that are not totally related to each other in a perfect way through a trace ID, especially as we go into, like, asynchronous JavaScript. And browsers are all about just like an event loop, just responding to all of the event listeners that these inputs are. So it’s not super well designed to be perfectly traced because where does the trace start and where does the trace end is one of the first things that I think like we got stuck on as we were talking about it.

So we really need to introduce a new concept like sessions to deal with that. And that wasn’t super well-modeled in OpenTelemetry and other places in backends and things.

So that’s kind of like one of the first major differences that we ran into. And there’s many of them from an application code perspective of, like, Node and the browser are extremely different runtimes. But even just conceptually, there have to be a couple of new concepts that we introduce to make this robust in the browser.

Colin Contreary: Nice, okay. And so let’s dive into that. ‘Cause I know we’ve received a few audience questions about this concept of, you know, are we tackling session management and what that looks like? And I know that there’s active discussions there. I believe Martin, you’ve put together an initial proposal or something about sessions. Martin, can you share a little bit about some of these discussions and maybe some decisions that are being made or still things that are, you know, question marks that are being worked on in terms of defining sessions?

Martin Kuba: Yeah, definitely. So I think one thing that’s challenging about sessions is that we have been talking about how do we model sessions. Sessions are something that’s applies, it’s almost like a resource that applies to all signals that are being collected in the browser. And the session is something that ties like many different events and many different traces or spans together. So we want to think about sessions as a resource. And it’s also interesting because sessions span page loads. When a page loads, the SDK initializes. And typically, on the backend, the lifetime of the SDK is constrained to last a long time.

Whereas the SDK here is like on every page load it initializes again, but the session spans many different page loads. On top of that, the session can end at any time. And at that point, a new session would start. So the challenge for us has been figuring out how do we represent the session as a resource, but also make it so that it’s persisted.

And that it can be changed during a session, during a page view. So that’s one thing. So my proposal for sessions, that’s more kind of the API and how users would actually interact with sessions, how sessions would start, how they would end. I think there are still discussions to be had in this. In this area, I think we don’t want to, from my opinion, like we don’t want to prescribe necessarily like how, you know, like when a session should end or, you know, how long it should be or things like that. You know, I think we want to give users like the tools so they can manage and define their own sessions. Yeah, so I think that’s the things that I can think of at the moment.

Colin Contreary: Okay, nice. Jared, can you share a little bit about session management and maybe some of the things that maybe we’re working on at Embrace that are things that we’ve come across as we’ve invested in this and where we think we can contribute about it?

Jared Freeze: Yeah, so one of the things I think is really special about the browser is knowing what the user is doing, like what they intend, what they’re trying to get done, basically. Because you have, like has been said, you have application code, right? And you want to know sort of what’s going on there. But then you want to know how long are they on the site? Are they doing something that’s really interesting, but it’s the same experience.

So, you know, I like to use the e-commerce example, right? I’m on the homepage, there’s a bunch of products, and I’m opening products in a new tab, right? But I haven’t visited that page yet. It’s happened in the background. There’s a few things that happen there. You know, the life cycle, you know, of moving through pages, right? Not just navigating within a page, but saying, I’m on this site, I’m still interested. I’m, this is my train of thought. And then like, I go to product one. I’m like, that’s really cool. Put it in the cart. Track all those events, go back to the homepage. Like I’m still having the same experience. So, do you include that? What are the options? Things like that. Another model I think is really interesting is like I’m in an email, right? And I get a newsletter, lots of links, and I’m opening these links, right, from Gmail or whatever. And there’s no, the referrer doesn’t exist, right? I’m just showing up on sites. But really, it could be the same domain. Is that a session, right?

How do people think about this? If, again, you’re going to the same domain over and over again, should that be included in the experience? Or how do you put these things together? How do they map across the real world, how people are really using stuff? Because it’s not just going to be, I’m on a page, measure everything, I navigate, and then I start over. It’s not how a person would think about it. So how do you measure that? How do you give authors or users the options to do that if they’d like to, or to say, you no, every time you open my domain, you’re doing something new, you know, or whatever it might be.

Colin Contreary: Nice. And so yeah, you’re getting into a little bit of what Martin was getting into about you need some flexibility in how you measure this because you might want to measure every single browser tab as part of the same previous session versus not kind of giving some optionality to the instrumenter is very important. OK, gotcha. Ted, was there anything you wanted to chime in about sessions?

Ted Young: I mean, I think that it just comes down to correlations. At the end of the day, what we’re trying to do when we’re observing things is you have something you care about, something that’s taking way too long or an error or some problem. You’re starting with a problem and then you want to know what correlated with that problem. So what’s going to lead us, how can we follow the trail of breadcrumbs back to the things that originated this so that we can, you know, remediate the issue. And that’s like when you get into stuff like session management, that’s one of the big questions, right? Like so, so some there’s one way of framing it is like we’re just trying to reconstruct everything the user might ever do. And that’s a very complicated thing. That’s why it’s hard to figure out. But if you look at it from the perspective of, like, we’re trying to find like correlations from the perspective of an operator trying to improve the product. I think that gives us maybe like the right scoping for what we’re trying to solve.

Colin Contreary: Okay, gotcha. Yeah, and even just trying to collect everything right from browsers would be an incredible challenge. I know we’ve already talked on this call, but I know a lot of discussions are there about, how do we reduce the bundle size of what we’re loading, especially if someone’s going to a website loading 15 pages like you were saying, Martin, you’re loading the corresponding SDK, collecting telemetry, all of that. I wonder, maybe I’ll start it with you, Martin. Can you share a little bit about some of these challenges with bundle size and maybe some initial thoughts or investigations on what are some of the challenges there in terms of making sure OpenTelemetry can work in the browser?

Martin Kuba: Well, I think the main challenge has been that the JavaScript SDK has not been optimized for browser. It’s been mostly focused on Node.js. So as far as optimization, it’s not optimized for browser. I mean, there are some things we can do as far as tree shaking, like making changes that certain, when you do bundling, that things that are not used can be excluded.

That’s kind of the main focus, I think. The other thing that I would, from my perspective, is that the tri… So I think that the different… One of the challenges is that there are many different types of web applications out there, and they have different needs. So some applications might be okay with maybe a little bit bigger bundle size if they want to care about more signals or getting more data.

Whereas some applications just really care about the smallest bundle size as possible because the speed of the page load is the most important thing. So I think, from my perspective, is as we’re moving away a little bit from span-based instrumentations to event-based instrumentations, I’m hoping that can make the bundle size smaller.

Or at least give users the option of, if they want to collect only certain events, they don’t have to include the tracing SDK. They can just include the log SDK. The tracing is challenging as far as bundle size, because the API and SDK is larger and more complex, but also because there is context management that needs to help.

That needs to happen, and we use a third-party library for context management that also adds to the size of the bundle. I think just again, I think from my perspective, giving users the flexibility to choose what they want to include in their bundle is one part. And then the other part is making updates to the existing JavaScript SDK to make it possible to do some tree shaking.

Colin Contreary: And going back to something you said, Purvi, when you talked about browsers and the way users interact with them being more of an event-driven architecture is part of the reason why we can tackle this now. idea that OpenTelemetry all have been working on the Events API as a separate thing. Is that one of the things that will help?

Purvi Kanal: I think it’s part of the picture that’s also something that’s emerged over the last year or so. The Events API is really like a wrapper around logs that we felt would be a good representation of most events in a browser. There are some other systems, I think, that would also help. It would be helpful to model them that way that are not the browser.

But I think it will be a combination of two signals, which is events and spans and traces. Because anything with a duration, you still want to use a span for that. Like, for example, if you think about like a network request or something, you kind of want to track that more with a span. And it might do some trace propagation all the way through to your backend as well in a trace. But then if you think about something like a Web Vital, that doesn’t necessarily, a, you know, cumulative layout shift, like that just has this arbitrary value and I don’t even really know exactly what the units are. But it’s just, and metrics doesn’t quite fit either. Like metrics are really good for tracking things on the server as things that are changing over time, but it doesn’t really work in an event-driven like browser system. So we kind of landed on essentially logs with just a very specific format of like a name and a body for adding extra attributes. So it kind of made sense of like, I kind of think of it sometimes as like anywhere you’d want to put like a console log, but you obviously shouldn’t do that in a production application. That’s a good place to like add an event.

Colin Contreary: Yeah, exactly. All right. Very cool. And then I think we can probably, is there any other challenge that we would like to go into before we go into our next discussion section?

Ted Young: I think there’s one notable thing here that we’re trying to do with OpenTelemetry that’s a little bit different than observability in the past, which is we’re trying to ship a unified system and a unified data model, right? Like traditionally, RUM, client observability, browser, mobile, like these are all separate things. And then even on servers, you know, like tracing metrics and logs were like totally separate siloed systems. All of these things were totally separate products that were kind of like end-to-end unified.

And what we’re trying to do is rearrange that and say you have a unified telemetry system. So it’s like the same data model across everything. So you could take all of this browser data and shovel it into any kind of backend system. It doesn’t need to go into like some kind of specialized RUM product to be useful.

And it also means that all of that data is integrated, which is very, very useful. Like the spans and tracing stuff we do on the server, you really care about latency, right? But the latency you care about the most is the perceived latency of the user, right? And to understand that, you need information from the user’s client. So there’s this like… trickiness of like, how do we get all of that information without all of the burdens that Martin and Purvi were mentioning around, like, well, if you have a complete tracing system, that can be pretty heavyweight. Metrics are, like, that’s even more stuff you’re loading. So is there a way to have more lightweight versions of getting that information out while still having this unified system?

And that’s just like a bit of a trickier problem to solve than, you know, in a world where these things were totally separate. But I think the value people are going to get out of having this more unified system are going to be worth the cost of figuring out how to do it.

Colin Contreary: Yeah, exactly. Yeah, I mean, there’s going to be challenges across the board, right? Because let’s say all of our data modeling challenges and everything were resolved today. There’s still this concept of the language of observability that backend folks are so familiar with that developers are a little bit less familiar with, right? The concept of setting up traces. So there’s an education component, and it’s important that we standardize like you were saying, Ted, so that that way we instrumenting all of our systems the same. It’s the same thing we can learn. We can communicate effectively, use the same semantics, et cetera. So yeah, I’m very excited that OTel will have improved support in the browser.

And so given that we just talked about that, let’s shift to our next discussion question, which is we’ve talked about some of the challenges, some of the things that the Browser SIG is working on. But let’s talk about if people want to use it today. So if web developers are breaking into O11ywood, to use our movie language, what can they use today? What can they expect to use in the near future? Let’s dive in. Let’s say they want to use OpenTelemetry today. Can they use what is out there? And what are some of the things that they should consider? So maybe, Purvi, can we start with you on that?

Purvi Kanal: Yeah, absolutely. I think in terms of using OpenTelemetry today, as some folks had already mentioned, you are able to use OpenTelemetry in the browser as it is today with some caveats, with that it’s not built with this browser-first mentality. So the bundle sizes are big. The tree shaking is very rudimentary at the moment.

If you are thinking about context propagation across something like an async boundary, you will have to use a library called zone.js to do that, which I think is a tough sell because it’s huge. It comes in at like a megabyte by itself. And it’s also not super well-maintained. And it doesn’t work for async-await anyway. So it might be better to kind of let that go and tie things together through sessions instead of these perfect traces that encompass an entire session, which is the world we want to move towards anyway. And so I think it is possible. You can get in there and play around with it. There is some instrumentation. There’s network request instrumentation, document load stuff. And there is going to be more stuff coming out.

There’s some user interaction instrumentation as well. But these are not perfect implementations, and they were built quite a long time ago without semantic conventions in place. So these are some of the challenges of using it as it is today. But I think you can do a lot of rich manual instrumentation as well. I think it is also right now OpenTelemetry really connects your browser traces to your backend traces like no other system does. And that in itself is a pretty useful thing to do. So even if you only use it for that, it’s a good place to get your feet wet and try it out. Then just getting involved by being really vocal about the things that you want to see in a unified browser telemetry SDK, like OpenTelemetry is really a good place to get involved as well. I feel like we don’t really hear from end users as much as we hear from observability vendors. So I always like to encourage folks to talk to the SIG about it.

Colin Contreary: Nice. Thank you. And how about Martin? Do you have thoughts on if people want to use it today? What should they use or maybe what is coming down the line?

Martin Kuba: Yeah, I think what Praveen said, basically, she said everything that I would say. it, I think, you know, I think the answer is maybe it depends. It depends on your needs. You know, I think we know that there are users out there of the existing OTel instrumentations for web. So it’s working for some users. If bundle size is not a huge concern for you, maybe that’s good enough for now. And as we introduce new instrumentations, you will benefit from that automatically. You can easily add them to your existing instrumentation. And I would also kind of just… you know, emphasize again like what Purvi said about manual instrumentation. I think it’s definitely possible right now to just include the log SDK and generate your own events from different parts of your application. Some of the events are not difficult to capture. You can start with that. And then as we build official instrumentations, you can just replace that easily. We are working on semantic conventions right now for some of those events. So I think you could start by generating custom events with those semantic conventions and then just replace that with official instrumentation when it’s available. Yeah. I think the other thing that I would also say, just like Parviz said, we’re looking for feedback. So I think, I would encourage people to use it if you can and give us feedback.

Colin Contreary: And y’all were both talking about the idea that, yes, you can manually instrument everything that you need for your use case. We did have a question from the audience, though, which is, what is the state of browser auto instrumentation? Can we dive into that a little bit and just share what people could get out of the box without having to manually instrument? Maybe I see some head shakes. Maybe Ted, can you chime in?

Ted Young: I mean, you know, the thing about the browser is a lot of what you care about is the comes out of the browser runtime itself. So I think you can do quite a bit just by instrumenting the browser and not having any like library-level instrumentation, which is where most of the instrumentation lives in server-side programming, right? It’s like you’re instrumenting your libraries and frameworks.

But you can get really far in the browser just by instrumenting the browser runtime. So in that sense, like auto instrumentation is kind of there. But I would say the state of the browser is really rudimentary. I think I may be like less bullish than other people on the call about saying, ahead and try it right now. Like if you are using an existing RUM product of some kind, I would say like, don’t worry about like, OTel at this time. But if you have nothing and you’re very interested in extending a trace back to look at the browser aspect of that trace, and you can take the hit of the cost of loading up all of that stuff in its current state, then that could be valuable. But I think we haven’t actually rolled out our new version of it.

And I would like to see us get, like, a kind of like a beta version of like, okay, here’s what we’re intending as opposed to the old thing that you can run right now, which might give you, like, a missed perception of where we’re going with the product.

Colin Contreary: Gotcha, and and there are options right outside of the official OTel packages, right? There are different SDK’s people can use if they want to put them in their websites and send the data to you know any OTel collector, like, you know, Honeycomb has one, you know, Grafana, Embrace. So there are also you know vendor solutions people can use without needing to, you know, use the vendor. But yes, in terms of the official community ones. Yeah, I agree, Ted. Jared, did you want to chime in a little bit in terms of how can developers get into O11ywood and OpenTelemetry? What are your thoughts there?

Jared Freeze: Yeah, I was gonna say about the SIG itself, I think just sort of getting involved that feedback like they were talking about. There’s lots of different kinds of applications, pages, some things are published, things are single page apps. There’s a lot of different things people care about, different patterns. And I think that’d be a good way to get started is just having, there was some energy today in the SIG about let’s get something merged so people can start using it.

So that way we can see how these things are going to go, even if it’s within the group. Just having something to look at, work on, just to get started, basically. Not worry so much about everything being done or everything being perfect or the names being exactly right. It’s more important to see is this meeting the need or what direction to go based on the real experience instead of just maybe looking at code or having discussions.

Colin Contreary: Nice, and we did have a question that I want to share with the panelists, which is, “Great discussion. Thanks for the insight. Is the Browser SIG reaching out or having discussions with other working groups like the W3C Web Performance Working Group or the W3C RUM Community Group?” I guess I’ll send that to Ted.

Ted Young: No, we’re not actively collaborating with those groups at this time. The, the kind of time scale that we operate on and the time scale the W3C operate on are, like, a bit different. So, we don’t want to kind of hitch shipping, what we have to waiting for the W3C to finish stuff and then browser vendors to, like, implement that stuff and then users to upgrade and adopt it, you know.

In that sense, we want to be aware of what might be coming in the future, but we don’t see those things as things we can rely upon for the implementation just due to the timeframe that we want to be shipping in.

Colin Contreary: Okay, gotcha. And we did have one other question, which was, since we’re on this topic, it was, how is the SIG thinking about integrating some of the existing browser performance APIs, like the PerformanceTiming APIs? Maybe I’ll ask, I don’t know, Purvi, you unmuted.

Purvi Kanal: Sure. So we don’t, I don’t think we have, like, an official proposal or spec. So obviously always open to hearing about how that’s useful for folks. I’ve done a little bit of manual instrumentation with the browser PerformanceTiming APIs. So in terms of auto instrumentation, I don’t know that it would, like, be this like magical out of the box auto instrumentation because browser PerformanceTiming APIs are all about like performance marking and measuring the things that you care about, which actually bring you a lot closer to what your true page load is. We all define page loads so differently, and I think it really means a different thing in different apps. In Honeycomb, when I think about our page load, I’m thinking about the graph on this main page, and I’m like, did that render? But that might not be true for your application.

So that’s really where I think having APIs, having really good span or event creation APIs is really more important than actually how we’re tying into the browser APIs. Because all that matters is we have a flexible enough API that you can stick it in any browser API and emit the event that you care about. And as long as those things aren’t conflicting, you have actually a very, very robust way to instrument your application code in a standard way, which is pretty cool.

So it’s more about getting to know those APIs and documentation for, like, hey, this is how you can use browser PerformanceTiming plus OpenTelemetry to measure your true page load rather than waiting for a document ready or something.

Colin Contreary: Right. Gotcha. Thank you. That’s very helpful. And I would like to, before we move on, since we’re talking about people getting involved, right, dipping their toes into OpenTelemetry, especially if they’re a web developer, maybe they’ve never used it before. I’d love to get y’all’s feedback on what are some first things that people can use, whether it’s a tool or an approach. Because as we all know, OpenTelemetry can be a very large, confusing thing if you’re not familiar with it. I’m curious, what are some resources, tools, or approaches y’all would recommend someone who’s, you know, day one, I’d like to try OpenTelemetry. Maybe we can start with Martin.

Martin Kuba: Well, I would say that maybe start with the website, the OpenTelemetry website. There’s a lot of good documentation there. There is an even example of getting started with browser. And also the other resource that I would recommend is there is a demo application that OpenTelemetry has, which includes a lot of different types of instrumentations, like different languages, different SDKs, including browser.

So I think that’s something that users can explore and kind of get a sense of how things work. Nice. Awesome. Jared, what about you?

Jared Freeze: Yeah, I was going to say one thing that really helped me while I was getting familiar with the space was the console exporter. So you could run the libraries and not need an endpoint. You don’t have to start there. You can run in the browser. You can see everything that’s emitted in a well-structured way and be, like, OK, cool, I have the right attributes. I did the right thing. I named this properly. Or I’m doing punctuation correctly for naming keys, whatever it might be.

And you can not have to necessarily go and worry about the backend, like right out of the gate.

Colin Contreary: Is this you just revealing Jared that you’re at heart just a console.log debugger? Is that what you’re telling us?

Jared Freeze: If I never had to leave the browser, I’d be happy.

Colin Contreary: Awesome. What about Ted? What’s your advice for people like just getting started with OTel?

Ted Young: I mean, I would double down on what Martin said and say the OTel demo app is like a really great starting point because before you go trying to instrument things and stand everything up, it can be very helpful to just see the data in the product you’re going to be looking at the data in. And so something that’s well-instrumented, and has a load tester that can like generate all the load and let you actually like poke around and get a sense of like what it should look like before you go try to like do it yourself. That’s really helpful. And also when you’re trying to implement, sometimes docs are useful, but sometimes you just want to copy paste some code, and the code in those demo apps is very clean. So I recommend people if you’re, like, confused about, how do I actually like implement this thing? Like looking at those demo apps and just copying and pasting stuff out of there. There’s nothing wrong with taking that as a starting point.

Colin Contreary: Nice, awesome. And Purvi, did you have any tips for people just getting started?

Purvi Kanal: I think those are all excellent tips. I’m trying to think if there’s, like, anything I could add to it. Yeah, no, I think that really, really covered it. Yeah.

Colin Contreary: Awesome. Now I did want to ask y’all another question, which is, what makes y’all excited to continue to work in OpenTelemetry? I know some of y’all we have 10 years extending very long periods of time. Ted, your co-creator of it, so hard to hard to get more ahead of it than you. I’m curious what makes you excited to wake up each day and help contribute to the OpenTelemetry project and continue to grow it. Maybe we’ll start with you, Ted.

Ted Young: Who said I was excited? Who said that? No, I love this project. On it, I mean, it might be a sappy answer, but I really truly love the community around OpenTelemetry. I like how chill and friendly the community is. Like I’ve been working in open source, like, for 30 years. And there’s always like a lot of open source drama and like posturing and like stuff that kind of like comes around the scene and being the cool kids.

Maybe it’s just because if you’re caring about observability and operations and all of this stuff, you’re already a bit grizzled or something. You’ve been through the fire and that’s why you want to work on this stuff. I just think it’s a very friendly community. I just enjoy showing up to work because I get to hang out with all these people.

Colin Contreary: Nice, and I will share this at the end, but obviously like you said Ted, it’s it’s an open source, it’s a community, anyone can join and anyone is encouraged to join if you want to just learn more. If you want to interact, if you want to ask questions, if you want to contribute, whether it’s code or documentation or any number of things, we really encourage you to just jump in. It’s a friendly bunch, as Ted says. That’s awesome. OK, how about Martin? What about you? What makes you excited about OpenTelemetry and continuing to work in it?

Martin Kuba: Yeah, so I am specifically excited about the browser work. I’ve been in the browser space for a while. I’ve been trying to, as I mentioned at the beginning, I’ve been part of the Client Instrumentation SIG for a couple years, three years now. And we’ve been trying very hard to make progress. But it’s just taken a long time. So the thing that I am mostly excited is about making actual like progress like and giving like new new implementing new things and making that available to users to use. And also just providing clarity and guidance to users because I think you know like these questions were getting about like well like what you know, how do I use OTel for browser? You know, like what is available? I think I just want to make I just want to make it very very easy for users to like understand like what OpenTelemetry provides for browser and what our roadmap is. And yeah, just make progress in that space. That’s what makes me excited.

Colin Contreary: Nice. And also because you want to slowly do JavaScript on all the things. Like all JavaScript developers, right? You spend enough time in JavaScript on the backend, now it’s front end, now it’ll be on refrigerators. I know you JavaScript folks. Awesome. Purvi, how about you? What makes you excited to continue to work in OpenTelemetry.

Purvi Kanal: I love an open standard. I like the idea that we’re all trying to standardize the data that we’re emitting from our apps to be able to understand them better. And it’s even more exciting that that’s happening in the browser space because it’s been pretty fragmented pretty much ever since the creation of Google Analytics and those initial analytics tools. So I’m excited to see standards emerge for it.

I’m excited to see people adopt them and have success with adopting them. And like really, I’ve seen that over the last few years. Like I’ve been also been involved with OpenTelemetry for the last three years. And I feel like there’s been a bit of a wave in the last year and a half where like, before that it was still just like, should I use OpenTelemetry? Should I not? And now I’m really seeing that it’s really becoming more of the industry standard.

So it’s been very cool to see that shift happen. And now it’s coming to the browser space as well, because everybody just should be demanding better from their observability vendors and not having to worry about what the data, like compete on what the data emitted is, I think is a really, really big deal, which will lead to much better observability tools in general for folks.

Colin Contreary: Nice, awesome. And Jared, what about you?

Jared Freeze: Yeah, I just wanted to echo all of that, which is, you know, people want to solve problems. Like having an open standard means I don’t have to worry about, like, I’m using this vendor and there’s, you know, all these things that come with it. And like, you know, you’re at the mercy of, like, how good the docs are, or is it compatible with this other thing that I’m doing? And so I think when you have a group like this, which is again, open and like asking all these questions and being really like deliberate and methodical about like, what questions do they want to answer? And don’t worry so much. You already understand these concepts from the larger group or whatever. You don’t have to learn something in a completely new way. And now you’re locked in to something specific. I like that it’s a standard moving quickly.

Colin Contreary: Nice. Well, thank you all so much. We’re actually coming up on the end of the hour. So I’d like to do just a quick wrap up. So that’s all the time we have for this discussion and these questions. All the time we have with these wonderful panelists. I want to give a big thank you to this wonderful panel. Thank you all for being here. Thank you for having a ridiculous OTel movie poster emblazoned behind you. Thank you for joining us for this premiere of the Browser SIG and sharing all of the work that y’all are doing to improve OTel support for the browser. If you’d like to follow up with our panelists in case you have additional questions, we’ll be sending a follow-up email with how you can get in touch with them. And there are also, like we said before, there are many ways that you can help the OpenTelemetry project.

You can provide feedback, you can join the discussion groups, you can become a contributor. It’s an open source, community-driven project. All you gotta do is join, show up, and contribute.

If you’re not sure where to start, I would encourage you to check out the OpenTelemetry website and join the CNCF Slack community. They’re a very friendly bunch, and people can point you in the right direction to what you’re looking for. And finally, when we send a follow-up email, please share any feedback about this panel so that we can improve them moving forward. So one more time, I want to say thanks again to this awesome panel. Thank you for being in attendance. Have a fantastic day and we will see you at the next one.

Thank you, everyone.