Open Telemetry Uncategorized, 21 Feb 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-02-21 meeting

Description

Instrumentation: Messaging

A

B

Good morning,.

A

Do we know if uh RAM is going to join or we can start to.

C

uh Not sure about Ram I Know Carl is out today. Okay,.

D

A

I added a few things to the agenda.

C

B

B

Pr there's been some updates to it over the weekend. Yeah.

E

B

I've started uh reviewing it, um and I should should be able to finish the review today. Okay, but I do encourage you to also take a look at it. I mean yeah.

B

If you have time.

A

um Is it the same PR it's NPR.

B

B

Oh yeah I think so.

A

Okay, do you know if I, uh even the exporter is added? No, the.

B

Exporter is not in this one: okay,.

A

Yeah I I'm just curious, like, wouldn't it be easier uh for you to verify things end to end uh in in one go.

B

I think it's gonna be easier if it's multiple smaller PRS I.

A

Mean how do you, how do you verify um that the you know, whatever processes you add or you verify through unit tests.

B

um I mean there are some exporters like there is the console one. So you can see you can see the interfaces, so you can see. You can definitely test that exporting happens.

E

A

Okay, yeah. um Okay, that's good to know, I! Think. Let me put this here.

A

Yeah I was uh um thinking uh like when would be a good time to add, support for necessary attributes, because I I sense a delay on the you know, uh the events API PR um and and given that uh I mean both both the you know, the nested attributes in in general for for Trace.

A

um You know that PR and the the events API itself, I I'm I'm sensing, some potential delays.

C

A

C

Shouldn't affect us because logs already support nested attribute.

A

Correct correct, correct, but but it does.

C

The implementation yeah it's how we go about implementing it at this point, we'd have to implement it as a log attribute extension.

A

Yeah exactly so.

A

um So, do you want to consider that as part of this PR or bring in as another PR.

A

Martin um something you can think about: yeah.

B

You you mean for the exporter.

C

Yeah, just generally, nothing generally.

A

Yeah because it needs support uh all through.

B

A

B

So it can be separate, yeah, okay,.

A

C

And the way we're we're looking to define the API at this point. It doesn't need it explicitly because if you can say emit name data and other events, then internally we we put data as an extra attribute, but you don't actually have to pass nested attributes at this point because we haven't defined any any semantic convention for an event where data requires additional nested attributes.

A

Oh, so the API itself um is not aware of nesting.

C

Or the the front-end API doesn't need investing.

A

C

Correct the implementation will but the the front end API doesn't.

A

That's interesting, okay, that makes sense yeah.

A

Yeah I think um I did not fully follow. uh You know where this thread is, uh you know going um but I I, think Riley and later uh mic I think they both expressed concerns about whether we really need a separate. uh You know: uh events, API, SDK exporters, the whole uh separate uh pipeline for events or I. Think one part, uh that's uh confusing uh that could delay is I. Think there was one statement uh Riley made I can't find it it's. Basically, what is the?

A

What are the use cases for events other than um you know, durum use cases and the the there aren't many, and until you know there are some use cases, including even the business uh events like like. If customers want to uh create, uh you know, custom events, I I will talk about it. uh Each one I have added here.

A

um You know it might be hard to make a good uh case for the events API uh and, and that's why I'm thinking that we should we should go ahead with the implementation as we like uh for our purpose now.

A

Now that uh you know there is, uh then there is no um a big hurdle um like even if the events API itself is not part of the spec um I I believe we still need to get the event.data into the spec so that the the concept of what an event is, uh if even if that is agreed on I, think I think we're good.

A

uh But if, but if we, if even that part is not agreed on um then, and if that changes, then the back ends might have to support. uh You know two different types of events and and uh our backend teams might, you know, object to it um some um a little clueless on that part. Any thoughts like you know: how can we proceed with some confidence that you know things are not going to change.

A

If we go down this path, um where we assume um you know events API is, is you know we don't worry about, uh you know it being in the spec, uh but we do the implementation.

A

um Do we do? We think we should at least get the event that data into the spec.

C

uh I I think I need to keep pushing on event.data yeah to get that in um there was in the spec meeting this morning. um The Josh and krask have got a an updated spec on what is and isn't Impossible by semantic conventions, um and they started talking like Riley again wanted to pull out logs and events out of that definition.

C

uh But Jack pushed back and I gave a reference to the you know, event: data, PR, saying that you know we will have our own semantic conventions, for we've got data based on the domain name combination, um so yeah I definitely need to get that through, regardless of whether we end up putting in event data or body which is like where we keep drifting in logs and I. Think um uh lunch um from you know McHale that sort of was also pushing back for that, but he's mainly on the um the dot-net side of things.

C

So you know really they will need it, but they have a different set of net events at this point, which are different from what we're talking about here. We're talking about um you know, crew, client, monitoring, you know real user metrics as opposed to a system events, which is what where he was going for. It.

A

Yeah I think I'll I'll bring this up in in tomorrow's log uh meeting, but I am not super clear on. um You know how those events are are used in. You know for Telemetry purpose. What what are the use cases.

C

um They're more for exception cases so way back when I used to do a lot of you know, C plus programming, um effectively, you had to create your own event: API your own dll, to interpret the data um they're really useful for like cracking down problems that you've got in there, which is like when you look at your event, console in Windows you'll, see, like you know, error, warning uh information they're that level as opposed to um crew observability.

C

uh How is it, how is the person using your application, which is the sort of events we're talking about? You don't want to fire too many of those, because you can't overload the Windows Event system, there's too much too much stuff unless you used to be able to.

A

Okay, okay, yeah windows, I I, remember there was a Event Viewer yeah.

C

I see yeah, that's fundamentally still there and that's that's effectively the the API that uh Blanche is talking about in the logs and I think Riley as well, because Riley's also on the dot net side of the camp.

E

A

Yeah I I think it's um it's a little concerning how you know where this is going in in case things, don't uh turn up the way we want yeah uh yeah.

C

For any anyone who who wants to create client-side, SDK and do client type monitoring is going to need an event API, which is why you see there's so many thumbs down on Riley's blocking of that PR.

A

Yeah I think the at this point more than the API the event data is is more critical uh to agree on.

D

C

um I I think we have fundamental fundamental bundle: fundamental agreement on that we need somewhere to put it as opposed to just being this Collective set of attributes.

C

um But every now and again we get someone coming along and trying to go back to a trace and it's like it's not a Trace, um so hopefully I should get to that. The uh well where's my calendar, yeah.

A

So so, let's talk about this right um uh now, I think I. Think um I I want some examples of what those top level attributes uh will be. Potentially you know what are some examples. I think I could only think of um the event. Ids schema URL. If at all you know we introduce them, they may not uh be the actual data.

C

um I, don't want them to be the data I want all the data living in data correct.

A

Correct yeah, so the way um you know like this is the JavaScript API of cloud events. The way.

A

They have done, is you know all the top level attributes.

A

Let me there was an example yeah, so so this one um are.

A

Are even you know this one? There was one with data second yeah, so this one right, um so all the top level attributes um they they have explicitly uh are defined and only only the approved attributes can be at the top level, and so they have not. They have locked down. You know what attributes can be at the top and and then um you know we I was thinking you know.

A

What's preventing us, you know to to do the same, where um anything that you know we accept at the top level has to be in the spec and and then only those can be you know set and that's what I meant I for some reason, due to my my background, I've done more Java than JavaScript, so I keep going to the you know the Java apis, but I think I only meant uh in that example that you, you only allow.

A

uh You know the approved spec approved attributes at the top level. Otherwise everything else goes into the data. Everything else is payload.

C

Yeah, but payload should only be so so the data should only contain the stuff that's defined. For that event,.

A

Yeah but anything that's not in the data, uh it can only be the spec approved item. So what's the critique on that are.

C

A

C

I, you know from a General open, Telemetry definition. We don't do that anywhere else, um which is I. Guess where my hesitation is coming from in terms of some good examples of what those top level fields are. I don't have that at this point um you know we're concentrating on just what the data is, but people are going to do it and they are going to have like log processors that will go and add additional attributes and We Can't Stop Those.

C

um Could we Define at the API and just say? Yes, we have an emit event that says your domain name data and that's it you know we could. We could move forward with that today like, um but when people say Okay I want to add my top level attribute or my common attribute of something we could say.

C

Oh yeah you're going to put it in a resource or something like that, but at some point they're going to want to do it so, which is why I'm saying there will be a your, an additional, optional argument, which would be the other top level attributes and by defining it that way, we're saying well. We can then enforce that that extra set of attributes you give us will not crash the event, name, event, domain and event data, because we'll just block them.

A

Yeah, but that's still um um not definitive, you know it still leaves door to um potential misuse.

A

um Where you know people might, you know, put things in the wrong place.

C

um Okay, so what do we do in in situations where someone's got their own semantic inventions and their own sort of top level attributes? They always want to put on everything going out the door like AWS or Azure, or an application that says okay I always want to pass.

C

um You know my custom user details because I know I can hide my pii or something like that. But how do we do that?.

A

They will still have to put it in event. Data.

C

um No, that stuff does not belong in event. Data I'm, 100 opposed to them, adding their own stuff to event, data that we don't Define. um They can have their own event and their own domain. Fine, they can go, create their own custom event and put whatever they like in their data, but for our event, data. It should not contain anything other than what we Define. No.

A

But that you can't, uh um you can hope for it, but you can't um like.

C

Prevent it right, yeah it'll be wording in the in in the definition saying this is it. This is all they should be. Yeah.

A

So I added that as a you know, the the third uh bullet here, where I think the case uh I want to separate out is there are custom events and then there are custom attributes on standard events.

E

A

uh I think you are you're worried about this third one. The.

C

Third, one yeah, there's custom attributes on standard events will not, we will say well, should not be put into event data, and then you say we can't stop it. People can do it either way, putting it directly in or some sort of processor, but.

A

C

Think, from our perspective, we're saying no yeah.

A

I think, whatever um the API surface, we give, in the events API to enable people to put uh data into the appropriate uh attributes, whether in the even data are in the uh at the top level. It's the same interface we'll have to expose in in both these uh methods um where there are instrumentation callbacks to add additional data. Additional. uh You know stuff to the you know, created events, and there are also processors right, I, think, uh processors.

A

You know they get the full log record, yeah yeah, so processors, you know, are more low level and where we can uh hope that you know they, they preserve the event semantics, but at least the uh the apply customer custom data on an event. uh You know you could you could split them um saying you know, apply custom data attributes and apply custom other attributes. You know how to separate things so that people, you know, uh don't make a mistake on on where uh you know they put their custom attributes.

D

People even care, if it's a mistake or not I mean your arbitrary declaring that it's a mistake, but most people are not gonna care. If they're gonna do this.

C

Yeah I just want the data in their back end.

A

um I yeah I think, uh but when you do the API design, it will be good to at least be clear from our side and then I think that's what Jack uh is pointing out. uh If, if we ourselves are uh not clear, then people definitely make mistakes, but at least from our side we should be clear and.

C

I I believe we are so we're saying when we're meeting an event. You get your event, emitter for the domain that the domain portion we say, emit name data other attributes, so the data is that we're saying for that domain. Name combination only give us the data that we've defined you've got your own stuff. You give us in additional attributes, you don't give us a digital attribute. It's fine! If you don't put in.

A

Yeah, so in the, uh if we go that route, when we implement the the instrumentation callbacks I think we will have to have two separate, um you know functions want to add into data and want to add into the other attributes. You know that way. You know that will match the the event API.

C

Yeah I'm, not following what you mean by add to it's the case once the event submitted. That's it it's! It's committed, no.

A

No, no I think let me clarify what that means. Yeah.

A

So this is the xhr uh instrumentation, so it has one uh the instrumentation config, so the application authors. You know they can configure the instrumentation uh when when they when they configure when they set up the pipeline, when they register the instrumentations, you can pass a config to the instrumentation and say you pass a function, apply custom attributes on span- and you know this um you know is- is given this callback function is given the span index. You know the xhr object, so you can basically do anything with the span right.

A

You, you can add attributes to the span you can. You can modify things on the span, um so so this I'm saying that we should have two separate.

A

um You know uh configurations one I mean in both the cases you know we should not allow uh the entire event object. We should only take uh you know the attributes and, and then one should enable writing to the event data and one should enable writing to the you know top level attributes only you know that way.

A

um You know we we enable clarity.

A

Of of where the you know, the customer attributes are going.

C

Okay, I I see what you're saying I'm, not sure. That's the right way to go for everyone.

A

Yeah I think it I think the main thing is really uh uh to to convince uh Jack tomorrow. I think I. Think the the main thing is more examples and more guidance on on. When you know people should, you know, use the other attributes the top level attributes and when not to.

C

Yeah well from my perspective, they should use the top top level attributes if they're adding data to an event. That's that's not defined for that event, yeah. That sounds wishy-washy, but it is deliberately that way and that, if we say for a page view, if you want to add other attributes that are not defined by the page view, it goes top level if you're creating your custom level event. Well, that's entirely up to you.

C

Our recommendation would be that you put it into Data, um which is this is where we we got into the thing with the logs last week. It's a case of at what point: do they choose a versus B and for our defined events you only ever. You know if it's not part of the defined event you've only ever put in other attributes for your own custom level events. Well, it depends on your custom level event.

B

In my mind, it's like the same. It's the same as asking like I'm. Creating a log should I put this thing in an attribute or in the body yeah.

D

B

So I think the I think the event should I mean the events should have like a set attribute and set attributes methods. And then maybe you should have just a set data right. It's like you, you like, when you put together the payload for the event you set. It set the data and that's it yeah. But if you're adding attributes you can just you know you can keep calling set attribute.

B

E

C

Like and we can't protect everyone from themselves like uh rather than uh apply, custom data uh apply custom data attributes on event.

C

Would it would just be applying custom attributes on on log event, because that's really what it is and if they come along and say, I'm going to replace event.data well they've just screwed themselves, like I I, don't think we can stop that and I don't think we should just extra code that is protecting against a very small amount of people, and maybe there is some funky use case that someone does want to do that.

A

Yeah, the other um issue is, you know: people are not going to only create events through the API yep, um in which case.

C

The whole point of my PR is saying: you're, if you don't create it through the thing, as long as you say, event name, event, date or um event. Domain it'll get treated like an event. Yeah.

A

But it may not even have even data.

C

Correct you may have a custom event which is just um ping. You know someone did this. uh You know it's yeah, it's just a keep alive flag. So it's an event which is just you know, ping I'm still here, but there's that doesn't need a data. So that's quite fine.

A

uh Our you know they might put data, that's supposed to be in the window data they might put it uh just uh at the top.

C

Then it won't be read properly by the back end. It won't won't be considered well anything they put at the top level depending on how the back end deals with it. So if we say it's a page view event and they put all their page view, data and not in data well they're not going to have a page view event. Are they it's going to be a page view event, that's got nothing in it.

A

Okay, so I guess then um this is what we're saying right. You know we are making a provision for even date, dot even data to be put in an attribute called event.data, but whether people use it or not, you know it it. The the semantics entirely depends on you know the event name right so for a certain, even name, the back ends can like, let's say, all the rum events. You know you know the backends can expect data to be an event or data, but uh depending on the event name, you know they they can.

A

They can expect data to be. You know at either places yeah.

C

Let me take a comment that I made this morning on this spec PR on chat, because that's along that those exact lines I.

A

A

And the the Define, the shape of events.

C

No, no, this is another one that I went that along.

E

E

C

And I went and added a to-do to my PR along there, but that's roughly the section where I thought that would be the location. So it is a case of yeah. There will be semantic conventions for our defined domain name combinations, assuming we still keep domain name, there's still that open PL.

E

A

Okay, so so from our side, um then, if I understand further uh correctly I think what your searches are. Okay, not here, what you're indicating is that the definition of an event will still not require event data as a mandatory field.

C

Correct um because there could be custom events that don't need it.

A

We will only will continue to only say that it is an event only if it has you know just these two.

C

A

Okay and the event.data is is available if you want to use, but otherwise you're free to ignore it. Yep.

C

um Except for our defined events, where we will be saying we.

A

Are rum instrumentations have chosen to use it yeah.

C

Because I know we have, we do have use cases where there are custom events where people just say that things saying it's just to keep a light um systems, so they do tend to have other payloads, but they don't need to have other payload um and in terms of like you know what are some examples of other business events.

C

I I, don't have any that I can give you because they're all internal um but yeah office have I, don't know they have about 40 or more events I've defined on their own, so they they're always emitting custom events. We even have some teams that actually hijack our existing events for, for you know, fetching xhr and rename them. um So, therefore, as far as the back end is concerned, as they become custom events because they go to their own back-end table.

C

But once they take it over, we don't take responsibility for them.

C

um I think I see within application insights. We have a cracker method um like I think we even have a tracking event method. um Well, you've never said anything like you know, give us whatever name you like and that'll just get thrown down into the customer event table.

A

Okay, I I just put something I don't know if this is the uh good wording, but um just to capture what we are talking. Yeah.

C

uh I've got a copy. I can find this uh common types, so this is probably a good example of a custom event what it might look like.

C

So in application insights we Define effect. You get a track event.

E

C

Telemetry there you are that we effectively Define this, which is really simple. It's you give us a name. The I key is just identifying you as an instrumentation key, and that's it part C it really. It contains the um the data, so they can go and find their own data appointment.

C

That's a custom event.

A

So what is the definition of a custom event right, I? Think uh in the slack too I think there were some.

A

um uh You know, discussion on that um in, in my opinion, custom events are are created by the application, authors, yep and and not by any instrumentation Library um right, because any instrumentation uh Library, uh you know whether it is created by by the open, Telemetry Community as part of the hotel, repo or, let's say in a third party, you know hosted you know somewhere else. They they, you know they they are defining.

A

um They are going to publish um that hey. You know this instrumentation is going to emit events. uh You know using these conventions right, so they will. They will publish the semantic conventions. You know, as part of you know, their documentation.

C

Then it's a custom event, but even if they do publish our instrumental convictions from our perspective, it's a customer event correct.

A

Now I think um the um the perspective uh I'm trying to bring in here is that uh you know the the library author, the instrumentation Library author. uh You know every customer that that uses that Library. You know they will see the same um attributes right, whereas uh let's say you know we go to uh you know: 10 customers and each customer. Then I have their own Uh custom events. You know those events are specific to them. They are not the backends, don't see the same events across you know: different customers.

A

Right, I, I uh I want to call them, as you know, custom events uh because those you know you will be uh defining per customer and then those are created by the application. Authors. Application authors are: they are the customers, the end customers? We.

A

Right so so, when they register, when they, when they set up the pipeline, when they register the instrumentations, you know they can, they can grab the global event, emitter and and then in their application. They can. They can generate events.

C

Yeah I I, don't I, don't deserve that, but they've got their own events. It's a custom event from our perspective because we haven't defined it.

A

C

Assuming they want to promote it and have it publish an open, Telemetry? Okay, then it becomes a defined event.

A

So uh assuming uh that definition, then um you know we could I think the question. Is uh you know what domain should they use? What uh and uh you know we could? Maybe you know one option. Is uh you know to to define a guideline that hey anytime, you use um your own custom events, you generate custom events, you know have like a the reverse.

C

A

Whatever you use, and even if you switch vendors tomorrow, you know your your domain, you know remains conflict-free yeah, um you know that's one option. Another option is that you, you completely hide the domain requirement from them. You you just provide a wrapper API, which uses a fixed value.

C

So it says custom and then they can put in whatever they're like in the name yeah.

A

Yeah, we could I think the first one is more uh clean. You know we're not hiding anything yeah.

C

I'm trying to I'm pretty sure there is something like this in Spec I'm, just trying to find it closest thing. I've found so far is the cloud definition.

A

um Now the spec has, this far uh in the attributes: I think yeah I think the specification common attribute naming.

A

Yeah yeah I think.

C

Yep, so we can follow the same thing: I don't have a problem with that per Customer, Events, okay and a lot comes down to like. If we can collapse the main name into a single field, which seems to be weird figurines thing is going. It does ease some of this a little bit because then we just have one field yeah.

C

We have two right now, sorry that works too.

A

Okay, so then we are clear on what custom events are. uh The next I think, let's talk about this one too I think the the customer attributes on standard events I think the common um response I heard on on this topic is that hey you know this will affect the the schema uh matching right. I, think we we don't want people to add their own attributes into Data, because then it will affect the you know the yeah, the the schema right.

A

We are expecting that you know this should be the structure of even data for this event name the main combination- and this is what we're expecting and now we are seeing additional data or we might you know uh these.

A

um You know these processors are. Are you know the supply? You know? Custom attributes on Spanish is currently getting. The whole span object, so they might even delete data it, um so it will definitely affect uh you know the the schema validation.

E

B

I would say not that I would say, definitely schema validation, but not just schema validation, I think in general processing of the event on the back end.

C

Yeah go ahead, yeah.

B

Where you have like you know, I mean this obviously depends on on the back end, but but you can just take to even data and put it like in a one place. You know, for you know, for further processing and, like all the other attributes are like, like you know your you would probably display or process them differently. Right like you would have. You would give the data to like some some piece of code that understands the event and can do can display it or process it in certain way.

B

But the attributes are just additional, like decoration.

C

Yeah um so yeah effectively. What we're doing is we're making a guarantee saying for our domain name, combinations, I'm, going to pick on page view again. So for page view we say: you've got these fields so back ends or or third-party vendors can say. Okay, if I receive an open, Telemetry page view event, I know that it should have at least these fields in it and I can go and create some funky UI based on those fields.

C

Now, if there's additional stuff in there yep it shouldn't be so that so they can go drop it and if it's been deleted well, then it's not a proper event. So therefore, the thing you're missing that event is invalid, so vendors can do with what they like on their back end.

B

Yeah yeah and the validation is part of it. Right, like you want to know, you want to be able to just like quickly uh just check like is this data, something that I can visualize or process and.

C

If not, then I'm not going to treat it like an event: I drop it in a custom event or drop the event completely yeah.

A

So in, in that case, uh I mean it's still. uh The reasoning is still schema, validation right, you know we, you want to ensure that uh the data you receive at least confirms to the schema, plus you know, potentially possibly more uh and to to ensure that would it be helpful if we prevent the instrumentation callbacks to not delete anything, but you know they can only add.

C

Even if you do it prevented the instrumentation callbacks, you can't prevent the log processes yeah.

A

So processors, I'm I'm, assuming uh you know they are they are they are low level. They will be used. You know with more care, you know, because processors can do a lot more damage uh and.

C

I I I wouldn't bother trying to limit the instrumentation, probably like the the reason. The apply custom attribute on span exists for a reason, so people can go and apply their existing. You know their additional attributes on there so.

A

Yeah, you know I'm saying that they apply custom attributes on spam. You know today enables you know, deletion to deletion of attributes, I I'm. Only saying that we should, uh you know just make uh small adjustments to it to to be able to only add data, but not delete data.

C

Well, there's a potential issue there too, so you might have. We might Define a field, uh let's say URL as an example which for most people it's fine, but for some environments it might contain pii data on the field. So therefore they want to apply their own level of hashing or scrubbing.

C

um If we didn't allow deletion or at least modification, that would be a problem because we'd be forcing them to have to push that down to a so.

A

So you are um uh okay, but um I think you are talking about being able to update the the value of that tributes, but not the name of the attribute. So the name after our attribute Still, Remains, URL right.

C

A

Because our validation, our schema validations, are only looking at the the keys.

C

Correct um but it's a case of we're not implying any programmatic blocks to stop them so effectively. We're just saying: you've got this callback, you can come along and replace the value they can go and add the value they go, delete the value they could move the value they could do a thing they like, but for it to be valid, uh Downstream and useful um across vendors, then they should keep the name as URL I think you know trying to have the additional code to block it.

C

I think, apart from the the extra code required to do that, especially you know in a browser, um I think it's going to cause a screen.

D

Ed and it being JavaScript third is always a week.

D

E

C

Yeah, father environments, like you know, Java uh I haven't done Swift, but you know you know other non-dynamic languages here, um like c-sharp you can. You can say this is um constant yeah. We could come along and say, let's like seal or freeze the the JavaScript but I I, don't want to go down that part icles. Okay,.

A

So so, what we're saying is that um that our instrumentations will enable people to to update the event and spans, but but what they do with it is is their responsibility. Yep.

C

They screwed up, they screwed up. We can't stop them from from doing bad things, which is the whole point of semantic inventions as well, which is that discussion. That's that there in the case of what you know, semantic conventions are really just saying.

C

This is at the guarantees of what we expect to be coming out of open telemundry clients. They use the word clients, including servers, but you know it's it's just the general thing.

C

So yeah, so the initial warning that I was going to try and put into my doc is some. You know something along those lines saying you know event: data will be defined based on the semantic conventions. um I I think your PR is it. Is it still open or is it.

A

C

That's when Riley blocked was it or uh or you haven't published, yet the one we were actually defining. What some of these look like um I might have to go, grab some stuff from that and give some examples um just a bit of a problem because most of the specs don't have examples like that. But uh I was gonna, try and come up with words along like what we've been talking about again, but.

C

Which is why I didn't get to it on Friday uh like what I did get to Friday I, don't know if you've seen a mountain I've got another PR out there to bring core into the sandbox.

B

C

um There were some effectively the the next iteration of stuff brought in some additional code where the um uh the linting was broken, so I had to fix that I think that was the one um and I had some bugs in my script for automatically adding tests. So that's what the current PR does.

D

C

Because yeah I want to try and push those through get as far as I can before I hit the the code blocks. That I know exist.

C

um I.E the visibility change I think is the first one I'm going to hit so I'll try and run that into a worker. It doesn't compile.

A

So so to conclude, I think uh never I think we still need uh some update to this event. Data PR yeah.

C

That's what I was just talking about what I plan to do? Hopefully, today, yeah.

A

I think uh if you could.

C

If you scroll down you, the I put it to do in here then. So, that's sort of I see.

C

So I think that's the appropriate place, but us um once I get back to it. So when I added the other comment earlier to the other, PR I came and added this one. So the people do quickly, they sort of see um but I think that's the place, but I want to go through it properly first, and it may be some even more words than what I've just got there.

A

Yeah, we'll also need some more rewording on on these two um yeah, like I. Think, instead of calling data should we explicitly call it as the payload event payload data, for example, yeah.

C

I, don't want the name getting too long. um I think payload is instead of event data. It's probably.

A

No, no, no event, payload data or you don't need a you know, event prefix here you know you just say: payload data.

C

So we have event name I, think domain payload data.

A

Yeah, no, the attribute name is still event. Data.

C

A

Just this parameter uh a method, function parameter.

C

Bucket for the API gotcha yeah, sorry obvious, still thinking of event, yep okay, this is where I said: I need to go, read.

A

This yeah, because Jack's concern is that you know: when should people put uh attributes uh you know in in each of these arguments in.

E

A

Should it be in the second parameter of this third parameter, I think we'll need to give some guidance yeah.

C

um And that's what I thought it was down the bottom when I was through it earlier today,.

A

Yeah yeah I think uh whatever you put here, I think make the corresponding uh wording changes here. Yeah one is in the second one is in the API yeah.

E

C

Get back to that today, uh I do have to do a release.

C

um Hopefully nothing goes wrong, especially with Carly being out. So you can't like back me up on that. I do have another big block of meetings again today. It's me on my life recently.

A

So uh Martin um this logs API sdkpr um in roughly in your mind, there are no blockers right, I. Think.

B

um I think it looks overall pretty good. It's just um just like looking at the details like I um yeah I want to make sure that, like things are covered with tests and stuff, like that, um the one question that I, that's kind of in my mind- or maybe you might have opinions- uh is that they, they implemented a log record to be kind of like a span where, like most of the functionality, is in the log record class, um whereas like it could be in the logger instead like um so I.

B

This is the detail like logger is passing like a processor to the log record, and the log record has an emit function on its own and pass things to the processor. So, like just you know, I think I think those are maybe implementation details some of it, but I I do want to kind of walk, walk through the details, myself so um but I mean overall I. Think everything is in there. Okay,.

A

Is is there a like? How is uh the the north side uh back-end folks, uh you know expecting to use this like? Are there uh like it's not as a upender right in he's up under a Java, only concept, or even let's say the logs generated by a by a node back end uh service when when they generate logs, you know what is the way for someone to ship those logs to an Hotel backend?

A

Is it through uh like in in Java you you could you could hook into the you know the process uh and and and then redirect those logs to uh the otlp destination, whereas you know, in other cases where there is no concept of a Pender, you you let the logs go into the STD out um and then outside the process. You know you you capture them through files or through some other mechanism, and then you send them to the hotel destination.

A

So in in what which of those two approaches would people here would be using, and indeed in on the JavaScript community.

B

It's a good question, I think um I think if I had to guess like the second. Usually people do the second, when it's just Council logs with a standard out and then it's scraped if they wanna.

A

In that case, you know this whole API is is not even.

B

Used but I mean, if you do that, then you don't get the correlation with um this span context right, so so yeah you might want to. You might want to do that. I mean so like there. There are. There are libraries like Winston, for example,.

E

B

Like you know, I think you can create. You can extend that with like a similar content as an appender.

D

um Yeah I was gonna, say any serious, app, probably use a library for logging, that's dedicated for it. Then then you can have an Hotel transporter. Yeah.

A

Okay, so so then you're saying that there will be an upender like mechanism to.

D

There'll be a library of which build stuff onto yeah.

C

Okay, yeah I think from Microsoft side, uh Hector and Jackson, uh mainly leading managed stuff, I'm, pretty sure in the Azure environment they're playing with that there is a logging API for logging definition. There I'm pretty sure they're, not just scraping standard outstanding error.

D

Chaotic yeah exactly.

A

Yeah I mean once it's outside the process, then you know you don't need to use uh JavaScript right. You know there are. There are common Solutions to you know, take those logs yeah.

C

Just redirect them to a file and just have something read them.

A

Yeah and uh like Martin's Point that there's no correlation uh once the logs are out the door yeah, uh so Martin you might want to you, know socialize this in the JS uh Sig.

A

You know because, outside of our use case, the event use case, um you know, depending on how people want to use it, you know they might have uh and they might be the ones to test this further.

B

A

So once this is in place, uh I I I think uh before we get to the events. I think you might want to. You will need to do two changes right, you'll need to build the exporter and then you'll also need to add the support for the map attribute value the value to be of type map. Only after those two changes, you know you uh you bring in events.

C

We could hack it but yeah so I, ideally um tigrants PR gets merged first and then we just make attributes the attributes which I think you can. He has enough sign off. He wasn't in the spec meeting this morning, so he's probably out this week um but yeah once that goes in then we're we're set to say: okay, as of hopefully 1.19 attributes can be nested everywhere.

A

Yeah I thought that if we are I I don't see yet approval from the trace approvers. There are approval from.

A

I think uh other uh signals, but there was also a comment uh earlier this morning that you know it may not suit metrics, so I I don't know if people have thought about it before.

C

Yeah yeah wants to make sure it's publicly socialize for us, because this issue has been going on for a long time. It goes back to um my PR. I think started this path, but my PR was just extending was it 324 is a three digit one yeah.

C

So yeah this is this has been bubbling for a long time. So will it keep bubbling yeah it's a possibility too, um but I think this is the most approvals anything like this has ever got before.

C

I think we're we've almost sold um uh a majority of people.

E

A

Yeah and and that's why you know there is, uh although it's going in the right direction, you know it's, it's just a matter of you know, timing right, you know it might still get delayed and and that's why I'm thinking that uh when we I think it'll be good to introduce that log, uh you know the industrial attributes for just for logs yeah for our purpose, for our for the purpose of events, yeah.

C

So there is a span attribute, which is now just an alias for attributes. So we can follow the same thing inside that we have log attributes which is effectively attribute, plus nesting, um and then we just use log attributes everywhere in the logging, um API definitions and then, if at some point it goes away like spandex, which did then log attributes becomes an alias for attributes again right.

A

A

Okay, all right, it's 10 o'clock, cool! All right, uh see you all tomorrow, thanks everyone yeah.

C

A

C