Open Telemetry Uncategorized, 5 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-01-05 meeting

Description

Instrumentation: Messaging

A

Hello hi everyone, foreign.

B

Hello, hello, I'm.

A

Fine I survived holidays. How about yourself.

B

I know: is it your first time here I.

C

C

Sorry, can you say that again.

B

How was the early days, what did you do.

C

uh I just stayed here in Florida I did some camping got a little bit of a tail end of uh that freeze that happened through the U.S uh before Christmas, so it got pretty cold here in Florida, but then it warmed up nice.

A

Well, I didn't know it didn't affect Florida, though foreign.

C

Florida, it just didn't last, uh like it warmed up after the the cold wave left.

A

How cold was it.

C

uh So here in Florida we got down to like 28 degrees. Oh.

A

C

Near Orlando.

A

D

C

It definitely froze.

D

B

Not that cold now.

C

Oh yeah, it's been uh uh close to 80.

C

And uh Fahrenheit.

A

Where did you want to translate it converts.

C

Say that again.

A

um I assume Amir uses a metric system and not uh does he even left I. Think I I need to have some uh complicated stuff to convert foreign.

C

Yeah, it's 26 or so in in Celsius right now, and then it got down to uh negative two degrees Celsius uh over right before Christmas. So did it snow? uh No it just that was an overnight low and so uh it warmed up during the day. But uh overnight it uh it got below freezing for like a couple hours and that's it.

E

C

Where were you located Tyler near Orlando, oh I, see, are the rest of you in uh in Europe.

B

I'm in the Eastland.

E

And I'm I'm in Oregon Oregon.

A

And I'm in Seattle.

D

Got it Israel.

B

D

E

Awesome so happy New Year to everybody.

D

E

All of you again.

E

I think it's we're six minutes past. So I think we can get started. Maybe other people will join in but think they can get going so. uh Firstly, some very good news like a lot middles PR with the attributes got merged, so we basically can see the attribute work as wrapped up at least for V 1.0 I mean if nothing else comes up. Let's see, but that's uh that's a great step forward and.

E

Yeah I didn't hear a thought about the next steps for us to take and I think there is three big chunks. The first is the Otep that we have about Spain structures and links. There's a bunch of comments on this old tab that we should uh that we should go through also related to that.

E

There is amuse work that he was doing about messaging links uh related to that there is a PR, an issue, a a PRI actually created some time ago in this back repo for allowing uh adding spendings after creation after span creation, because currently spend links can only be added as Bank creation.

E

But this proposal that we have here in some cases requires adding spendings after creation, so uh I think for us. The first step might just be to quickly revisit that here. It is all dependency. Is that uh do we really need that for uh for uh modeling the way we want to model and if yes, then, we should kind of push uh in that direction again.

E

Two because I think we are in a good position there, also based on our last discussion with Josh, also from the sampling site, said that you have from from the sampling point of view. Nothing is speaking against, adding uh or to put a different deal and nothing speaks in favor of prohibiting adding spendings after creation.

E

So that is, that would be another uh other thing. And then here the last thing I put here. Something I think we should do- is uh splitting up this existing document for the semantic conventions in the spec, basically having uh like the generic conventions and attributes and then having the attributes and examples for each particular messaging system, like Kafka rabbitmq uh rocket mq in different files, because that will also give us the the flexibility to uh to declare different or different parts stable at different times.

E

So uh then we can also, or other people can add, new messaging systems in separate files, like conventions particular to semantics news messaging system. They can add in different files without basically uh uh being bound to the document status of the overall document, so which means that the overall semantic conventions, the generic ones, could be stable. But you could add message or messaging system that is still uh with still unstable, so I.

C

Think that makes a lot of sense.

E

Yes, I think that's actually something we we would need. So those are basically the three big uh big I mean more or less big items, I see, I guess the last one is probably not that big. This here is some spec discussion with the overall group, probably hard for me to predict how long it will take and the first one I think that is the that is the bigger trunk that we need to take, because that involves the old type and then, in a further step, also merging the outer wording into the spec.

A

Is it fair to say that the last two items we basically need the wider Community to agree upon that we can come up with proposal and discuss it. It's like the first one reactivate the pr. So this links after creation um and we can prepare something and come to the general spec meeting right, because this is where it belongs and then derive there and the second displayed existing semantic conventions.

A

I think we should uh maybe present it to the uh this Josh sauruses group and uh this guy said like not the scope of messaging but more like uh overall semantic convention problem.

E

A

E

You think I I think for the last one we could even even come up with a draft PR, because I think it's not that much work. It's just putting things into different files.

E

It may be coming up with a general kind of read, mirror index overview file. uh uh I could probably you can find some cyclists to do that and then, with this draft PR, we couldn't show that maybe first to Josh, maybe the north, if necessary in the by the spec group and get people's opinions on that. I actually think the last one is not that controversial, because it doesn't break anything.

E

It's just moving stuff around uh to different places, a great little big but good to get like some overall uh opinion because yeah, it's kind of uh we are only one of many semantic conventions and we should not do completely our own thing.

A

Yeah just to check if anyone is working on something similar- and maybe there is some intersection there is the smithing question, Josh SARS I think it should be on next Monday and I can try to join and bring it up just to get the quick knee-jerk reaction. And if there is anything similar done or planned.

E

That would be great. I can try to get some draft PR up until then.

A

You don't have to, but if it if it's there, then it's great. Otherwise uh it's easy to explain the intent here.

E

No, that sounds great, then I will write a note here.

D

E

E

The less controversial one uh for this here for the adding links after span creation yeah, there is already uh there's already a PR there that could be reactivated, I think without many bigger changes, uh but I think your next steps would be I. Think first for us to kind of uh clarify. Okay, do we really still need and wanted?

E

uh And then, if yes, then, maybe first again just quickly checking in with the sampling group with Josh, with this BR saying? Okay, would this be fine for you from a sampling point of view and then uh maybe reopening this I guess it will involve quite some discussions.

E

Also in the wider specification group in the spec meeting ndrc, where we, where we uh come towards I, know when I opened it the last time it was basically only baked on uh pushing back and that pushback was strong enough to uh to basically set a set at work aside and the one of his main basically pushback points was that allowing this will uh with limit sampling capabilities, because then they cannot uh consider our Links at span Creation in the server when sampling takes place, but I think with uh Josh's uh based on social, serving relation from the sampling sick, where he said: okay, no actually for sampling.

E

That's not that's relevant anyway. uh Maybe we can easily overcome that. But let's see if Parkton has other other consonants there.

A

Now interesting, apparently, Josh uh approved your request for editing things after spam creation. Already there.

E

Were some approvers torture proof that, but uh uh but uh yeah mostly talked about those pointing against it and that basically then you're blocked.

B

E

B

Opens the possibility for loops in the trace, which is uh inherently not possible if uh links can be added only on spin creation.

B

So I don't think it's like an issue, but once it's technically possible, then it makes it more likely to happen just.

A

I think Loops are possible anyway, even without links like from the schema perspective, methods comes to them from happening.

B

How is it up, how is it possible if you must set the links on speculation, only set links to something that happened in the past, but if you.

A

B

Like I, don't want to cause any issues that we learn make this.

F

B

To to merge, that's.

D

B

That could affect people.

E

Yeah I think to look questions. I, think you're, right I'm. Here it's in most languages, I guess it's currently not possible. It will I think it would only be possible if you can actually set the span ID to its fan start and then you could basically, from from another place, link to a span that doesn't yet exist, but.

D

E

I think that doesn't actually work in in most languages.

B

Yeah, like someone malicious, can do a lot of bad things but uh like if we allow links after speculation, then it's become like um they'll, valid flows where it can happen, I, don't I, don't I, don't know if it's such a the thing that we need to protect from.

A

B

A

Backhand sexually supported when it's not a problem, yeah.

E

And I mean honestly I think it's not that big of a problem because span links are like uh are uh don't have a direction anyway, like there's no Direction really defined for spendings. You know open Telemetry, it's just basically, this connection, this undirected connection between two spans and in that regard, when you have two of those, it doesn't really change much.

E

So because the link relationship doesn't really say, okay, you go from this band or this band, or this band comes first, it's kind of just like an anti-reacted connection and then, if you kind of have add a link and the API API from A to B and from B to a in the end, it looks mostly the same. There's no Direction, so you just have two of those. So it's not that you're getting to some kind of cycle.

E

At least from the from the data model point of view, depending on how it's implemented there, a video can be yeah oops but yeah. Let's, let's see, let's just try for us in the group to get to a point where we say: okay, that's uh we previously deleted something that we want to have that we need, and if yes, then, let's reopen this and let's see what feedback we get also remember from book. The last time I think it's it's.

E

It was mostly dependent on um also on uh how how spend links are seen for Bogdan. A span link was mostly like, uh uh on the same level, to a private child relationship. Where is that, basically it's just? It should have the same constraints as a private trial relationship. It's just the case where you have multi-preparents, that's very use, links to model those cases, so he had like a more narrower view of Link use cases than we.

E

uh Then we I think in this group usually adopt and I think this caused some uh uh caused, some of the pushback from his side, but yeah. Let's, let's see again, maybe when we reopen that and then we say we discussed this. We also discussed this with the sampling group and we both agree that this is something that we can add to the stack without much uh without limiting any uh any capabilities that we intend to have.

E

Maybe that will be sufficient, but yeah, it's hard hard to predict for me here what to expect.

A

In the course of action, is that we first within this group we agree on what's in that PR right and then we get the blood Another Blessing from Josh, uh and then we can bring it up with the technical community.

E

Yes, we can, if you so so first I uh I, wanted to ask if that the three points, if, if you can think of anything else that we should do before, basically or that you think, is needed before we can, the can declare semantic conventions. The messaging, the medical management for traces, ready for a 1.0, stable release. Is there anything else that you think that should still be uh considered?

E

I think one other point still probably that's not here on the list is that we then revisit the attributes for particular messaging systems, that you say: okay, we look at the attributes for Kafka NBC. If anything is missing or we look at attributes for rabbitmq and see if anything is missing before uh declaring that stable, because previously we just looked at like the generic attributes, I think that might be another.

A

Or I think the big thing that's missing because uh settlement, because we don't have a defined code and we need to add a settlement operation with all the attributes. That would be helpful.

E

Expected here to spend structure.

E

I mean we had some settlement uh routines defined, but I agreed your their open questions around.

A

But they are not in the spark right. There are no attributes for them. There is no operation for it. So it's more like um on the responsibility of instrumentation to to to instrument it, but that the key part there that for settlement we need to uh uh have special attributes. We need to explain what is settled and we need to define whether it's messaging system, specific querative, some generic part of it. We never even discussed it.

E

uh I I agree, we don't have, uh we don't have a attributes for that, but let's see I think we discuss settlement here. Let me see yes, we have. We have some verdicts here about settlement regarding the span structure.

A

Do we have an operation name.

E

I think we have an operation and yes, oh.

A

E

Operation is there. We have some discussion about settlement here and uh we basically say that we should have a set of stand for every settlement operation.

E

And we say that there are, alternatively, alternatively, there can also be event. Events instead of settlement settlement spend I. Remember there were some discussions: okay and we also circus, settle, spends, made, link to create or publish and I think we even have then I hope in some examples.

E

D

E

The settlement but yeah I I think you're.

A

Right, wait: it's it's a knockout, oh the stand structure, so they will come to the specs through this order.

E

That's the idea that will come to respect through this old tab. Yes,.

A

And then now the only part that I need is to discuss what are the attributes should be so maybe their prayer messaging system and not generic and then in any case we need to Define them.

E

Yes, then I will make a separate point for this.

E

Yeah, so that will basically be like a to-do list.

C

uh Quick question, so this term settlement uh is that used uh commonly across various messaging systems.

C

I I guess uh what I'm trying to get at is uh for a lot of the various uh vocabulary that we're using in messaging. uh It seems like it's not entirely consistent across uh different messaging systems, uh so I'm wondering has somebody gone through and kind of looked at all of the different messaging systems, uh analyzed kind of what their terminology is and tried to. You know, align with the the most common terms.

A

I looked a little bit into it uh cell and uh I'm, trying to remember I think I found that the terminology is quite inconsistent. Yes, uh maybe Dwayne do you know if there is any consistent terminology that we can stick with.

F

Well, I, don't know uh I I, don't think there is um like you won't find between all messaging systems. One vocabulary that that matches all of them. um The the concept of settlement is, um if we're gonna, just focus on settlement. For now it usually in most other uh systems that I'm aware of they call it usually acknowledgment or something like that.

F

um Settle settlement is a term that kind of comes out of ampp, which, at the very least, is a a standard um and, and it's it's kind of a little bit more generic than just acknowledgment like you can have different outcomes uh like you can reject a message you can ask for redelivery um and so there's different outcomes that may use the term settlement to say what the outcome of that message. Delivery is going to be, and so I think it's a broader term than acknowledgment okay, which is kind of focused.

C

On yeah, just to be clear, I don't have problem with the term settlement. I think what I'm trying to get at is. uh It might be uh beneficial, for uh you know posterity purposes, to have a document that uh outlines uh the these different vocabulary. Words that we're using here and give some justification for why we chose those words, as opposed to some of the other words that are more familiar with, like the Kafka Community or the uh you know, the the rabbitmq community or whatever.

A

And the good part that there is no settlement in coffee.

E

Yes, so I agree there with you, Tyler mean we have basically here in this old tab. We basically describe just the terms that we use for the stages and we give like a short description, what we mean by it also by settlement, basically, which is defined by notifying the intermediary, that the message was processed.

E

So that's the that's. The definition that we give here but I I I'll, create that V. Then, when we were choose into this spec we might need like in in the spec. There is like some kind of glossary anyway, so we might, let's see what I'm pretty sure settlement is not.

C

Like I I think even like a table of uh you know the various different messaging systems that we're uh considering to support or or uh that we're evaluating having uh you know a table that represents okay, for this uh particular word that we are using. This is kind of what it means in that community so like in Kafka. uh They have producers and consumers. Okay, we're using the same terms here uh in the uh uh in the sqs community.

C

They they, maybe they call them handlers or something like Anyway, uh just kind of uh diagramming out um the the consistency and uh show that we understand um what words mean which and which, which words mean what and why we chose to go with one versus the other.

E

You know I mean what we what we have here, basically interspect. That is the specification request. We have a list of definitions where we basically Define, like the terms that we are using in this pack, so we have message producer, consumer intermediary destinations and sources and other things and uh I think if there's any kind of contentious term that we're using, we should add it to those lists. This list here make it clear what it means for us in this document for mapping this to all the different systems.

E

I'm, not sure that might be part, then of the of the specific documents that we have. For example, when we have then a separate like file where we have like rabbitmq specific things, these files might also contain. Then this, like mapping more or less, that we say okay for us on webinar, Q, side settlement means this or that's the term we use for for settlement. We could yeah, then, into those kind of specific messages.

C

I think the main thing I'm trying to say is like if we have that in like a table representation, then somebody that's familiar with a particular technology. I can come in here and look at that table and say: oh I'm, familiar with uh you know amqp. How do those terms map to what's being used here and uh you know, have a very easy way to identify that.

A

Yeah I, agree and uh I can prepare, um let's first not put in put this back. I can't just prepare the document. Was this analysis regarding settlement and I? Don't promise all the all the messaging systems I think even from the stability perspective from the target Kafka and rabbit, but what they can do. I can prepare the terminology stuff and suggest some attributes, and then you can review it and they will include well.

A

Kafka doesn't have settlement out of the box, but Revit has and I can hook them to GMS and amqp terminology and I think this should give us a good basis for the discussion.

C

Thank you I appreciate that I think that would help a lot.

A

Of first year suggestion.

E

I think we that makes sense, because they would also then help instrumentals to say. Okay, for what I don't know rapid mq operation do we need to create a popular span or for what kaf Corporation do I need to create a settle, spin, yeah.

C

Like I I didn't know that Kafka doesn't have a connotation of settle I thought that they have like a commit of some sorts like uh offset commits that might uh correlate somehow but I. Don't.

A

Know but my understanding, because it's something that's additional, you do it's not part of the Kafka per se, but I might be wrong. I will check.

C

Yeah offsets are are separate because they're tracked per consumer group, not at the broker side.

A

Let's say it's: okay, this offset this product is is settled. Nobody needs to tackle it again, I think it's not part of the Kafka and you would need to do something. In addition, uh there are some solutions, but we'll see, maybe it's something we if it's common, we should probably still give users an idea on how to instrument the user trade. But, let's see.

D

E

Makes sense so I I added, like the settlement attributes here to the to-do list so again, tracking? Does anybody have anything else that.

C

And just to be clear, I wasn't speaking specifically to settlement. That was just the example. I gave like I'm, referring to more just the general terminology overall.

E

I understood it today, you're, basically talking about the about all those terms, you're using photos. Yes, okay,.

A

Oh for other things: well, it's interesting because the terminology I think depends like we try to stick to a very common one. I understand you want mapping, but it's uh the mapping in general would be difficult because the terminology is part of API and there are multiple libraries right and uh in different languages, and they don't necessarily share the same API. So we could be in a weird spot here where we need to analyze like all the popular libraries and understand if they use the same terminology.

C

Foreign I think just a best case. Effort on like the most common ones, is probably sufficient.

C

I I'm not expecting an exhaustive table here.

A

A

Justin is an idea uh all these tough synonyms right, so how is it called and just out in the world.

A

Would it did make sense.

C

Sorry, what was the question.

A

It's like assuming, oh we talk about, publish, I can say it's also called um I, don't know sand or sending messages. uh It's usually like producers sometimes called senders, um and uh you know like just a list of synonyms, not necessarily tied to specific system yeah.

C

I think that that would help as well.

A

Okay, maybe we can start with this and make it more specific as we got it. That's a great situation.

E

Yes and and Trust to uh add to that I think we also I think we cover, or we can cover part of this still by also by examples, especially when it gets into details, because here we have like a, for example, very specific, with like some description text here and actually like a table of what spans to create, how to name those bands and uh uh I. Think we can in the in the particular messaging systems, then also make it clearly about the kind of operation the particular Spanx cover for giving messaging systems.

E

But yeah, that's just an attention to my Noble Tyler uh you're. Talking about this just uh one flavor that gives them an overview very.

D

Happy that the case.

C

D

I think having it.

C

Split out in all of the different examples makes it hard to kind of see the the overall picture of like okay, uh this maps to this- or these are the synonyms like these. These are all like terms, um yeah.

A

Yeah and coming back to your question about the to-do list, should we take a look at the project board.

E

Yes, we definitely can I did not update the project. What recently so I would basically update the board based on the to-do list that we come up with, but we can definitely look at Prospect or two.

E

And let's see whether we have anything on there, that still needs to be done.

E

E

We have in progress that span structure that is related to span structure and this one here I think we can actually move over.

E

Or I will look at this at people that that might that should be probably fixed by.

E

By the pr that we merged I think you wrote that issue with Miller. Okay, multiple message sent within a single batch.

E

Do you think that is with the attributes on links.

A

We uh it's part of the plant structure, yes,.

E

I think the parents understand.

A

E

Talked about links, okay, then: let's leave this open and that is part of span structured and we leave that.

A

E

Those are all the bad structure issues here, at least.

E

E

E

Attribute should be Somehow Here and done. I actually will add that, as it seems, they're not added to the board, I will add, then the attribute part will be merged and for the open things there's the attributes for a specific messaging systems. I think we should at least review them uh span relationships in semantic conventions. That is also related to spend structure.

E

That is an issue that we should be able then to solve once we I guess that's a more generic one, that's not just related to messaging, but it's an old one. It may be the Kenya.

E

Close this once you're through without discussion, then this is uh adding an example on a patch sense scenario, and uh this again is uh related to videoing what they came up for cloud events that we are consistent there. That is basically left over one that I asked travel to create, and here there are then a few specific ones. Cluster ID consumer client group, ID I mean that those would actually I mean those are. This is I, think part of the attributes for specific messaging systems, and this here is an issue.

E

Maybe we should look into that weather that is already covered by what we came up with uh with the within the in the other attributes, PR and then here those are some that's a very old issue about attributes and I'm, not sure we can do anything uh about this. This is about consistency of attributes across different semantic conventions, and uh this is the one we already have the recording links after span creation- and here that is a one about basically compatibility between messaging functions or service and RPC how to play together and.

E

This one I have to look into details, so this one is here- and here we have some uh settlement ones related to settlement and.

A

I think the message Ada can close it right now.

E

D

E

So they move it to time or.

A

Should we yeah yeah, please, yes, thank you.

E

For this over to them.

A

And by the way, consumer ID is also generic. Now.

E

That was some other I think it was further this year.

A

uh Yeah but yeah, but not the client 80, so there is no produce already.

E

And I think we should look, maybe look into this here and see whether it's completely. Could you take a look at that look Miller.

A

E

The issue and then maybe we can archive that.

E

But yeah, that's that's that's a good point. Maybe we should try to then or I can prepare that for next time that we look at all the issues here that are related to attributes the open issues that we have and we can see whether we still need to uh uh whether there's still some work for us to do an automators that there's the ones that are specific for messaging systems like this Kafka cluster ID here, but there's also those this is related to the payload message, sites, attributes and uh yeah.

E

We should then cariflower, but there's still something we want or can do about those things for V1 or whether we truster maybe postpone that or just to throw these issues out.

E

I will create like a list for this next time and then, uh uh basically, let's try to clean up this board so that it it reflects the to-do list that we need to come up here. That was a was a good point. Look Miller, yeah.

E

Yeah I will I will prepare this for next time. I will actually up add this to the to-do list.

E

For me, okay, then we basically let's continue this. uh This simulation next time. I think you already made some progress and I will try and next time, let's try to I will do some preparation work and then let's try to get the the board to do column in the board, the two column for V1, basically in sync, what we, what what we have here.

E

E

We have 50 minutes time left. Maybe we could uh the code related.

B

To another, the document that I'm working on it's not yet finished, but uh if there's extra time I would be very happy to get some feedback about it.

C

Did you want to discuss uh pr220 there.

C

He said: go through the open comments on the agenda right. There.

E

Yes, so uh that is, that is definitely something I want to do. Go through the open comments here, but uh I mean we have 15 minutes left now, so I'm not far sure how far we could get there. So maybe today we should then let the Amir. If you want to present what you have for the messaging links, because it somehow ties in here with this PR2.

E

Maybe we can use the last 50 minutes for this and then for the next time. I put this one here with open comments up first on the on the trender and maybe then also for you next time you could can have. Maybe you could have a look over this PR I will also then I can put it in the chat, a link to the section that is relevant for uh or wherever we need the creating spend links after creation.

E

I will put links to the relevant sections and examples into the the slack chat, and maybe you can then have a look at those sections and then next time we start discussing right away so that we can come to a conclusion next time, whether we, uh whether we should push for that further or whether there's an alternative solution.

E

And then today, we kind of uh we switch to uh to uh having a look at amir's document.

B

Okay- and they want me to share the screen. Yes, please.

B

Can you see it okay? Now you can see it right, yeah, so I'm working on this document for like uh I think two months, and so it covers a lot of things that we discussed in the Sig and it's still a walking progress. So some parts are not completed and I will probably make some changes to it. The following weeks, but um I will just start and if you have feedback I would be very happy to help. So.

F

Like the first thing,.

B

That was important for me to to list is that that, like.

F

Every decision.

B

That we take about the semantic conventions like those some perspectives, like some uh entities that are involved that might have different needs or different ways of looking at it.

B

So I wrote them here like one of them is the instrumentation Auto he wants to be able to like whatever we write in the specification needs to be able to be implemented in an efficient, readable, geomatic, simple maintainable manner, and there are a lot of friction points around it, because sometimes we put things in the specification and when people try to like actually implement it, they they can't, because there are some real world problems that there needs to be reflected.

F

B

Specification so um yeah I have some examples here. You can read later, um but.

D

B

As few examples like sometimes the users they come with requests, they say this is how the specification is written, but it's really not comfortable. For me. I wanted to look some somewhere differently or add something that is not in the specification, because it's very interesting and important or structural things in in a different way, so like instrumentation Autos as a lot of these requests, like I, see a lot of these PLS in at least in JavaScript, and yes, so this is a one part in the in the pipeline and then we have the voices.

B

These are like, um like software components that sits in the Telemetry Pipeline, and they like receive.

D

The data and need to operate.

B

It on some way right and so I think for poster Source. What's the most important thing is that, like you, have like a deterministic, uh systematic algorithm that you know that you can always operate on like arbitrary data and and and derive decisions, so there are no like edge cases or places well things uh it doesn't compile, compile well and um and and another a very important quality for processors to be able to work efficiently is if they can operate on spans like on when they get just one spanic.

B

If they have to aggregate the entire Trace in order to to do their job, then it everything becomes way way more complicated. So if we structure the specification in such a way that when you just have a single spending end, you can understand a lot about it. You don't have to jump to the parent or read a link or understand the full context. Then everything becomes very easy for processors and the last thing is telemetry consumer. They called it.

B

These are like humans that sits at the end of the pipeline and they look at the spans with their eyes on the trace and they try to extract value from it and they have other needs that are different from processors and instrumentation. Authors like they have questions they want to ask and they need to get answers from the trace right. So like giving a message ID. How was it possessed and when, like, if I see a message being published to an intermediary like who consumed it and like I I, see like a message delivery?

B

Is it a retry? So there are like a lot of questions that users ask and they look for open Telemetry to get their own cells um and they're like a lot of questions, but some of them are really really popular and we have to make sure that we cover all of them like in the specifications.

B

So I don't know um how we can agree on what uh what what questions are should be answered and which are not, but just to to state that the that it's important and yeah so so other things that, like human consumers are important for them, is like they don't like to click on like uh links to to get the full picture. They they usually are not aware of all the the details like if, if you have span with of this type, its parent is some is, is something else like they don't know all the details.

B

They just view it with their eyes and it needs to be the simplest possible for a user.

B

um They usually a lot of users, they don't, they want to be able to change the verbosity. So maybe some users want to collect a lot of information to create a lot of spends and other users they want to save costs. They want less spend, so um maybe some spends might be noise for some users and valuable for other users. So um yeah users are like the most important part here, because they they are the reason that we do all of it.

B

um Yes, so and then about the cost and um yeah anyway. These are the the three uh entities that are relevant when we evaluate or assess any proposal, I, I think um and then I have this part with some definitions, like I, looked at the definitions that the current specification and it's really good but I, think there are some things that are missing in them and I just like it's.

F

Not a surprise, it's like the the obvious.

B

But I just had to vote it, so we can refer to it. So we have like a definition for a message and and messages and the intermediaries and then a messaging, the operation and messaging spam, and then a batch messaging expand and single messaging span. So I wrote some text about each of them um and then this is like the most important part, because what I want to say is that currently, because we're collecting spans like spends, they correlate directly into our operations in the system right, so users that want to observe operations.

B

They have a very good experience because they look at the spends and dispenser our operations. So they know all the operations that happened, but when we're talking about messaging systems like the unit of work is a single message and like the current specification, it doesn't treat a message as a first-class.

F

B

Like, like a spend.

F

Can mean a message but.

B

It can like uh spend can also be a batch of messages, as we know, and the single message can appear in multiple spans and users that that want to observe messaging pipelines. They usually don't care about the operations they care about, the specific messages right and and like there's a lot of things that I think are important. We already talked about it, I just sold it down so like giving an Arbiter expense like the term uh determining if it's like a messaging span.

B

So it's the obvious, uh it's obvious and giving a little bit of expand determining if this span represents like a single message or a batch of messages, no messages at all like a control, plane, I think this is covered by a rude Milos PR recent PR, um giving an arbitrary span enumerate all the messages involved in it.

B

One or many and tell if some messages are missing like if they spend represents 10 messages, but we can only enumerate the five, for example, and these are all things that I think are very important to be able to do like there and then giving like once we we have like yes, a single instance of message in hand like being able to efficiently uh enumerate all other spends that record this message.

B

So if, if we have like a span for consuming a message, we should be able to to deterministically be able to say okay, these are all the other spends that recorded the same message and and this one shows how it was produced. This one shows out how it was settled. This uh spends the show how it was forces, so we need like an algorithm to be able to do it um and if we.

D

B

A specific message to be able to extract the attributes that relate to the message not to the operation right, so um yeah, so.

D

B

Feedback so far, is it helpful.

A

I have a something, but it's it's a great document and it's it's I also feel that it's important to see different perspectives. When we talk about instrumentation and uh sorry, the this fact one point I would like to see is how does requirements translate into the spec like what is the Delta? You would like to see in this fact to satisfy this requirements.

B

Yeah, it's a good point, so these are all like preparations because uh later in the document, I want to suggest some changes and I want to like say these changes because, like it helps to satisfy this requirement, and this change helps to satisfy something else. And here there can be a couple of options and I want to like uh base it on uh on on things yeah if, if I scroll down so so, I have like a more things here and it's not yet uh completed.

B

I will probably walk on it above, but um so it'll you'll, like basically talk about like the the links I, see I only said two messages at two minutes. Maybe I'll just uh show you the headers, and then we can finish for this time. So uh there's a section that talks about links about why I think it's in.

B

We should use links and not something else, so it just summarizes everything we talked about in the Sig like um during the last year, um and here I have like a section about the links semantics. So this like comes down to the details of like how exactly things should be structured. So all the relevant entities would be happy like we can do something that we can't do something that will make everyone happy right.

B

So we can write a great spec that will make instrumentation Auto's happy, but but then users will be not happy or processors will be not happy and like there's. No, no absolute.

B

um Tools like everything will be compromised between the needs of various parties, but uh yes, so I have the deals and then I have um like this part is like uh an algorithm like how do you record a message into a messaging span? So exactly what you need to do like cases? If it's a batch to this, if it's, if you have the the contacts, if you don't have the context, you have like a like a recipe for what to do um yeah, but it's not yet completed.

B

I just uh wanted to present it to you and maybe get some motivation to to work on it and complete it for next week. I hope.

E

So we are at time now I'm here, I, just uh I will have a look at the document. Just do some quickly comments, a quick comments, I think I see three big Parts there I think. The first is that you try to list some requirements. I think that's definitely useful, because we can then uh evaluate our existing.

E

Existing spec can be in the end, be evaluated against these requirements and we see. Okay. Are we fit to kind of satisfy all these requirements? The other part, the last part that I see. That is definitely very useful, but I'm not sure where it can end up in the end that this basically comes some some kind of end user documentation where you say: okay, that's how you can actually write.

E

Instrumentation based on these semantic conventions uh and the middle part I think is where you propose some changes to to the existing semantic conventions based on the requirements that you came up in the beginning and I think it might be good to maybe uh maybe keep those things apart or split things or focus on a certain thing, because I think the last part is definitely very useful.

E

uh Very basically, people have some kind of guidance of how to use the existing semantic conventions when writing instrumentation, but I think it's a bit of an uh an overload for people looking at the document, because there is 22 like many content in there. So I think when you split out this document and you focus on getting the requirements and the gaps that we need to fill to fit those to do uh to uh satisfy those requirements. uh I I guess we can have a more efficient discussion on top of that.

B

Yeah, so I will keep writing it as a single document and then we can discuss maybe how to split it or maybe what to do with it, because I'm not sure if it should be. You know what the spec app yeah, maybe multiple as you mentioned, so we can discuss it next week yeah, but uh thank you for the feedback.

A

By the way, I have a proposal pose of time. Is it's a short one? uh We can write a set of articles for one article about how to instrument messaging system uh the client side, and we can put it into the open to. Let me try your Docs they're. All like the three four particles there.

E

Yeah, that's that's. Definitely where I I think would be a great place for this last part of your document, where you basically describe okay, how to concretely use this uh conventions to write instrumentation yeah. That would be a great place for that for an audience. That is basically not just this group or not just open Telemetry, but basically everybody who wants to write messaging instrumentation.

B

Yeah I think we will need to decide what goes into the spec and what should be like less formally written down as like I. Don't know how to care blog post, something that I I just liked everything that I think that.

E

B

And then we can discuss how to splitting. Yes.

E

And maybe your document can be a good place to discuss that if you say okay, what do we actually want to make key into spec? And what can we trust here put out? There is blog posts for people to to pick up. I think that is that that would be a uh at least one of the great benefits we can get out of of this document. You're working on amongst many others,.

B

Yeah cool, it's still a working progress. So if you read it- and it doesn't uh look right to you- then it might be because I didn't finish some pounds yet, but uh so I will let you know when I think it's complete for a review but feel free to read it in the meantime. And maybe you have some good feedback yeah there.

A

Is one uh thing right away? You can mention the attribute your suggestion, messaging uh link, type and type I think we should probably Define it on link and it should be general purpose and I think there is an issue about it. I'll find it in our request and I'll. Send you uh it's over slack, which.

B

Attributes are you selling to.

A

The messaging link type.

B

The messaging link type here, yeah.

E

I might have I will I can put a link in the chat. There is the actually put that on the messaging on the hotel messaging slack Channel some time ago. The link to this uh to this message that mail is referring.

A

Awesome. Thank you.

E

Okay and by the way in the so I have to go for for today, 9905 have a hard stop, but also I put the it's. It's only. The two of us left but I also put links to the relevant sections for the receive operation which requires adding uh links after spam creation into the messaging slack Channel.

E

So maybe, if you have some cyclists until next week, you maybe can look at those parts, maybe add comments. Otherwise we will start discussing next week.

A

Yep awesome. Thank you.

E

Thank you thanks. Everybody have a great week and see you next time. Bye.

A

See you next time bye.