Open Telemetry Uncategorized, 14 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-02-14 meeting

Description

Instrumentation: Messaging

A

A

A

A

B

Good morning morning, good morning, uh there is nothing on the agenda, so maybe we can wrap it quickly.

B

B

C

Hi good morning, um I'm, just uh I'm I have to leave early today. I have a doctor appointment in about an hour yeah.

B

Yeah no I think um uh I I, don't have any topics um unless others have.

C

I, don't either I mean the the thing at the top of my list is the log SDK and I'm just waiting for the changes from the contributor and um if they don't, they don't get to it this week that I might just uh I might just uh um do the changes myself to their PR IDE.

B

Yeah I recommend that anyway, I think you can Fork off of his Fork yeah uh and then create a PR from there.

C

Yeah yeah, they said they would be able to do it this week. So I don't wanna. Oh, is it okay, I didn't want to like uh you know, take over, but okay, if they, if they don't have, if they don't, they don't have time, then I'll do that. Yeah.

B

B

Okay, now did you have any topics? uh There's nothing else on the agenda.

D

um No in educated, you know the the sandbox is moving forward.

D

uh I tried to merge in the next one and for some reason, the es linked, it's failing, which is why the the merge is failing so I'm trying to understand what's going on and even though Autoplex is enabled it pales locally as well so I I, don't know why I've just compared the the current Branch with the the so the current ones is 1.4 I've merged as a 1.3, and they look the same so I yeah I really don't know why it's planning to build.

D

um But these are the sorts of issues I was expecting in terms of emerging through, so I I just need to sort it out so that I can then move on and get the rest of the packages in there.

D

But I said in the JavaScript sector last week the the plan is to have all this. You know up to date up and running by the end of the month, which I think I can still do.

A

D

um It's tigran still joining tomorrow,.

A

C

What I've heard but I'm, not you know, maybe you should bring him to double check.

D

Yeah, so uh do we know what we're going to talk about so that we're not just ends up being nothing.

B

Yeah, let me helping him.

D

um And in the spec seek this morning, the renaming of HTTP user agent to just user agent staff. It looks like it's going to go through. They added a comment on onto the pr saying. Do we want to also add the renaming of browser user agent to the same PR or I'll, follow up with a different one, but um that was not one of the points of removing HTTP user agent must do that.

D

Try and stabilize that one. So, let's uh imminently and I think that'll be in 119, which is the next version of the spec.

C

Yeah, we might just want to I, don't know- maybe you don't have to, but you might just want to like right now. Does the browser spec says that the user agent in the browser namespace is optional and only only filled in when the other fields are not filled in yes,.

A

C

Just make a note: there.

D

Yeah um yeah because it looks like the new name they're going with is a user agent.original which, which is the ECS name.

C

Yeah, we just don't want to uh send it with every payload yeah long.

D

String yeah because, like it's, the collector's Gonna Get It Anyway yeah, the request is going to happen.

C

Yeah I mean so so far the topics with tigram, um it's it's things that are blocking us right. So, like the the events, API discussion is going still going.

D

uh Yeah, the renaming of the logs. So let's, let's start making notes here: I'm just gonna yeah.

B

I think the events related anyway we're actually discussing in the log Sig so yeah, maybe you know we should not spend any time on that topic in in when he joins us. I think the critical one is really the ephemeral resources, the varying resource, attributes and I. Remember uh you know his positioning um has been to prototype um the compression aspect and I think we just need to dig out previous nodes and keep it ready, so I uh I know I. Never you had provided some context on it uh previously.

D

B

Yeah yeah, maybe just refresh the starts, and we could uh bring it up. I think the other thing is uh uh Josh Smith and tigrant. They had a conversation about introducing additional attributes in the resources anyway, for other purposes like for identifying metrics, um so we could check with them where they are and if, if they are going to add additional types of attributes in a resource, you know we could introduce in a one that uh changes as well.

D

I'm just making notes so that we've got to make a look at tomorrow, yeah just adding additional attributes to resources that we said.

B

Yeah additional attributes to a resource, so current uh attributes can be, can continue, but we could add an another uh uh collection of attributes that will identify the metric.

B

Let me get that.

D

Yeah, yes, uh clarify the noise so that it's just so that we don't end up forgetting something.

C

And then the last last topic we um maybe not lost, but one more important topic is that you need to help with Landing the semantic conventions for events yeah.

B

That I I don't see uh I think once I'm just waiting for this event.data PR to be merged and with that I I think we were ready to. You know introduce that PR yeah.

D

Yeah I think we got enough sign off for the uh nested attributes done last week. uh You know that's tigrant, one, sorry we're getting close on that.

C

Okay, yeah. We just want to make sure that if, if he's, um if he's the representative or TC for our group, then that.

B

He's not no I I, don't think it's that way. Yeah he's not going to, uh as in he's he's just agreed to join and listen in and and see if he can help but yeah.

C

Okay, yeah I thought the the original plan was uh like from Ted's project proposal was to have one TC member assigned to a working group. Yeah.

B

I I don't think this is uh as per that plan. Okay,.

B

So um never I sent uh in the chat uh the issue where they discussed about tributes for metric identity.

D

D

Okay, cool um I, I! Guess, if you think of anything between now.

A

D

Tomorrow, just just dropping me here, so we've got something to, um but.

D

So the biggest thing with the compression is the fact that is your browsers only um which at this point is probably not an issue, because the color code will only run in your browser anyway.

C

And there was also that also had. That was also arguing that conceptually these attributes don't make sense to be on every individual signal like that. There's just like a missing piece in the data model for this kind of thing.

C

B

Yeah I'm thinking we should call it as a you know: the state of a resource and the state you know, can change so I think the state term I I find more suitable. um So we could suggest that.

B

It actually applies even to several of the back end infrastructure as well.

B

B

Telemetry, you know its state could be changing.

A

C

So is this really blocking us like I,.

B

It does right, it is blocking, because there are several uh things in in our list which uh are in that varying uh resource attributes. Section.

C

Let me bring that up, but I mean if we, if we like as a first first Milestone, we implemented it as an attribute on every signal and then down the line like. If, if you know, Hotel introduces something something like the FML become we can. We can update it. To that later, I mean there's gonna, be you know, backwards, compatibility.

D

um Yeah, it's been like the discussion that's happening around at the moment for um like in the spec seek today that was talking about changing, b y to bytes, um which is not considered a breaking change um like if we start passing it as part of the attributes. They'll then be pushed back saying, that's the standard way, um so it's more a case of if we want to go with it in there once.

D

Let's try that first, rather than saying uh we're going to model it without that and then hopefully get it later, that's um if we, if we try and push it first and then it fails, we've got that as a fallback, but I prefer to.

C

D

I appreciate with this to.

A

C

I'm gonna have to go back to back on our notes. uh We've we discussed it so many times last year, yep.

D

At the end of the day, we could do all this by having attributes past and every event just the size issue that that's going to cause um on the you know. uh Maybe I should add that in here, um because during unload we can only use the um send beacons or fetch with API at least currently there's a new one coming out. That's not standard. Yet.

C

But, and do you also agree that the from data modeling perspective like it makes sense for it to be on the resource?

C

um Aside from the you know, I'm sure we're gonna get pushback on the size like to the compression yeah, so I kind of feel like there's, there's got to be a little bit stronger. Oh.

B

Yeah I mean, if it comes to that then yeah we cannot. We can agree to disagree and move on.

B

Because for regarding size, I'm sure uh there is also an argument uh that can be made where you know in in our Legacy products: uh Legacy systems. You know we, there is no concept of uh resource if I'm, if I'm not wrong, and therefore we are attaching these uh attributes or this, uh these items in in every pull everyone yeah yeah and everyone already. So so we we want to make things better, uh given that there is an opportunity.

B

um So that's all yeah yeah.

D

um Has anyone tried using the compression API within the beacon because I know with thin Beacon, you can't specify any headers, um so you know I guess you could always use a Fetch with keep alive and you can specify headers, then to say this is a compressed preload. But we if we're using, send Beacon or we're going to use then Beacon, then we can't specify that the payload is compressed unless that compression API I still haven't looked at the having a time to look at the new compression API.

D

If that automatically changes the content type to that's compressed, because that would play into the 64k limit like if we can use compression on that. That would reduce that somewhat. But if we can't, then that's even more critical to not repeat it, especially considering attributes or uh when they're in Jason.

B

Would we be using send Beacon uh anytime uh nav, because I thought uh the xhr XML HTTP request also supports a similar, a flag uh that that gives similar functionality is that only in the newer browser.

D

So there is asynchronous um yeah, which is completely blocked. You try and do that. While the page is unloading it, it gets wood straight away. You cannot use synchronous xhr during page unlock on your browsers.

D

That's how you do it on on older browsers, but you just can't do that now.

C

In my opinion, we have to use CSN Beacon yeah, because that's that's the recommended API for that better reason for that very use case that we're you know when.

A

C

To send the data.

D

Yeah there is um like you can use Fetch and with keep alive, um which also exists, which browsers that have effects of people like under the covers use that percent Beacon.

D

um But you still don't get the response back um and I'm just trying like there's a new API that I've got down to investigate.

C

Oh yeah, there was some some new proposal, foreign.

D

Or something from memory.

D

There it is I'm just grabbing my internal.

D

Painting because Chrome.

D

That's on there so I haven't looked at this one in detail, yet either they're saying it's going to start shipping in 112.

C

D

uh Like this came up this week from an internal team, they they want us to implement this. It's a quest to get around this 64k limit, but I say apart from creating the work, I'd have to go. Look at it. I haven't actually done anything.

D

Because we won't get to it until uh at least probably April May time frame.

C

Yeah, so maybe something we should look into before tomorrow, like the compression with some Beacon and maybe look at this new API yeah.

D

But it's still going to be okay. This is only going to be chromium, it's not going to be there for Safari like.

C

Right right, right, I.

D

Don't believe the compression API is implemented in Safari and correct me if I'm wrong, I put that in the notes.

C

Is sunbeacon even available in safari.

D

uh I believe it is it's not not available in um uh in ie.

C

Yeah, okay, it is in 11.

D

Yeah except Opera, Mini.

A

C

Don't have anything else so.

D

um Yeah I, don't think I have anything else either that was okay, so I just wanted to be prepared for. If Stephen does turn up tomorrow, we've got something.

B

Yeah uh yeah, he replied yeah, so he says he will join yeah. Okay,.

C

Cool and do you have um so maybe this is not a discussion for tomorrow, but do you have like any strong opinions about like what the event API and SDK should look like and I know I keep bringing it up but like we need to resolve it soon, because if you want to implement prototypes, we need that um um I.

D

I think we're we're already pretty close. We had like an admit event that had the name, the the data effectively and then a third one which was additional attributes, that's I, think that's the minimum set we need with. The third argument would be um optional because not every event, not everyone was probably going to want to do that.

C

um Yeah I meant about this structure um where, where the the events SDK uh has is, has a separate provider, a separate like Global provider and set of classes from the log providers.

D

um Yeah they should be really just thin wrappers or you know like if we have uh an event log SDK, it should just be a thin wrapper which internally initializes the the logging uh or you know, passes down to the logging SDK um yeah I. Guess the open question is for the domain.

D

Do we want to say we always like if you've got a different domain, we always go to ask for uh as a provider I think is the equivalent um or do we want to have that as an optional extra on you know, we have another emit function which says: emit domain name combination, I'm fine, either way as long as we keep the SDK as thin as possible.

C

Yeah yeah, so so I think there were some there was. There was some pushback on um on having like the whole um kind of missionary around the event event provider event: emitter yeah, you know event, processors, um all that having having that like it also almost makes it looks like there's a additional signal. Yeah.

D

We we don't want processes, I think we just say we have. The SDK is there's a basic set of um help us, which I think uh tigrants got uh or is it in the Fig? The spawning he's got a PR out to rename the logging API to the logging, the log Bridge API, um and it's part of like reading through that.

D

It sort of says that the event API is really just a a helper functions which is really oh I, think we we want to have it as um we're just abstracting it out, so that we can have. If we want to do a you know, a console version for testing, or you know, a dummy version for testing.

C

But it's going to be separate from from logging right, correct.

D

A

C

If you select, the instrumentations will not know anything about logging, they will just interact with the events. Api yep.

D

And at the app all the the thing hosting it doesn't, you know provide it. Then we still have the knob, which I'm not not quite sure how I'm going to deal with not wanting to have the no Ops in there, but still having the code work at this point, the master create a function that just generates dummy functions. That does nothing.

C

And then, okay and and then for end user configuring their application, they will um they will. They will have to create an instance of like event, SDK and register it with as a global provider. Or will they.

D

Yeah, it's gonna, it's gonna have to be in terms of like having the event API separate it's going to be registered, but when they register it, they just register it with Logan instance. At that point, all the names we just say you you're registering the event SDK, which happens to be a logging event, SDK instance. So therefore, you give it the same um basic values. You need to construct it, but if you don't implement, if you don't register the logging SDK as well, then it'll still do nothing.

C

Yeah yeah yeah, but that's that's like the implementation detail of the events. Events SDK or is that like more closely coupled.

D

um It's at the point of adding it to the registration that we need to specify. Okay, when you're using this SDK, you must also have a registered logging SDK.

C

D

If you don't, then effectively, you know secure will end up picking up the knob logging instance.

C

Okay yeah, so so like there's, no processors. No, no! Nothing like that. It's just like a very simple SDK class that just takes the dependency on the log SDK yeah um and, like all the processing and exporting, is done through the login SDK yep, um but I mean in theory. You could implement a different implementation of the events. Sdk that doesn't rely on the logs. You.

D

Could yeah we could have a console one you know protesting, will well one of Mach One yeah and at some point I can Envision someone wanting to have that generate spans or suspend events.

C

Okay, so that's yeah, that's that's totally! Fine like I, just don't I, just I, guess I all I care about is that, like the instrumentations are not aware of blogs. The logs API yeah.

D

Yeah, which is the point of having the the event API, so yeah they're, not aware at all, um okay yeah, but yeah. We don't want to go fully blown and make it a fourth tier like uh Riley was talking about um actually haven't looked at. This he's still got that PR blocked, or is that ytigo knocking off the second one.

B

But I didn't follow the part uh on the processors. uh Will there be separate event, processors or we will have to use uh log processors only you.

D

Have to use log process, there won't be any event. Processor.

C

But that's only because the SDK, the events SDK will now Define it I mean you. Could you could Implement your own event, SDK? That might have some kind of concept for processors, okay,.

B

So there's no limitation we're just choosing it that way. Yeah.

D

Yeah yeah we're just not going to Define it because you know we don't need it at this point. Then, if, if we do I think we get more pushback pushback saying that this is uh we're defining a fourth TN which even gets us back into the discussion world. Do we then go a whole hog like we had on um on slack there and just push it down that path which I'd prefer not to, but that's always a possibility.

B

D

Yeah and unless we see a need for a processor which I don't at this point, um let's not worry about trying to Define that, let's just keep it thin and lightweight.

B

B

We will, we will definitely be needing a exporters event. Exporters.

D

Yeah they're about they're blog exporters, yeah.

B

Which will be based on uh log exporters, yeah.

D

So yeah you you so.

B

D

When the implemented, then you'll quickly, Implement a log.

D

B

Yeah, so so the application developer. uh When he puts together the different instrumentation libraries uh he will have to attach a lock exporter.

D

Yep and then that's another argument for defining having the shape well defined. So during the log exporter he can look and say: oh, this is an event because it has an event name and event domain and event data. Sorry it'll make that easier. At that point,.

B

C

Okay, I guess that's a good start and it doesn't close the door on other possible implementations.

B

Yeah yeah I think if needed, we can, we can add it later so that doesn't need changes to the instrumentation. So that part is good. Yeah.

C

All right, I gotta go so we can, and here yeah, okay.

A

C

To you tomorrow, yeah.