Open Telemetry Uncategorized, 26 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-07-26 meeting

Description

Instrumentation: Messaging

A

Hey martin.

B

Hi santosh, how are you.

B

Can you can you hear me.

B

Yeah I can, I can hear you can hear me.

A

Hi martin, can you hear me.

B

Yes, I can, I can hear you uh you, can you can't one.

B

Santosh can, can you hear me or no.

A

B

Hello, you can hear me now. No something is, can you can hear me now.

A

Okay, I'll join from the phone.

B

About now or what now can you hear me now.

A

Yeah, I can finally hear you okay, good good.

A

Okay, welcome back.

B

Yeah thanks: how are you.

A

Good good good! How are you.

B

Good, um it was a good vacation, nice.

A

So um not much to talk, but tomorrow um I think purvi from honeycomb. um She is going to discuss a few things. um I asked her when she was basically asking how she can help.

B

A

And uh last week I pointed her to our project board and I also told her that uh you know each of us. You know we are already working on one or two things and uh I'd like to understand what their concerns are from anikum.

B

A

And she sent me a few things and you know um they are about the same ones that you talk about, so I asked her to take up and drive one or two of them so we'll go over it tomorrow, but I had uh I'll send you her list. Actually let me send you right now.

B

Is she is she mostly browser, focused or also mobile? No.

A

I think browser focused only which is fine. I think, let's get browsers, uh you know browser stuff more, you know forward mobile will follow later, and so my question is um so today uh you know all our browser instrumentation, the browser spans are sent in json form right and the json form is not officially, uh you know stable. Yet it's it's an experimental status. The otp json.

B

A

And um and and currently there is no uh in library in a package to send the data in the protocol form right, that's something that said, that's an ask, but it's uh nobody has added it yet.

B

A

B

I think I think well, there is there is, but it I don't think it works in the browser.

A

Yeah yeah yeah. I think it's probably there for the back end and we need to make it work. So could you uh add a ticket for it uh when you get a chance? Because if it's on the project board, then I can add a label, I mean we can add a label saying help wanted.

B

Okay, yeah yeah.

A

And uh and then we could ask, uh you know, take a look so the way I I um I think I told her only half part yesterday, but maybe not tomorrow. When we discuss, I think we will have to either get the json specs table so that our browser agent can send json or we should uh get the browser agent to send protobuf because that's already stable.

B

A

Not talking about uh which is more performant, you know performance aside, uh if we were to, um you know, get some stable implementation of uh you know a javascript agent. I think it would be um at this point. It would be the protobuf based uh exporter and that doesn't exist today. So maybe we should get that working.

B

Okay, yeah yeah.

B

Okay, uh I saw that yeah. I saw that the um the pr for the short codes was was closed. The the short codes yeah.

A

B

A

B

A

um In fact uh said that you know they recommend using protobuf.js binary protobuf, which we are not using today and and again it's coming back to the same thing, so they are asking us to use protobuf and not json.

B

A

So I wonder who actually asked for json in the first place like? Why is this and why does it exist?.

B

Well, yeah, I think I think uh historically I mean json is like the you know like the protocol is using browsers right. I think so. The.

A

B

Was the main main use case, and um I think you know there was probably a concern about overhead. You know like the how much the the protobuf package would add to the package. The bundle- um and I mean you know nev- probably has more opinions about this like he, um but we should. Probably we should probably take a look. You know how much, how much bigger that the package is going to be with the protobuf and how much cpu it's going to take to encode.

B

B

Okay, yeah I but yeah, I I don't. I don't know, I think that's probably the only option that we have right now. Okay- and I think I think you know- I think the json is still an option you know like. If maybe, if there's a big difference between performance, then you know the end users can choose between having a bigger package, but smaller data data coming out or or json like smaller package and bigger um so that they have.

B

You know they have options um nonetheless, but nonetheless I think you know obviously the json we probably can't we can probably probably do much to uh make it smaller at this point sounds like right: yeah, okay, so yeah. I also saw that you uh started uh that you opened uh pr for for the specs.

A

Yeah yeah the spec. uh Let's say it's essentially the same contents as before.

B

A

And I also looked at your pr uh that implements the api.

B

A

As per the spec- and uh I should say that I don't have a lot of uh you know comments on that- I I I I I don't- have full understanding of the uh the javascript, um the open telemetry.js.

B

A

Structure, so it's best if nev or somebody from the from the js sig you know, can reveal your pr.

B

So I was thinking I might. I might just open this as a draft pr in the js js sdk and just just get comments from like the wider js community.

A

Yeah yeah, I think it should do that and once that is ready, I think you know um we we're going to discuss. You know what are some events we could implement with that api yeah later.

B

Yeah so I do have. uh I also have the other pr in my own um for in my own uh pork for the uh or the some of the events spec, so the semantic conventions for a couple of events um have you had a chance to look at that? One.

A

I think I did- and um I am not sure um so so, basically the event name and even domain, I included in my pr itself, because you know it goes all together, um but in your pr you also included the uh attribute the 70 conversions for the.

B

A

The performance timing, uh you know entries.

B

A

And that I'm I'm not sure whether we really need it, because uh those are uh at run time. You know your browser gives you right like for example. Today you know there might be 10 entries and tomorrow browser might add 11th entry.

A

You know so you you just you trade through whatever the browser gives you and then you send them all right.

B

A

Don't need to you know: pre-define statically, you know those names.

B

Yes, I agree with that. I think the only thing was that we might want to specify uh whether it's only like numeric and string values that it's that are being sent uh because they're like some of these. Some of these objects have, like you know, nested objects on them.

B

Let me see, and and the other did I actually- I think I did not worry that way.

A

uh Can you excite again, I didn't follow what uh you mean.

B

B

I'm just looking at the pr just give me a second.

B

B

So you meant like the net, for example, navigation, one yeah. Okay, I did list them. Okay, yeah.

A

Yeah, so that is not required, because those are dynamic uh strings I mean the the system. The browser will give you you. uh Typically, you know you, you put them in the semantic conventions, those that you know you reference from your library and then you add value, attribute value. You know to that.

B

Yeah, so I I think I.

A

And- and I also want you to you know, take a look at one other. uh Let me give you that so.

B

So before we move on like, let me just say one more thing, I actually did did word it this way. I said like that this list uh is not exhaustive and it's only listed as an example and or- and I said all numeric and string values should be included.

A

A

Yeah yeah, that's what I'm saying so. Why do you even need to list them because you are not going to uh you are so? The way I understand is that you are going to ask the performance timing uh api from the browser it's going to give you a list of key value pairs.

B

Right right, right.

A

And then those you just pass on, you know here blindly you're not going to pick and choose a subset of them. Do you.

B

Yeah, no, so I just I just listed these for as an example like you know,.

A

No, but even if you list comprehensively, are you going to? Are you going to use that.

A

Like, for example, let's say you you list, uh you know 10 right because there are 10 and then tomorrow let's say the browsers, you know add you know an eleventh one sure you're going.

B

A

Restrict to these 10 or will you be getting.

B

A

B

No, I mean that's what I saw here. I mean. I said that this is not exhaustive, exhaustive rest.

A

Yeah yeah, I I would recommend to not. You know, put this in the semantic conventions at all.

B

A

Okay, I want to you know in this context. I want to give you one more ticket. Can you open this ticket? I mean this comment in this link. I gave you.

A

Let me know once it's open on your screen.

B

A

Okay, so uh you see that attributes you know json there um yeah. So I added uh like the same performance timing data that we have. um You know I was thinking of. If we had nested attributes support, then something like this would be ideal, and these are long integers and that's why they are each one is represented using two numbers in an array. So that's like just the integer representation, but it's it's basically a name and a long integer value.

A

So if we had a support like this, wouldn't that be simpler.

B

So why not? Why? Why have even why? Why even have it nested like this? Why not just have the the attributes directly under attributes.

B

And, do you mean.

A

I think I mean, um then you will have to prefix the each of these with something common right, because they're all related.

B

A

Just you know logical grouping.

B

Right so so I mean so by wouldn't that uh so you're specifying the inlet name. So you know you're getting like navigation timing and then all the attributes are related to the navigation timing right and you just plan them yeah and then so you don't. You need this timing. Data like parents.

A

No so uh go to the previous comment in our two comments about you know. Today we send them as individual events right and it's pretty long.

B

A

Right so I'm I'm suggesting that instead of individual, you know span events we spend, we send it as a span attribute. If the attribute can support a supporter or map value.

B

Okay, yeah! Yes! Yes! So yes, so the! um I definitely agree that there should be one event and each of those numeric values should be should be.

A

B

So, that's that's! How that's how that's how like this? That's how this is defines it right this. This proposed spec this. This proposed semantic convention, yeah.

A

You're, showing something.

B

Yeah I'm so I'm going back to my pr for the semantic conventions for navigation so, like I said so so for like there's gonna, be an event called navigation with domain browser and then then the um the attributes for that event are gonna. Come from that navigation timing, api, like you know, each of these things is a separate attribute so right so so yeah we would not. We would no longer do this thing like where we have where we have individual span. Events for each timing.

A

Okay, okay, so then you basically at a high level. You agree with uh you know this approach right that I yeah.

B

I'm suggesting.

A

B

Yes, yes, that that aligns with with this pr that I proposed okay, wonderful, okay,.

A

A

Okay, yeah, that's all I had.

B

Okay sounds good yeah. Me too. I don't have anything else um um so so tomorrow, we're gonna have, I think, more vital.

A

Yeah tomorrow, we'll have a wider focus yeah I was um um you know, thinking of inviting her to this tuesday meeting, but then I realized that not many people joined. So it's let's just stick to wednesdays yeah, okay,.

B

So I do have one thing that I'm and I'm probably gonna, bring it up tomorrow and that's that's. uh We have. We have a couple of uh mobile folks like stefan and I think now bryce he works on on mobile and we also have some customers neural customers who are willing to contribute to semantic conventions from mobile.

B

uh So, like I wonder, I'm wondering if it would make sense to um to have a separate working group for mobile, where they can just focus on talking about. uh You know, mobile related, related topics.

A

No, we have two meetings anyway right, I think let them join use. This then.

B

Tuesdays yeah, okay, yeah, I'm I'm I've like we. Originally. We created this just tuesday meetings to work on the old tab, yeah yeah and then now it's like you know, changed into something else, so yeah I just want to make. I just want to make it clear like if someone's interested like in certain topics like which meeting should they should they attend.

A

Yeah yeah yeah, I agree their confusion, yeah. I think I actually. Let's uh look at the list of topics. I think we could reserve 30 minutes for this 30 minutes. For that I don't think you know the topics I mean the topics are most likely going to be common right. If the browser folks will also be interested in hearing, uh you know those things because we usually talk about.

A

You know the sessions and it's usually the same thing. The concerns are similar, so I think it's still good to have one meeting.

B

A

Because for the javascript at this point it's it's less of a discussion and more of a actual prs, and now we have. We have gone to the next stage right. I think there are quite a few peers open new peers need to be. You know, worked upon um so there's more clarity so for for for the mobile, I think we it's it's.

A

Luckily now people are interested, so we, let's you know, spend like 15 20 minutes uh each uh wednesday.

B

Okay: okay, it sounds good.

A

Let's start suggest uh tuesdays, then, let's just hear you know what kind of topics they have and then we'll decide.

B

Okay sounds good yeah, we'll just do that.

A

Okay, all right I'll talk to you tomorrow, then yeah.

B

Talk to you tomorrow have a good day.