Open Telemetry Uncategorized, 30 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-08-30 meeting

Description

Instrumentation: Messaging

A

B

A

How's it going.

B

Can you hit me.

A

I can I can, can you hear me.

A

And can you hear me santosh, yeah, yeah.

C

B

Had okay, some issue here yeah, I can hear right now.

D

B

D

So santosh looks like the events and logs um spec you've got is about to be pushed yeah. They came up in the specs meeting today. So okay, you're gonna get everyone one last chance to uh object. So.

C

Yeah, I think there is one um small piece uh that I'm waiting for the android folks to confirm, um which is whether to that there is a flag that I added to include the trace context.

C

So in android, what happens is when you set up a call back when you set up an event handler, it is called in the same thread where it was originally set up.

B

C

If, in that thread, a span is in progress, and if you get that callback, you know it, it will be in the same execution context, and we may not want to include that spans context in in that event, um so this is, as per the android's official documentation, that the callbacks happen in the same thread.

C

So so um I I don't uh fully understand um some of these things, so I'm at least on the javascript side, martin confirmed that all callbacks get a new execution context due to the way you know how the zone functionality works.

C

So it will always be a new context. It will never be the case that an unrelated event, its handler, will get the current spans execution context. So we may not need that flag in the case of browser, so I told him to you know, omit it entirely from the api for now.

C

But but I think we'll keep it in the spec and see how it goes for the uh android side and and then I'll update the speculator it's experimental anyway. At this point,.

D

Yeah I get called out perfect, meaning that um it's the shape of what we believe it will be, but it is experimental so.

B

D

Cool okay, um I guess yesterday I did eventually get to the remote dependency. So I've updated that rum events. um I only went through the application inside. I didn't do the internal one, so I probably still got a little bit more work to do uh turned out to be a much bigger task than I thought, because I hadn't we don't have a documented in in the level of detail that that now exists in that document anywhere else.

D

I also added in the span based um existing set of events as well and tag them as experimental. So for completeness, um the other thing that's come up is we've also got the elastic um team uh to merge the electric common schema. There they've actually attended the last couple of uh uh events, so they were on the specs meeting this this morning as well. There's also another spec um semantic convention.

D

um Sig, that's gonna, start up, um so they'll probably attend that one. I'm already signed up to be involved in that so yeah, even more mentees that'll be fun.

A

So, as I saw that comment from riley on that project tracking issue, have you seen that uh he was saying.

A

We're gonna find it. He was saying that the instrumentation group is working on stabilizing the semantic conventions. Is that do you have do you know if there's an existing sig, that's working on this right or if this semantic conventions group is going to be that.

D

D

I don't know at this point, uh let me I'll grab the is.

B

It the new group that was in github, I just put the link in chat.

C

Yeah they haven't started the meetings, though yeah.

A

A

Okay, okay got it yeah. I was looking for it yesterday.

D

If you want to be involved, just like add yourself to this, so pretty much most of my team, the leads, like trust, clayton and myself for all language leads for our sdks.

A

Okay, so like, if you talk about like the semantic conventions for events, how they should be defined in the spec, this is the group that will be working on that.

D

um Yeah, I think that will be there as well yeah.

A

Okay: okay, that's good.

C

B

C

Clear, yet um if, if there are any proposals for for for it to be very different from what it is today right.

D

um No, the this group, as far as I'm aware, is going to be working to effectively stabilize it.

C

Okay; okay, because I am wondering um whether you know we should pursue.

C

Defining a schema um saying you know this event has: will have these attributes because today that's that's missing in the semantic convention structure, correct yeah! um So should we even pursue that? I think um it.

D

I I think we should uh I, I think we need to define all the different fields that we want for the different types of events, whether we end up merging with this in terms of a general common uh semantic convention.

D

um I think it's too early to tell at this point, but we need to define the events and come up and say: okay, we want to do this event and we want to have these fields um like there's still the open question which I raised last week about um once we define like I keep calling it event: dot data and everything's like nested attributes, um we still need to have a mapping to get into span events because I'd like to define the event once I have a common schema for it, and then you can send it as a log event or, as a spam event.

D

That's my ultimate goal, which is also why I raised that discussion topic on the existing one um where currently it has each individual property as an event where it just should be an event. It should be a single event with multiple attributes.

C

Yeah, so uh I think um we can do it in two steps, where initially we can define the in the semantic conventions each of the attributes um separately. You know the the way it's defined today, uh not showing you know which event they're part of, um and you know that could be step one. You know that will get us going and then separately.

C

At least you know in a word document you know in in this room events document we could define the different event types and and then list the attributes against each of them and then I think.

D

I I I think it's more: it's going to be more likely that we're going to the attributes are going to be specific. The names are going to be specific to the event rather than we'll have a general thing called fred and that will be used in multiple events.

D

There might be some fields like duration, like an easy one or name, but I think most of the events are going to be unique to the event. Most of the named values are going to be unique to the event.

C

Yeah but the it is um you're right, but it is not explicit right. It's not represented in in the in the ml files anywhere.

D

um Correct, I'm not sure the yaml files will do what we want at this point. Yet.

C

Yeah and and uh there's also a a completely independent requirement where, if we know um which event which attribute is you know, is part of each event, then you know we can facilitate some validations on the back end.

C

So if the producers can use a schema to produce data, um that will you know, you know make it conformant uh to the spec.

D

Yeah, I'm not discounting that I'm just saying! uh Rather than have we we try and say this is all the different fields that we know we're going to have, and then we try and say for this event we're going to use that combination of fields. I think we just say: well, no, don't worry about trying to create the uber list.

D

That's just concentrated in each individual event.

D

At the end of the day, we'll probably end up with the uber list, but I'm just looking at it from a different angle, just saying: okay, let's pick on this event, start working on that one. Let's pick up this event start working on that one and then.

C

So um how do we uh proceed on on this document that you're working on uh like, for example, initially um we could focus on those uh you know the three uh spans document load, fetch and etc. I think those are the most uh basic ones.

D

Yeah, I think well, there's five there that already have experimental span based things. They are the most common ones and they're, probably the ones we should be doing. First, yes, I agree, and maybe the error one as well.

B

A

So what exactly is there to do on the span once.

C

So we need to finalize.

C

We need to finalize the attributes and and the complete structure of those spans like exa, for example, the the timing information um we we wanted to redo right.

D

uh Yeah and it's not actually the structure of the span, it's the truck structure of the let's just call them attributes, which are the fields like for a page view. What what fields do we want once we've got those fields, we can then say well, if you're doing a log event.

D

This is how they're represented and, if you're doing a span. This is how they're represented so yeah yeah yeah. Now.

C

I meant that the the events uh that are related to these three spans- um you know uh we should prioritize.

D

A

So so um so the way I've been thinking about this is uh for you know I I proposed the the event types for navigation, timing and and resource timing.

A

So so right now we have, you know like the current instrumentation has a span. You know it generates multiple spans right like it generates the one for document load and each resource, and then like puts the, I think, puts the resource, timing or navigation timing. Things as as individual span events and the way I envisioned this is. We would have an event for navigation timing uh that has just you know, it's just called navigation the event and then then there's an event for resource timing.

A

That's just the resource resource timing, attributes on it and then the the span is optional gives the context, but you can link these events to the span. So are you thinking about it differently?.

D

um No, I I think I'm thinking in that fashion, um in terms of the actual name um like is the navigation timing, is that the page view performance um yeah so that so what's gotten invested, there is the second one um and then the resource timing like when I added all the resource dependency yesterday, um we actually include that in the same event, so the fetch and the xhr, which are actually the same type of event we just have a type field, also includes optionally, the resource timing, um and that was purely for some, our internal backend teams, it's actually off by default for general users, um but that can easily be split out and say: well, we say browser timing resource.

D

I know what we call it. That's part of the first name um but yeah. I think. If we go through the list and then say these are the events we want to flesh out um and we've got. uh What do we got so cisco? Don't have the browser timing or the user action listed so yeah? We really only got uh splunk uh microsoft, cisco have some of them.

C

What uh what actually is part of this user action is this.

D

C

D

I think it's user interaction, yeah.

B

Yeah, we don't have yeah yeah.

D

um And that's fine, you know not. Everyone needs the same sort of events. I'm sure there's gonna be a bunch of events that microsoft's never going to want to consume. Yeah.

D

Which is the whole point of this table is to say like let's, let's pick on them and I think having the span the the the five experimental ones that are listed, I think really highlights that they exist and they have their hacky work arounds. By having you know the events as things because they're the most common, so it to me, it makes sense to pick on those, and is there really six instead of five because of the resource timing? Maybe.

D

Because we don't have resource timing listed in this table, yet we just have paging performance, which is really navigation. Timing.

A

So so so going back to the span, my my question about spans. So if, if you have captured the navigation timing and resource timing as events and we just link them to the span, what other attributes do we want to have on the span.

D

D

I I from my perspective, I don't want to spend so I I don't think I can answer that question. um uh I can answer the question for fetch and xhr, because I can definitely see a logical span requirement there and that would be um you know, having the identifying the the overall uh name, which I I don't like the way it's there they're for, like http get http post, but.

B

D

It's there for um uh to reduce cardinality on backings, but yeah.

C

Okay, um uh never, I think the I. I want to understand a little bit on why you don't want the page view to be a span. I think the way it is structured today, um the you know. You know these three, the document fetch resource fetch and the document load. They have a parent-child relationship, um you know which is easier to model using spams than events.

C

So you don't want that.

D

um No, don't need that so effectively. That's that's what the you know. The trace header is all about, so the w3c trace parent, that's how we link them today, um you you know everything's associated with the the same like internal. We call operation id, but it's affected the the trace id.

B

C

Trace would it be well, is there a trace um if.

B

You're not using spans at all.

C

If they are completely represented only as events standalone events yeah, then there is no trace right.

D

Yeah we still have the trace id listed like we. If you go down into into the remote dependency you'll see we pass it over as operation, I think, but the the trace id will definitely need to be there. Otherwise, there's no way to link a log event with anything anyway um and if that's not catered for, then we need to cater for it.

D

um And the other reason for not doing in the span levels is spans, don't get sent until they're finished and if you've got like a page load event, you may not actually have a page end if you're doing a client-side redirect. So you you've got the case of event loss just waiting to get the collection of all the events um like as part of the sdks. I try and make sure that everything that gets recorded is sent.

C

But that problem is, uh you know, you're going to face it even with the events.

B

D

Think because, once you fire an event that event can be sent.

C

Yeah, but how do you know when to fire the event right? Because you don't uh know uh when the user is going to navigate away? Okay,.

D

You buy the event when you're, when you, when you know the event occurred.

C

Yeah but the the way the page load is designed is you you wait until the page load is complete or you know for for certain callbacks to occur, and before that happens, if the user navigates away, then you have a browser. You know on unload or something to to tell you.

D

C

D

If you're holding up the pageview event until all that other happens and you've lost your pageview event as well,.

C

Yeah exactly so.

D

So but if you fire the page view as a non-spam and just an event, you've always got the page because you fired that straight away.

C

But the page load hasn't finished, so you will not have the correct duration. In that event,.

D

uh Yes, you will so that so effectively, the page of your event gets gets triggered on page load or on your first execution, depending on how your sdk is constructed. Okay,.

A

So I think, I think what you're describing.

D

Is that one you're talking about.

A

Yeah yeah, so I think what you're describing math is like immediately as like as you as your script uh loads. You can send some some information to the back end like, but it doesn't doesn't have all of all of the timing, but it has some information that that, like the navigation occurred.

D

Correct, which is explicitly why we separate page view and page view performance page view performance is the one with all the timing, because that may not occur not just because of redirects, but it also may not occur because of um the browser may not support, uh and it's asynchronous like um when I did all the remote dependency uh what's called ajax perf in there. I found that there are multiple issues where, when the xhr fetch call comes back, the resource timings aren't there.

D

Yet you have to wait, and I found it was up to like uh 10 milliseconds after that it finishes um before it's there, and because the resource timings have a maximum number of events. It actually may not be there at all and most of the stuff I found online before I came up with my own was always looking for the matching url and always found the first one, so it was actually recording the wrong stuff.

D

um So the way application insights works is when it gets. When it's about to do a fetch or xhr call, it actually drops a mark tag in the resource so which is unique it for every single thing so that when it finishes it can go back to that mark tag and look directly after that mark tag for the for the url, that's after and then once it finds. It then delete the mark tag, so it doesn't keep consuming it up. So it's always got the exact resource timing, data.

D

But it does delay the ajax call, which is why it was a hack that I needed for office, but it's um not ideal because the same problem will occur and that if I'm waiting to get the perth data and the page never gets away, I haven't even fired the fetcher exit out of it. So I've lost that too.

A

Sometimes the the the other, the the other piece of information that I can add to the navigation performance versus the span is the span. Duration currently uh is recorded when the window load event, fires and window load is just like one of the navigation timing attributes on the navigation from the navigation timing api.

A

So if, if the net, if the window load never fires, then the span will never finish.

C

No, I I hear you, I think.

A

uh Let me just just one more piece of piece of detail there, like so like with the navigation timing event: um you know you can you can send it uh as when the window load, fires or you can send it. When uh the browser is unloading and like when it's unloading, you can get at least some timing information, uh so it may be, it may not be complete. You know, like the window. Load. um Timing may not be in there, but you get something.

C

Now I I feel like there is scope to to do that uh with spans itself, where uh you know all of these uh top level objects, you know, can still be uh spans.

C

uh You know there is a an internal reason for us like I why I want all of these to be. You know spans, so uh you know so that could be a little biased opinion. There.

D

And- and you know, by defining it as a event like I I I keep, I know hopping on a little bit- I'm not precluding flying it a as a span, so you could still have an instrumentation that still creates the span and then attaches like the page view event to the span uh and you can sit there and wait and say well, actually I want to create a child span or I want to effectively add the pg performance, the the the navigation timing as an additional event on that same span or on a child span.

D

Yeah. That's that's entirely up to what you want to do. um I'm just saying from a micro, microsoft perspective we won't be using spain's.

C

Yeah, I think the um concern I have is I I think there is going to be a a distribution from open telemetry um for for instrumenting uh applications, and we want to be able to. We want the customers to be able to continue using the the same instrumentations.

C

And and point uh the exporter to a different backend, a different vendor's backend. I think we we want that ability.

C

So if we each uh I mean the more we diverge, uh you know it defeats. You know that purpose uh of making it simple for the customers.

D

And there's two ways to do that: um one is you have a different set of instrumentations, so I think you have it. You have a distro and that you know ultimately, that's that's one of the goals of the sandbox when we can get it working with web properly is we could have a an example distro, but I see these as individual instruments either either as individual instrumentations or you can.

D

We could put a content uh on the interpretation to say that you want to spam this or not, um but at the end of the day, it's the event and the event content is the payload how you how we get it there I see a span or a log event, is just the two different delivery mechanisms.

B

D

And there's pros and cons for each depending on the event yeah um so so like for fetch and xhr yeah, I'm happy to let's you know we define the event and most likely the default instrumentation will will create a span for those, because that makes sense for those.

D

um What we're really talking about do or don't we have a span, is the page view and the pageview performance. um So, okay, but I want to try and define the event as the event and then let's say you know whether you, whether you do you don't include a span, should be but should in quotes. um We should be able to boil that down to a conflict on the instrumentation, um if not, we have two different sets of instruments, so it's instrumentation implementations.

B

Okay, okay, yeah yeah.

C

So so, given that uh you know these um instrumentations are already part of the uh hotel js today, I think that that will form kind of a base as a reference. uh So.

D

Well, if you look at them, they really just define the fields. So it's not that different from what martin's already done with the the the timing stuff, because they're pulling the same data um yeah, it's just how it's represented so yeah. As I say my my biggest thing is, I don't want to see them represented as individual events, which is what they are today. I want to see those individual events wrapped up into a single event, um so you fire one event with all those attributes. Yeah.

C

No, that's! That's a given yeah that that I think uh yeah. There is no uh argument there. Yeah.

B

Yeah um well, someone who isn't that female with browser might argue that events have a built-in timestamp.

D

Yeah, but the way they the way that they add network uh it's in this document somewhere the two functions which unfortunately, are released uh as ga yeah.

B

But I don't mean implement current implementation, I mean when you go to a bigger open parameters. Spec, you know, make a pull request. There's gonna be people who have no idea about browsers they're going to look at me, but this is already that possible timestamp field here. Why are you you know you have to make a better argument about this.

C

I I think um the uh argument to me is uh the current structure is, is hard to process in the back end. uh So it's more of you know that kind of reason, but, but I agree with you that they they actually are individual events that occur in a browser as the page loads.

C

So they each parameter, you know, does make sense to uh you know to be called as an event, but but I think the way we put them in the object we send them on the wire, I think uh ultimately uh for for for us. You know if they are all in one place.

C

In one event, in one object, I think it will be easier to for from access perspective.

D

Yeah because I I just see from a different person, I don't see them as individual events. I see it as different attributes of an event, but it's like the page load one's a good one where you say well, the page load event occurred and it started at this point.

D

It did the dns lookup at this point you know they're just attributes of the entire pageview page load, so we can go round around our circles yeah, but that's the way I see it um and in terms of the start time, when you start a span, I believe the start time today is at the point that javascript ran not the point at which the event occurred. So.

B

It depends on which you're talking about the little fetch or the document parts.

D

uh Well, they they get around it today by affected yeah, creating them as events and then injecting the the um the time as the which is just because that's now.

B

I'm pretty sure for document uh load and resource spans. They set the start time to where the fetch start was.

D

Of the actual span or over the event of okay, I didn't see that when I was looking, um but you definitely see it like this time, unix nano is the the extra bit that they put for the individual event.

D

um Yeah I was looking at the contraband the thing the um the existing instrumentations, which are, in the contrary, repo, which is the ones we're talking about. um There was an issue that came up yesterday uh that amir pinged me on um someone's trying to add some of the http conventions to the fetch, um and you can't get the test to run and when I try and run the test. Yet none of the browser tests are currently working in the contrib repo, at least for me, and apparently for him.

D

They look like they work, but they're actually failing silently, at least on windows,.

B

Yeah, it just checked yeah. They said to start them to from the performance entries.

D

I've got a link to that one yeah.

B

In chat and then screen right.

D

There's my chat.

C

So is this an attribute this parameter.

B

Yeah, this is where you set this pen and start them manually start. If you don't set it, then it's your current time but got it.

B

So that would be this yep.

C

And what what is used for the end time.

B

Now, up a bit this unit resource pin up here.

B

This here got it okay response and.

B

B

A

Yeah I mean there's there's like multiple ways: this could be modeled yeah yeah um and I guess you can think about it different ways, but I've been always thinking about it as like, the minimum, the minimum, the minimum data that you would want from browser is events, and so, like you could you could. You could think about like having the minimal sdk as just generating certain events that aren't the most important and and then like?

A

If you want to tracing, if you want tracing on top of it and like more additional context, you could include like the tracing in it um in in that package,.

D

And I do have some internal teams like we have multiple skus, um which effectively it's a collection of our different components for that exact purpose, because we have some teams that have very tight device requirements um for memory. So they can't include everything.

A

And the the spans for sure give you more information, uh they give you the context. They give you the relationships and um but they're they're. You know they they're not like the core, maybe in my in my mind, but.

D

It depends on the use case, yeah some use cases, the the core will be spans and logs will be. You know, events will be extra.

D

Yeah swings around about, but that's why there's three signals realistically, that's why they're broken up the way they are because they are probably separate domains.

D

But I think if we define an event as the collection of that data, and then we just say it goes in a long event or it can be included as a spam event. um I think we leverage one lot of work instead of defining it multiple times.

A

Can I just quickly clarify on this one, so I the uh the reason for being able to send the same type of event as spam event also is just so that you have it included in the same payload.

A

Is that because, like otherwise, you know.

C

It will be one.

B

Or the other, not both.

A

One or the.

B

A

Right right right but, like you know you could you could generate, you could send the span, you could send the log separately and you could just link them through the span id on the log right so like. Why would you want us? Why would you send it as a spam event? I just want to clarify that.

C

Yeah, I think you know it's just for us.

C

You know some correlations happen. You know uh as the data during the injection time. uh So if we were to, you know, get the span first and and then we have to wait for the other event to arrive, so so the uh the the so it processing becomes a little stateful. So we want to ensure that both this pan and that event they arrive at the at the same service instance.

C

So things could get a little complex, but if they are in all in one object, you know that will ensure that it will all get processed in one shot.

A

Yeah, that's what I thought.

D

Yeah, that's really a back-end optimization as well for payload, um probably to answer. I think the question you're asking martin about.

D

Why would we want to define it and then send it as either a span or as an event, a good one would be resource timing if we define the resource timing event as containing this set of data as part of page load, you may want to fire a whole bunch of resource timings for like how long it took to load the css, how to load the images everything else you can harvest from the resources um so and you might want to include those in a span because maybe you're using a span for the for the payload or you might want to just say the individual events where for the fetch and the xhr, it would logically make sense that that the resource timing would be included as an event in the associated span.

D

For that picture, except our request.

A

Yeah I mean, but we could still, even if it was part of the span, you could still send it separately as a log.

D

Correct, which is what I want to do- I want to define the shape of that event, so we can do either.

A

Yeah so so sending is sending it as a span. Event is just an optimization for the back end.

D

uh Or logical grouping of the when you look at fetching etcher yeah.

D

And you know I I you know, there's going to be both cases like here, we have uh santosh and myself are coming from, at least for the page view for completely different angles like I don't want to send the page view with the page with the pageview performance, because our backend can handle it, because when we receive it on our front end, it effectively just stuffs it into storage and it gets processed uh further down the track, uh not even by us we're just the collection team.

D

um So it's the the back end guys further down that stitch it all together, and we already have all that in multiple different internal hierarchies, and that's also what azure monitor does today in the portal it. It looks up the effect, the cosmos data cluster and does the grouping based on the operation of the I e, the trace id for linking them all together, and they.

C

Could have been.

D

Received by different servers as well.

C

Yeah, I I I'm I'm still not uh 100 clear. Maybe I I'll wait until you know you have a prototype uh on on how you would send the first event um for the page view, uh because at that point you wouldn't even have started the trace.

D

So you still have it. You still have a trace id that you that you should have.

C

So so you would, you would start a trace and and not send any span against it and then include that trace id. In this event,.

D

Yeah, so if you look at the document, I think it's, the document load instrumentation uh bart added some code in there to look up the meta tag uh that should be written on the page to know what to see the trace id as um same thing. That's really just saying use this trace id as you're leaking sorry, um and this comes back to the session id type discussion, because that all have the same session id.

D

But for me I also have the same, create site across.

C

I think I think there is a scope to keep all these three spans. The document load document fetch and the resource fetch all those three spans and, in addition, send one more event standalone event with the same trace id in the current instrumentation.

C

Because the the document load span as it stands today, it really includes the navigation performance timing info and the document fetch is about the.

A

And we think we think that that should be separate event, though right, the the performance, the navigation timing, performance, navigation timing should be a separate event. It should no longer.

C

A

C

Yeah, so that I think uh that I I don't know if, uh uh if that's what you meant that I thought uh I I thought you only wanted. uh At least you know, you know, as a general document that you know these are the events um you know, and these are the attributes of that event, uh but whether they come as a log event or a span event that something uh you know the same instrumentation would generate in different ways, depending on on some flag right and and then that would also need.

C

That we update the trace spec trace api to be able to generate uh standalone events for for the span event. So so so not so the instrumentation library itself will remain the same. It's just that the trace api. We need to extend, uh adding a flag to to automatically generate a standalone event whenever somebody creates a span event.

D

uh No, but if you're, if you're using spam events, then you're going to spam and then just say add the event like we don't have to change that. But but it's a case of, if you happen to, if you want to include the pageview performance event in your span, then you put your spam and just say: add event: pages performance and away. You go um as opposed to you just want to fire the pageview performance quickly now and and get it going.

D

um If you remember back a while ago, um um we talked about potentially in the future, and I think it's a long potentially long in the future um unifying span, events and log events, so that under the covers a span event actually fires a log event.

C

D

That's sort of part of the rationale for the training also for trying to define the event as one thing, so you could you could in once we get to that point.

D

You could say I'm going to start a span and then, when you say, add an event under the covers, it goes and actually fires a log event there and then, even before the span is finished, because now you've got the full trace id associated with that spam for linking and that works for us because of the how our back ends work, but it sounds like it won't work for you because you want it, ideally all delivered in a single payload where today, the logs and the span exporters potentially you're sending you know two different network requests um and therefore could hit two different servers.

D

If you've got multiple collection servers.

D

But I think that's a long way down the road, and that was where I started on my nested attributes trying to define how that's going to work. I think we will. You know, because I got tigran to give me some feedback and I've implemented most of his suggestions. So we'll probably be able to say nested attributes are only supported for logs coming back later and say. Okay now we want to do nested attributes for span events.

D

I don't think it's going to happen yeah any time this year, maybe not anytime next year, um maybe as part of the semantic convention group. We can work on that, but.

B

Anyway, ramblings.

A

So I'm wondering if it would make it would be helpful to create a prototype of this and just show show you the different scenarios and then discuss it from there.

D

A

So I I have been I have been so I have that logs api, um it logs api pr open in js and and I've been also I've also started working on um an sdk that implements the api.

A

um So I'm not very far with that, but you know once that would be kind of the next step to have a working prototype.

B

A

um But maybe for like, for I don't think I can do it for tomorrow, but maybe for next week. I could just put something very quickly together um that generates these events. We're talking about the um you know, the the pageview event, the performance, navigation, type performance event and the span and see like how different scenarios of what could happen on the page would generate different things.

D

Yeah- and you see it comes off- the box um like ram, was going to be driving this, but he's out this week, I'm just trying to see when he comes back um he's back next week, but he'll probably be catching up based on his time off. So it's probably realistically september 13 14 before he'll be back in the meetings.

B

D

um Yeah, so I just jumped in so we're currently going through planning, because we do planning on a semester basis and currently we're we're we're carving it up so that our next, when our next semester starts, I will be you know, 90, on open telemetry rather than the five percent that I am at the moment, um uh and then I got the uh my other person that I haven't for the managing the sdks she'll take over uh more direct definition.

D

We are comparing a beta, so I I do have a bunch of stuff I have to put in place first for her to build on top of, but um the plan is yeah. I'm gonna, you know at least start switching more to uh time, open telemetry, rather than my my as I say, my five percent, which really gets concerned about meetings pretty much every week today,.

A

Is it gonna be mostly on on the client side or on the browser instrumentation? Okay,.

D

Awesome yeah, so, uh basically, the the goal of my of the semester will be to get the sandbox going, get all the minification happening and ideally uh get a proof of concept uh of getting open charge working the web. That's I say ideally because I think that's a very huge task to try and achieve in six months.

D

Yeah, especially considering like one of the reasons for creating a sandbox, is I'm all isolated. So we can we'll have the minification branch and I can just keep going and pounding and making it as small as possible to get that proof of concept going um taking that proof of concept and then pushing all the code changes back to the main repos.

D

That's not going to happen in the six months, but at least we'll have everything going by then.

A

Yeah I, as I mentioned to you, um I have to scale back a little bit from hotel, but it just means uh I I was I was assigned 100 to it and I'm probably going to go to 50 yep.

A

So I'll still be involved and I can still help out. I think 50 is to a good chunk of time, but.

B

We'll see how it goes.

D

Yeah we've been planning for me to do the switch for a while and it's just a combination of um people leaving and having to backfill the team and having no one else to to do all the internal work and and all the internal work. So.

B

D

um I guess on the sandbox it's still blocked daniel hasn't had a resolution yet on getting the pr in. So that's only the first pr to merge in history um because of all the other internal stuff and coming back and catching up like it took me ages to catch up on all my emails. After being out, um I haven't had a chance to work on my my next little script to effectively take that merged history and munch it back into the format that I want.

D

um It's probably really getting realistic. It's probably still not a couple weeks before I'll get to that point as well.

D

So I have hope- and every time I say hope I have a manager, always, I hope, there's not a plan that rings in my head. Every time I say hello, but I hope that by the end of september um I'll have the sandbox operational.

D

Considering I wanted that, like at the end of july.

A

Okay, great and from from my perspective, I've been trying to just focus mostly on the um jsm current js sdk implementations, the the logs api and sdk um just so that we have that available. So we can start creating. You know: prototype instrumentations,.

D

Yeah, um so are you doing that in the contrib repo or the the js repo.

A

It's in the js repo, okay, so I mean the instrumentations would be. I don't know where the instrumentations would go, but uh but the api and sdk the logs sdk obviously would be in the core.

D

Yeah yeah, because otherwise I think we have some instrumentations in the js and then we have three of them like before. One is user interaction, one that we haven't really defined uh in the contract repo. So the way I defined the sandbox script is, I can quite easily merge the history from the control repo with like adding three lines of config to a json file, um but I yeah, I think, eventually we're gonna have to merge all three and then harvest all the web stuff that we need.

D

But, as I said at the moment, I spent a good chunk of yesterday trying to get the web test running in the contrabrupo again on my windows box.

D

It's a combination of updating, webpack and um karma that broke it. I tried rolling that back and then I've got another dependency conflict. I'm going to solve so I'll keep I'll be working on that for probably the rest of today.

D

So I can unblock this other pr, which is really just adding two attributes so that we can then create a web test, because the webcasts are broken.

A

A

The the other thing that we still have um that's been basically put aside for for now I get, I guess, is the um the resource attributes session.

D

A

I should have been waiting.

D

For ted to come back to drive that.

A

D

I don't think we've gone anywhere like we have a number of people out internally and riley's backfilling them, um so he's quite overloaded at the moment. So I I don't know where that's got to in terms of getting us assigned a tc member, considering, I think riley is probably the most relevant person in the tc today, but I don't think we would have the bandwidth right now.

A

I had to kind of uh laugh a little bit because, like the one comment that I already put in that project tracking issue like he said, uh the name of the sick is confusing and I like we went through that discussion like we uh used to be around and we just changed the client instrumentation yep. um So I was thinking it yeah. It would have been good like if the.

A

If the you know, it's just approved proof that, like the uh tc number, would have been good to have from from the beginning, because yeah yeah.

D

Yeah so yeah, so riley mainly owns the net uh implementation of the sdk from our broader team. So you just have exposure to client stuff, but definitely not browser. That's really just our team.

C

Yeah ram would have been an easier name. That's a.

B

C

Standard name in the industry.

A

But I think there was a pushback for ram because because some people thought it was wrong back end.

A

I think I think somebody that brought this up. I think ted or someone brought it up like you, should rename it or maybe.

C

It was morgan, morgan,.

A

Yeah, because around like some people were confused, that ram was was not client, but it was back and run. We.

B

C

B

Rum client instrumentation said anyway.

A

Okay, well, I think we're at time yep.

B

Okay, all right thanks very much.

B