Open Telemetry Uncategorized, 20 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-10-20 meeting

Description

Instrumentation: Messaging

A

B

A

I'm good, how are you.

B

Okay, nice, to see you where have you been.

A

There was holidays in Israel.

A

Yeah but it's finished.

A

B

Do you feel rested.

A

Yeah yeah visit the family I have been to a music festival.

B

A

What did you talk about the last two weeks.

B

We mostly discovered the process uh right how we are going to move forward. um Shall we have some different approaches right there. We change the current spec. What's the small steps and we break it all together, I think uh what they are.

B

The top was is that where would first break the cards back I updated the pull requests for attributes, so it covers basically all attributes we wanted to add, and we assume that most of the breaking changes would be in this priority and then we kind of can move incrementally or maybe we will reconsider uh once we merge this one, we will propose to to see how we are going to move forward either by creating an extra document and then merging it into the stack or if we just naturally evolve the the current one.

B

So I think we are mostly over with the process. Discussions and today, I think we're going to review the the new attributes in the PR to strike.

B

Okay and it's it's like the PRS, it doesn't talk about the uh stunt structure, right links or events, uh and things like that.

C

B

Praise everyone I, don't know.

C

Hi R sorry I'm I'm.

D

A bit late, I guess we can get started right away.

C

Sounds good I will share my screen with the.

D

Agenda so please add your.

C

C

D

Social cannot make it today, he's pretty swamp, so I will I put some things on the agenda, starting with yeah this first big PR here this old depth, 192.

D

uh based on our discussions last week, I killed this one with a reference to uh two other work items that are going to replace it.

C

So if you go yeah, you see there's a lot of discussion going on in this one.

D

Yeah I closed this yesterday, because you have uh part of this is already merged in this context: propagation PR. So that can be quite done. Another part is captured in the proposed changes for trace and span structure. That's the Otep and there's also part other PR that covers uh the proposed attribute changes. That's this PR.

D

So, based on this yeah I closed this, uh the big br, so I think we have been asked like for everything that relates to stand structure. We continue working on this PR and everything that relates to attributes. We might continue working on this, but we can discuss details about that later in next points, so that that was this and then last time we they're talking quite a bit about like the strategy. How do we continue with pushing changes to the stack?

D

We came up with this.

D

Basically, three possibilities uh of pushing changes to the spec that The Idler will be just evolved, existing semantic conventions with introducing multiple breaking changes or we introduce V2 in parallel, so it won't break existing ones, but there will be a parallel one. That eventually replaces we want orbital with a hybrid solution where we have a one-time, braking changes for single, measured scenarios and then the battery scenarios between more complicated. We basically evolve that over time without breaking the singing method scenarios.

D

So we said Okay I, I, said: I will write a short document describing those two and then we will present them to the TC and get the direction of how to best proceed.

D

However, when writing that uh up, I made a short write-up, but while writing that I thought that before we go to the DC and bring this there and ask them for direction, I think it would definitely be good for us if we would have some change with some concrete changes that we're already ready to push to the spec Repository, because if you, if you go to your trust with this question, how should we do it and we don't have any kind of car yet or any changes yet to be, as a group agree on I think we are in quite a big position to uh to push things through.

D

That will probably get low priority and we will not have kind of much leverage to to get the decision. There is when we already have, let's say a draft PR or whatever, with some changes that we agree on and that we are ready to push to the spec I think we are much more likely to get some some movement here and some answers to these questions.

D

So that's why here in the strategy, I kind of I I put this first, that we first agree on this draft PR for attribute changes that look Middle star uh put up. So we put in a Auto attribute changes, at least for the single message scenario in this PR, and we as a group, agree on that go through the discussions and then once we are ready basic once this will be ready for a real PR or for merge.

D

Then we go to the TC with this PR these changes and also these three possibilities, and then we get some direction from them of how to best proceed here, but that that would be the idea of how we go about. We first get work on the attributes. Pr, we do our kind of uh few technical religions there we discussed it comes an agreement and then once we are there, we go to the DC and get for the directions of how how to proceed with what we have and then is.

D

The next point I mean I can add it here. Then we then we.

D

Then we continue discussing the span structure, changes, but I think it makes sense to to start out with the attribute changes, because those are I think we are closer to uh to getting something. That's ready to be merged on this side.

D

Okay, so just wondering does this make sense to your? Are you? Are you fine with that? With that outline.

C

A

C

Sounds good okay,.

D

Then uh I think let's go to good middles PR the attribute PR. There are several open discussion points there and uh what I thought is? Maybe we just go just start out going through this open discussion points and see which discussion items are still uh relevant and need to be considered or probably should discuss discussion items we already written agreements. Maybe let's start from the from the.

C

B

And just to let you know, uh I updated this PR yesterday to reflect all the attributes who have been attacked. So there should be more reasons for people to comment now.

D

Okay, then, let's, let's look over this first, let's look at the changes first that we get an idea and then let's look over to open. uh Let's recover old, open comments, awesome.

B

Yeah- and we kind of can get a summary from uh the changelog record.

B

So like this is all the remainings and they're, not it's not the fair list, because we also, for example, the destination kind. It now can be represented by the destination crying for a source kind, but I kind of skipped it here.

B

So the this is the list of ratings, and then we also introduced to namespaces right the destination and source and message and that's it.

C

Okay, thanks Luke Miller. That sounds.

B

And this file is a schema like collector has a component. So if you run collector, you can add a component that will do this transformation for you uh and this file goes into collector and it uses it to apply transformations.

D

Yes, so here basically, we have all attributes that are not really new, but they changed for messaging, yes from existing names, but we always also have a new ones added that don't drop in this list. Okay, so yeah. We have Source name here, which is name.

B

D

And I think when we go to the.

D

Table here we might see here.

B

Yeah so I switched it so we have a common table and then we have a producer, specific table and consumer specific table.

C

D

C

D

Didn't we are messaging attributes and then we also have producer attributes and we have consumer attributes.

C

Yes, let's see.

B

One thing: I didn't: do I, didn't move messaging Corporation to Common attributes, because I think we can do it at any moment. It's not breaking at all and I didn't promote messaging, the URL, uh but messaging people I. It might be a worse discussion. People.

D

Yes, an entrance to clarify messaging operation. Why didn't you move it to Common attributes? Is there a.

B

Because Nothing Stops us from doing anything moment, I I can move it. It's just. It increases the size of the sphere, but, let's feel genuine I mean making introducing messaging corporations with published threads. It's an additive change and there is no urgency in doing this.

C

D

Always see because in the current spec we don't have, the messaging operation is only on consumer.

B

Right, yes, and.

D

C

D

D

But like at your point that if you would want to move it at some point, it would not be.

C

A breaking change from spec point of view, yeah.

B

Oh, it's recommended this. This one is clicks the operation.

D

I mean I I think it might be when we move it later. It might be a breaking change for because it might break uh uh I mean because it's not required it's just recommended, but in that sense it might kind of require changes in instrumentations, I.

B

Think the document just shared on the Telemetry I think it explicitly mentions that the stability is considered for consumers, not their producers.

C

B

But I might be wrong, but yeah it's a good qualification amen, doesn't matter.

D

For consumers, that means photo back ends.

B

C

D

Okay thanks a lot Luke, Miller I think that already gives us more uh more food for review and I. Think we truly have now, as mentioned you can see in the other PR I think we have uh all the changes from this PR that are closed. Now in this. In this new draft PR in the spec, which is great, we can, uh we can continue working and discussing here.

D

No thank you and the about I then wanted to do for today's just go over uh discussions in uh in this PR that we just looked at the attributes PR, because some items are pretty old and I I actually sometimes are even like still from the summer.

D

Some some comments here and trust you wanted to see which, which one of those are still uh relevant and which ones we can close I mean I I already did some uh kind of beat up. Last week there were some suggestions that were just containing spellings I merged for those, but there were some that uh yeah I was not sure, so maybe we can go through those and I'm also, maybe then we can also carry five. Each of those are already kind of obsolete, uh based changes that you did look Miller mm-hmm.

C

B

D

Yeah, let's go ahead.

B

And it's just I wanted to ask you if you want to um take over, do you want to show, or do you want to scroll through that comments, or do you want me to keep me to take over and just.

D

uh If you could recover that'd be great okay,.

C

D

I think you have a better handle on the overall prmp yeah. We will be faster.

C

C

B

So yeah uh this is the discussion with Amir.

B

Message attribute some links.

C

D

That was the discussions from the last week. I guess yeah, where to put the attributes I think is this about the message, specific attributes and where to put them.

B

It's even better: it's it's! Okay, to create the link on single message, operations right and you were able to put all the consistent behavior of this batch. The non-batched operations I feel it's a good discussion to have.

D

I see so this is the colleague not really structure related to attributes, but it's I mean it's related to attributes as to where to put them, but I think it's actually automated span structure because it's about they are putting a link on all the using links for all the operations, even single message operations, if I understand correctly.

A

So so, I'm not sure if it's like a mandatory like if we want to say You, must use Link but um I think it should be optional like if somebody wants to be consistent, then for a single message case. It's like I want to suggest that everything is valid. Like you can just have a span with no link.

A

You can have a span with a link and have the attributes on the span or spend with a link and have database on the link, yeah and I think the specs with the state that all of these permutations are allowed.

B

I think the stock should give preference and say that you either should recommended the the one way is recommended and um the reason for it is.

B

I mean it's it's very hard to implement this spec. That doesn't give you guidance right, and there are probably other things that depend on it. So if we can not force people but put them into the the right way it it's just easier for for everyone and, for example, if we don't sorry I'm, sorry, uh just a second, if you don't give this guidance, then people, for example, they will start creating links all the time and putting attributes on links all the time, but no back-end supports it today.

B

Maybe yours, maybe you're the head of the world under but you're the only one- and this is this- will create a lot of friction and users will be not happy about it.

A

So I think uh for libraries like um rabbit where there's no batching, there's only always a single message. I think it will be most convenient to have uh like a span with the like, with no link and then have all the attributes on this spam right, but but for packages that support both batch and non-batch.

A

So it might be make more sense to to have one behavior for those two operations, so they they have the same structure and template like um and and I don't want to like uh comment or force implementals on how to do it. I think they have to make like a common sense and and and each use case will have a different considerations.

A

um I think we should uh state that they both are allowed I'm, not sure what guidelines to give to which one is better.

B

I think what happens you believe that people who are instrument libraries know what they're doing they don't.

B

I can give you a few examples and even myself, I I, don't always know what I'm doing, because I created Telemetry, who is used by other people and who you who use it through visualizations created by the third group of people, and if we allow everything, then there's three groups of people don't know what happens at all.

A

Yeah like if, if I look at the back end, like I, think for the back end, the most convenient thing to do is to always use links and to always set the attributes on the links, because then you can implement the processing of these bands like once for all cases, and it will always work right so for for like seconds this is the most convenient option, I think for a visualization.

A

um It's it's more convenient to like not to have the link, if you, if you don't have to and don't have the attributes, though, and.

D

I mean I think there's several points to this discussion here. First to loot, Miller's point about what is best for the back end, this kind of relative, because there are some back-ends who don't or actually most back, can still support, attributes and links, and some backends, don't even support links, so I think other others would would disagree here with us what's best for the backends. But apart from that, I I in in substance definitely agree with uh with the proposal here from Amir, because also when we look at our Spanish structure power.

D

Maybe anyway last we we models require links for all scenarios. So there is no problem type relationship between usual consumers anymore anyway, in this proposal, but I I also want to hear how much we can keep this this apart, because here, basically in this PR, we want to focus on the attributes and in the other PR we're going to focus on the span structure and the test. I wonder how? How far can we keep those discussion?

D

Apart so I mean we're getting into the span structural discussions here, which actually would prefer to have on the other PR and just focusing on attributes here and I think your domain, the main source of discussion here, is you're there to put attributes either on the spam or on the link and I. Also think. Another point to consider here is when we see this. This sentence that I'm your quote quoted that for patch operations per message, attributes cannot be said on the current span and should that be said that on.

D

The link- maybe we can formulate this in a way that is, uh uh that that keeps things open enough for both scenarios and then they'll also stand in an Unbreaking way kind of to adapt our expense to kind of adapt to to merge our span structure, changes and adapt this so that it is a uh still consistent.

A

The spend structural PL that you're, referring to uh like do you imagine that we will have like a one big PR with all the changes at once.

A

That would it make sense like to create just the pl the change like this one thing, and then it's much easier to review and merge.

D

I I, don't thought about the real strategy to Mark to spend structure changes yet I think we we first ourselves have to agree on a consistent. That's everything very close. We are not there yet and once we agreed on a consistent set I think then we can. Then we can uh uh think about how to best merge that into the stack, but they don't have a real plan for the get, whether to do it, piecemeal or or as a whole.

A

Yes, so I think uh if I understand you correctly, uh this comment is not relevant in the scope of this particular BL right and we should edit in a future plate.

B

It's still relevant go ahead.

D

So I also think it's relevant, but I think we will try to. Maybe we should be fine not coming to a like really. This will be fine if we don't come to the final solution yet in this PR, but we that we should do it in a way that we're open to kind of then nail this down. Then we really do auto span, structure, changes.

B

Okay yeah, so basically the the feedback to this PR is to make sure it does not prescribe the way just yet right and it's kind of fine, because this this document currently it does not even prescribe using links. It says the attributes may be populated on links. So it's like the correct. There is another open discussion, whether we use attributes or links. So this one should go first before we actually say that we should put something on links: okay, so I'll take a note of that. Maybe I can just write it down so.

D

Because I don't know, don't do something: I mean you. Basically you suggest that they are I. Think in one of your descendants, you know, commands you just say: okay, let's also allow to use links on single message scenarios and have the attributes on this link comes on this link consistently through all scenarios and I think that that would actually require us to change.

D

Also, the examples here and the span structures in the example or to add another example like for single message scenario that has a link and I think those are things you would like to avoid at this current point, because it will just make the whole span structure hinted that it examples more confusing and we should I think it would prefer doing it in a later PR that focuses on span structure.

E

Yeah I think it might be a good idea to sort of just in this PR say Define, which attributes are per message and which are per send and receive operation um and leave it at that and and not say here, where those attributes go and then maybe that's part of the span structure operation. Maybe the span structure is, is a second period and a third one says where the per message attributes go. Now that we've defined stand structure and where the per operation can receive attributes go um so yeah because I just think.

E

If we kind of break it up that way, it'll be easier to to keep Focus discussions. I, don't know what you guys think.

B

A

I want to add, like a tour questions here, one if we want to uh to say that um we must always use links if, if it's like a parent-child relationship- um and the second question is where to put attributes. These are two different questions, so we can have like uh all the follow-up permutations. Okay, like a we need to agree on those two things.

B

uh If to create links right.

A

B

Then, where to put attributes.

A

Yeah and and I would promote uh like to always use links, because there are many places where links make sense and like when you were doing uh like a delete. We, you might always also want to use links so I think if we just consistently always use links everywhere, it make everything much more simpler, because uh I wrote the logic for um a specto backend, where I have to like a branch like too many branches like if it's uh like all to the parent check.

A

If it's a sand, if it's a sand, then you know the message from the parent, but if not then check if there's a link and like it gets very complicated and if there's always links, then everything becomes so simple and consistent.

B

I have some objections here, but that, let's discuss it once the time comes.

D

Okay, yes and and another state one last question here based on this to these two questions here so do we do we agree to postpone both of them and clarify them along with span structure or or do we still like, just basically postpone the first one, whether to create links or not in certain scenarios? But we still uh answer the second one in this PR where we say where to put attributes I, don't links or messages, or do we basically postpone both.

A

I think postpone both okay.

C

A

Yeah and I would be very happy to have a PR just for that, like not to mix it with the spend structure just to have a PL that says how to use links without going into all the details of of all the way that it can be complicated.

B

I agree, and also this will help us with the discussion events versus links and links with empty contexts. They referred to.

C

It sounds good.

B

Okay, so moving on to the next item.

D

B

Yeah I think this is the same concern right if to create links.

D

C

Guess I think it's also.

D

D

Then structure to a certain extent but I think it I think the main question that this touch here is here: if we put the attributes on links- and there is no like context or not link for you to create what do you do.

B

A

We can discuss it in the links.

B

B

Yeah- and this is where I I I, we became very unprescriptive about links and say they may happen.

B

So I think I already summarized what we just discussed here, so that this this is probably out of scope of this here.

B

So can I resolve this one or um you want to go through it again and and check if, if it covers the current State of Affairs covers your concern for now.

D

I mean what what I would do. I will create a link to this discussion uh yeah. Ironically, a link on the on the span structure, PR because I think that's the case. We have not uh this character. Yet what do you do when links? Basically, you cannot create links. So then we have the basically the discussion link there and I. Think from my point of view, you can close it here, but maybe I'm here yeah needs to decide because he started it here.

C

A

I support the talking about the attribute names in this PR and they've. Looked at the follow-up yeah that discusses all the issues with links.

B

B

Yeah, so there is some questions from Dwayne and they think okay, so there there is this weird situation. I can show you that, since our uh spec is in the ammo right, then um there is a choice: I can either be strict or I can make it easier to read my preference on being strict and specifying, for example, there is the requirement level right and essentially requirement levels are very similar or different attributes and carbon tooling does not. Let me tell okay, there is one not for all of them right.

B

So what happens as a result that I have some ugly.

E

If it's a tooling issue, I I didn't realize that that was what was generated. That's fine, okay,.

B

Okay, so let's resolve it for now and we can come back to the Cosmetic changes at any moment, yeah perfect. Thank you.

A

This tool is something that uh open Telemetry about, or is it uh like.

B

Yeah, it's the this, this Ripple and it's super easy to change. It they've done multiple PRS to it, so we uh I, actually I, was going to add a few more changes to this total support messaging like supporting links and a few other improvements right. So we we should be it's. It's super easy to change.

C

B

B

um So, what's next I think I need to revisit uh comments from Joe, because I didn't pull my changes from this Branch I didn't know the harness that he merged, something I will go through them and I will make sure they lend it uh there.

D

There, oh I, see so I just merged some, like spelling some spelling corrections to draw kind of uh uh proposed here just to reduce the number of commands, because they were like a a lot.

B

Okay, yeah I'll go through them again and I'll make sure they're ended up in the branch.

C

B

So I think what I'm trying to say here that if a specific system like Kafka right wants to extend this, this is where they should put their extension name uh It's, actually an interesting point because for Destination I think we agree that should be messaging. The destination system message: okay,.

B

So uh they see what I mean.

D

When I think false comment here, it's just about uh I think it will be fine. When you just said note that attributes in the messaging.message namespace describe an individual message, I think that would that's already. What is what he's proposing so I think he's just uh uh what he just asked for is to make it clear that this is just about the stinky individual message. Okay,.

B

Okay, cool I'll take care of it and.

D

And the point that you that you brought up Luke Miller that was basically better. uh uh This message, the system specific one basically have their own namespace and are not in the messaging.message phone.

B

Yeah, but also there is a choice rate. There could be this one all right.

D

B

C

Could be this one? Yes,.

A

B

A

Think it's border than this right, because database uh attribute names also have this pattern, and we might also need system attributes which are not uh for a single message and we we need to agree like on a pattern on how to extend the specification for a specific system.

A

But and then after we agree on it, we can. uh There can be many many use cases not specifically this one.

B

Yeah and I think for remember: we had a discussion on the destination name, so maybe we can quickly have it now and then uh it will resolve for all of the namespaces, so I think for the destination name uh or something like that. We thought that maybe there is something system specific and then how would backend approach? Looking for all the attributes that are specific to destination, right and I think starts with is an easier pattern matching than uh Records like this.

A

Well, can you repeat it, though, what do you mean.

B

So remember you mentioned that, for example, you need to find the back end needs to find all the attributes that describe destination right. So we have the choice: okay, for, for example, uh the in the first case.

B

In order to do this, you would need to go through all the attributes right and find those that match this pattern me and for the second one you only need to do the storage space.

A

What, if those like, um like a system attribute that is not a destination like uh something else, I, don't know messaging dot, Kafka Dot then like, then we will have like a messaging dot, destination.kafka dot.

A

B

I mean if there is an attribute, that's not specific, to destination right, then it just uh goes to the random global data. So when you would not show it was specific to destination right, it would show it as just random blah.

B

Do you see what it means.

A

Can you uh show me in a like a concrete example, please.

B

Okay, so let's take a look at the current.

C

B

Example, Reddit.

B

um I, don't know the flying pages right, it does not describe and it can describe destination but anyway, let's just assume it does so it does not describe destination and the back end doesn't need to show it as something that specifies destination when you, for example, when you click on the Strand, it will show it in the list of attributes, but it won't be used if there is some experience that specific to destination.

A

So what we're talking about Defenders stand correctly? Is it? Do we want to take everything to begin with messaging dot, Kafka dot, something this is option one or like the other option is that we have like messaging.destination, dot Kafka, something and for other attributes we will have like messaging.

A

B

So yeah, if there is an extra namespace like message, destination or Source, the system should go as a certain things or if it should go as a second namespace. So if there is no certain space right, uh sorry something for the client ID, then it's just this.

B

Is basically the order of namespaces.

D

Yeah I mean I I, have a slight preference here and I mean when trying to like think how to formulate this I actually came up on some other thing that we might think about the codifying here in the attribute conventions under my preference, is to have like a system like uh the messaging system name closer to the top level, so I would prefer message, dot, kafka.destination to message.dusting destination.kafka, and why I would prefer that because I think it's just uh from the how to save and just looking at the attributes from the from the point of view of like the cognitive overload that you get I, think it's just easier to have all the messaging system, specific attributes under one namespace group better.

D

C

D

I think that makes it easier to kind of consume them. That also makes it easier to ignore them if you are kind of uh a backend that does not know about the particular name spaces and to the to the that. That is a very relative kind of thing, so I I I think there are other points to that and other other pros and cons.

D

But to your point of parsing, this that's an interesting point and actually Wonder for this system string that we have here uh whether we should require to be that to be the same as the value of the messaging.system attribute that we have is is required for us, so we always require this to be present and I mean, for example. If this is Kafka, then we could.

D

Then we don't need to direct expressing you just say for destinations, looking to messaging dot, uh message destination and look into messaging dot, Kafka, because you know the string, Dot message so yeah. This should be something that we require in the conventions yeah.

B

Great point, so let me write it down.

A

I I think it's not a messaging question. It's like I.

D

Think it was, the logic is the same in database yeah there you have DB system, which is uh required and in database. Actually they have a list of of these of possible values and they map also to the attribute sub name spaces.

A

So so, for example like uh for mongodb, we have like a db.mongo DOT, something guy. Yes,.

D

And also for mongodb, it's basically db.mongodb dot, something and also.dp system. The value is mongodb. So this value of DB system matches the name of the of the specific namespace.

A

So I think it should be expect like in general, right not for messaging, like somewhere in the specification which they how to extend an attribute name for a specific system that that applies to all the categories. Right, yeah.

B

If we don't do this, nobody will.

D

I mean it, it I think it applies to all the conventions where you have this basically system attribute and the namespace I think it's it's messaging its databases, so I'm not sure. Where else that we.

A

What is the name of the first part like the messaging or the DB or HTTP like how? How does it call? How is it called.

B

It's connecting right, it's just somebody comes up with the name, you mean the first part, the messaging colon.

A

Yeah, like is it like a phrase to to whistle to it the category I don't know something. It's.

B

A namespace right, okay,.

A

Do you participate in the instrumentation I see you know if they talk about it in that base context.

B

So there is now database group there used to be a Tuesday meeting uh about HTTP, but I don't think it happens. Anymore I actually use the same document now. So we can see that there is no HTTP meeting at the name.

A

So so it's okay! If we can suggest to do it for database as well right, it's not like they're talking about something else that we need to coordinate.

B

Yeah- and there is no database working group at least yeah and I- think that the databases they don't have more than one namespace so far, and we are the Pioneers here.

D

I mean I think database that they already I think uh implicitly do it. They have DB system and, for example, one possible value is Cassandra, and then they have db.cassandra for Cassandra certificate review through db.mssql for uh Ms, SQL, specific attributes, so I think they already do it and also in RPC like in the RPC semantic conventions. It's also kind of done to some extent or whether you have RPC system, and then there is RPC I, don't know.json RPC.

A

Yes, for dbsc, there's like a db.mongodb.collection and db.reddits.database index. Yes, so the logic will be like the first part is we call it namespace and then, like namespace dot system equals something, and then we have like namespace dot this something and then it's a like a silo for a system-specific attributes, I I hope I was clear. Did you understand yeah.

D

And basically, this is the name of the system. Namespace should uh should equal the like DB system or messaging system or RPC system.

A

Yeah so so the logic is like uh well defined, so backends can process this uh attributes consistently right. Yes,.

D

Because then, as a backhand you're, just looking to let's say a DP system, and then you know that's mongodb, then you know: okay, now I have to look at to the db.mongodb namespace and I. Don't need look for other I, don't know MSS, Creator or MySQL namespaces, and then you can do without like some black acts, uh some reg X parsing, but you can also always use what we just said. That starts with logic, which is cheaper.

A

Yeah, that sounds a very good to me.

B

So there is this document that describes attribute naming and we can basically add the guidance there that uh if you use system specific attributes, then first name space, then system name, then the system name should always match the the extension right. So we can try to extend this document to cover this for all systems.

A

The first about the the namespace: it's like it does, is it a good name to call it namespace.

C

Do you think so.

B

I think so so, for example, here the there is a hotel name, space right yeah. So you see that attributes that uh the first name, the first part I'll tell here they call it namespace.

A

So yeah, so it will be for DBL, PC and messaging right and and possibly other things in the future. But this is what the currently will be uh affected by this yeah.

B

D

First, videos for now: yes,.

B

Maybe there is also a fast uh Lambda spec which might be affected I'm, not sure, and oh there is also practice anyway. So, let's see, um maybe we start with this back and I'll check how how far we can go in in standardization, yeah.

A

And then this sentence in in our PR is no longer needed right because it's uh described globally in.

C

B

Oh, that's a good point. Yeah I suggest that we do this in the sphere right once it gets merged. We can go to the generals back uh to create the same guidance for everyone, and then we can come back and remove the sentence because it's redundant this way we can. We are not blocked on this General discussion and like okay process people, don't like that process. That Windows is now the the requirement or something.

A

Yeah, but then again that needs to extract all the um a single message attributes it will look for either a messaging Dot message: dot, something or messaging dot. uh The name of the system, Dot message on something right, this the the union of the both of them would give all the the message under this.

B

Yes, uh maybe the one you need to pick here is that the messaging.message attributes are, to some extent fixed. It's a clause said described by the the specification and probably backhands will not be so strict about it.

A

What do you mean I.

C

A

B

I mean it's not like when you, when the back end searches for messaging, that message, the generic attributes comment for everyone right, it's probably a close set of attributes, at least for now, uh and maybe searching for everything that starts with messaging. That message is not the fully uh correct case, but I can easily see that for future proofness backends would ignore that it's a close set.

B

Does it make sense.

A

Why is it important that it's a closed set.

B

I mean if there is I, don't know some fault instrumentation that populates some low quality data you might want to protect your visualizations from it or I, don't know, but it's it's I think it's not important discussion to have.

A

B

Okay, so I'm posting this, so the action items here for me is uh first three and the fourth one is is like the the future right.

D

I agree to shoot my block this PR. That's something that we kind of yeah would like to see is consistent across.

D

Different semantic conventions.

D

Okay, but I think for from the thing, as you said, we can trust this first sentence that messaging, that or the second bonded system should exactly match messaging.system, that they can start encoding into the messaging semantic conventions and then, as the next step, it might be here might be a next step to kind of uh make this uh consistent across this requirement, consistent across them and the conventions.

E

I wonder if um there's ever would ever be a reason to not follow that, like, for example, uh if someone's using a JMS API or like with an as with it amqp as a provider, maybe at some place some point in your um Trace. You've got okay, my messaging system is amkp, but am but the tracing logic knows that certain attributes on the message are JMS attributes.

E

I wonder: would it ever make sense that you know you say messaging.jms where it's a JMS specific attribute in the ampp message and messaging dot amqp, where it's purely an ampp detail, or do you kind of say at that point? No, you always have to use messaging.mqp. Even if it's like a JMS specific attribute.

B

Oh, that's a great question and in our case we have like a generic ampp uh attributes and we also have event Hub and service bus, specific attributes.

E

Yeah because it like for MTP, they do have a JMS bindmap specification for how to implement JMS on amtp, and it describes precisely how JMS Concepts end up in a few messages and so down in the MPP layer. It's reasonable that it would know which things are our JMS attributes.

B

Let's see so we are we, we have messaging obstructions and we potentially have a mixture of abstraction, specific attributes and messaging system. Specific attributes.

A

Yeah I said I'm. Sorry, I have to talk. I have the other thing to attend. um I'll catch.

D

Up then we're over time, and maybe we can then continue next week with those discussions uh we can. We can. We can add it here still as an open point that we, this mqp HMS kind of mixture in Spain, because I think there's certain issues here to discuss that or some heightened leading to spend structure again, because the question is yeah, should you then have different spans for those or do you have then just one span for modeling, both the mqb and the 3ms operation, which are kind of uh technically the same.

A

D

We will continue next week, yeah because we're over time.

E

Just one more concrete example of this: if you talk about mess, just maybe we can note for um discussion next week is that message: ID could mean something at the amqp level and there's a JMS message ID. So you have multiple message: IDs and um yeah it'd be good to know kind of at every point along the way. It could be good to know about all like all message, IDs and and just clarify what we mean when we say message ID, um which one it we're talking about, but yeah I agree. We can.

E

We have to stop for today, but that's just one example of where I can see. This is um we'd want to clarify what you mean and what we want.

A

What will we write in messaging.system in this case, like JMS or mqp,.

D

But thanks thanks everybody thanks Lut Miller for updating your PR and walking us through it and please, uh uh if possible, take some time and review. This PR add your comments and then we can continue. Offline discussions, add questions and maybe then yeah we or we will continue next week with open items. Okay, so.

C

Thanks everybody also thanks.