Open Telemetry Uncategorized, 2 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-03-02 meeting

Description

Instrumentation: Messaging

A

Hello, hi everyone, hello,.

B

I guess, let's change a little bit more! That's right! Do you know if Johannes is joining.

A

Sorry, can you repeat it.

B

No, you know if you, if Johannes.

A

Is joining, let me check.

C

A

D

Hey everybody good morning, good evening.

A

D

So sorry, for being a bit late, my computer, seven minutes in I think we can get started right away. I will share.

B

Okay, here we go.

D

Okay, be on Monday the uh it was just immediate and draw so we canceled, let's see if we going forward, have with us attendance on this Monday meeting. Otherwise,.

E

D

We can remove it from the calendar, then, but let's still try a few times more I would say we would need at least to have three people two to do some.

D

Okay for today, so let's start looking at the board. I did not have time last week to reach out to Ken regarding this consumer group ID, but I will definitely do that. I see there has some there's. Some discussion has been going on to Miller side, especially here regarding the terminology like when we talk about destination kind, q, a topic and Q and topic and address I just when I cleaned up the board. Yes, it is okay.

D

We have two issues for this year: I'm not sure if they both uh uh are all the same thing. I think what is actually new about here, the one on the top.

A

Yeah, so they are kind of different, but Christian brought an interesting point and in one of the discussions, I think it's in the pr that's uh addresses or if you go to this comment.

D

So here here in the song, okay,.

A

If you go to the link to the comments, the last one yeah and if you scroll down so uh basically what we realized that uh it's, it's not clear how consumers of telemetry are supposed to use the destination code and then, if it's not clear, so then why? Why are we even having this attribute should be removed? How does it help.

D

Yes, I mean that's, that's one point I made previously in a comment: I think uh I I think for many messaging systems there exists only one uh or one terminology like for Kafka. There only is a topic, don't look using Kafka and for a rapidmq uh at least as far as far as I know, there are only queues, there's not a real topic, but in webmq.

C

D

uh And it's the same for like the uh for.

E

D

Too, you don't really have a topic. So basically, if you know the messaging system, so if you have your attribute messaging.system uh in most cases, you know whether you were kind of sending to a queue or a topic.

E

But Rob mq, like you, when the destination of a published message, would be like a key in exchange as opposed to a q. You don't send it to the queue.

E

The queue the destination or the source type on receiving from rabbitmq would always be a queue, um but in JMS topics and cues are are distinct and and I think there are a lot of JMS implementations out there um and because there are lots of different and in other messaging types, there could be more types as well and I I, like the idea of just saying that you know Topic in queue are, are too possible destination kind for Source kinds and that you know other like rabbit mq that doesn't fit perfectly but they're free to Define others um and specify them in their own specification.

D

Yeah my main point that I wanted to make. My comment is that uh currently this attribute like destination and Source kind, is uh required. So it's like. We have like a strong, uh yes and.

E

uh I agree, making it optional, makes more sense and.

D

My point was requiring it basically only for systems where, uh where, uh where that support, both I want to support more kinds.

A

How somebody would use this information? What does it change for them? Why do we even keep it as an optional? How does it help? What does it say.

E

Well, you can have topics and cues that have the same name, and so it can help uniquely identify the object. That would be one thing that comes to mind.

A

This well the same within one broker with the same name. Then it's the same thing. Nope.

E

Nope, uh like definitely, you can publish to a JMS Topic in queue that has the exact same name, and those could be two very different things like the type and the name are, are both identifying the attributes if either one of them is a different value. It's a different object out.

A

Well, on our blockers for service bus I can publish like publishing, is it doesn't care right, I I can publish to you or a topic. They are the same entity.

A

uh Dms is an abstraction right and like so what I'm saying that on the publisher side, there is nothing that changes regardless, where you published it. It's on the consumer side, where it's remotely important.

E

I I think some of those details could vary with the underlying system. I I think it's still valuable to have, and if it's not useful in a particular messaging system, then don't include it.

A

How is it useful? Can you help understand, because that's what I'm missing.

E

One reason is uniquely identify the object.

A

We are saying that the combination of net pure name and the destination name uniquely identifies an objective. We have the reasons to believe it's not the case. We should address those problems because the kind from the semantic conventions doesn't solve the uniqueness, not problem currently.

E

Okay I uh so I guess, if I guess what you're suggesting is either including kind in the uniqueness qualification or for systems that have, where kind can affect it, they have to help with some a way of designating the name in the trace like. Maybe it would be. You know, cuticle and whatever topic colon whatever, if uh to make it uh unique.

A

Mama and Nickelodeon.

A

uh Yeah I'm saying: if it's the only thing we get from it, then that's that's all we can some of their way.

D

You can get from it on the consumer side at least how I understand those attributes and I mean I, understand it that basically, a queue is kind of uh uh is what what identifies the keyword think is that there is like an individual settlement. Each message is settled individually and when I think about the topic, I think about checkpoint-based settlement. So basically you advance the checkpoint and I think uh the only thing I could get from it when I think about it.

D

When I see, for example, a settlement operation on a queue, then I can be sure. Okay, only this single message was settled by this operation, but when I see a settlement operation on a topic, then uh more messages might be settled by this operation, because it's just advancing a checkpoint.

E

Though consuming from a topic, it has the same acknowledgment semantics or you know, um checkpoint like it. Just you consume a message on a per message basis, whether you're consuming it from a keyword from a topic yeah.

A

This is the same story for a service bus.

D

And then I don't really see much use here besides the identity, uh besides reasoning about the identity of the of the source or destination.

A

Going do you know any particular system uh that actually supports having cues and topics was the same name.

E

uh The solar system does for sure okay.

A

A

A

Because if we keep the identity in the kind, then so far, what we have elsewhere in this pack is wrong, because we assume that the combination of the network name and destinations, so we we have to find we have to either include it in that entity or put it inside them. The destination label.

E

Yeah I mean if I I guess you know, like a single example, is not a great um thing to base a general specification on so I'm, not sure I'd have to think about some others, but because, if it was truly something very unique to Solace, then I would say it goes in messaging.solus dot, something um I, I, guess I I, my like the reason we did it. The way we did it is to allow for better implementation, better adherence to JMS.

E

That was the reason we actually allow them to have the same name and I am not at the moment.

E

This was you know, probably 15 years ago, or something and at the moment, I can't quite remember specifically, why that's uh useful um so I, don't know whether how generally applicable it might be uh so I guess, yeah supposed to say, I, guess it yeah I'm saying if we're the only ones, if Solace is the only one that does this, then that's not a great argument to keep it in the spec, um but I I have a feeling the reason it's there is because of the JMS spec, because this back originally was fairly jams Centric, and um it might be worth just a for me to take a review of the JMS spec a little bit to understand how useful that would be generically for JMS if you're implementing something to the spec of GMS.

A

Yeah, you can look, it should be great, so.

A

Yeah one way like on the producer side, we can specify topic or a few. It doesn't matter prediction. It doesn't matter on the consumer side, though um it results in creating uh we'll call it entity pass it's not the name. It's like it contains information about topics subscription right. So it's like a plus.

A

It contains words like topic, name subscription, name things like that. So maybe it's something that so is also supports. Maybe internally the the name is represented. Like a structural.

E

uh No, no, not really a name is pretty much just a name. The configuration against the queue like it's subscriptions um are our kind of configuration on the Queue um and but they wouldn't be part of the identifying attributes, like the things that make it unique.

A

Okay, do you feel it will be useful for users to create topic and queue with the same name.

E

Whether it's useful like whether uh I would Advocate they do it, um I, don't I I, don't I, don't really see a good use case there, um but if I I believe we did it the way we did it um just like I said just because if someone publishes to a JMS topic and then consumes from a jmsq I believe at the time we did this. We believe that that shouldn't be consuming from things that were published to the JMS topic and- and so therefore, we just you know to adhere to the spec better.

E

We consider those different objects.

A

Yeah, what I'm, trying to turn the users who create Community topics was the same name and sent to them from the same place.

A

um Well, I would expect them to have observability problems, and we probably want to give them some identifier uh in the name that would identify them fully.

F

I would I would agree with that.

F

um My main concern is correlation, um so as as you're as you're, taking that data and you're you're going to use it either human looking at it as an attribute or you're going to have systems reading that as a signal and matching it up, so it is a little concerning having having that name be be dictated by one system.

F

um You know having that capability. um I I agree, if that's something more specific to that particular either spec or that particular thing. It should be really under uh something very something specifically for that, not not dictating that that using common names would be allowable and possibly cause a little bit of chaos with everybody else. That would be my my opinion on it.

E

So what one key yeah I I agree, I agree fully on not dictating something based on one system. I think that the um the key being whether there's usefulness in terms of a JMS uh perspective and I just did look up. One difference between JMS topics and cues. So a JMS topic is is a broadcast right. It's it can go to many destinations, but if you're sending to a jmsq, it's implicitly point to point like there's, so that the semantics of a message published to a topic versus a a queue are different.

E

um I haven't looked into the consuming side yet but uh yeah, that's that's one difference in terms of publishing to a topic or person acute. So it's important to know that it would only go to one place or possibly many places.

E

Could be useful.

A

uh I think, even if you use few semantics, it can go to multiple places in a generic case. You can be route it, it can be um I, don't know it can be received by multiple consumers anyway, on multiple attempts right, foreign.

E

Kind of persistent Story one uh destination like it's, it's whether it's point to point or broadcast is a difference, um but I think that, but using the GMS semantics here might not be a good thing, because I think people think of you know cop I, I, don't know if that would be obvious to people.

E

If that's the intent of what you're trying to say, if you're trying to say this can be point-to-point versus broadcast and using the term topic or cue to describe that I think that might be a poor choice of of words um just because it's that's what GMS defines, but those terms Topic in queue might have very different meanings across many different systems.

A

So, for the sake of time, I suggest the following: it sounds like uh we don't know how tracing back-ends, observability backgrounds would use this field. It does not provide any clear understanding of the it doesn't say anything uh it only so far. We know about the use case to provide uniqueness to the the destination.

A

How would you feel about uh removing this attribute? For now? We can always return it and emphasizing that, at least in the current, like and I think that this weekend won't be able to change after the stability. Is that the pure name, plus destination name or Source name is the the this combination is has to be unique and I. Think we have this language already.

D

C

D

Me I mean I'm in favor, of taking out complexity and ambiguity here and also one one last thought that came to me about, like the identity, I think for identity. Ideally, you have one attribute that kind of defines your identity of of this entity, which is also destination. I mean we have two attributes: that's okay, but three attributes they are already what like, as a user, start to scratch. My head yeah.

D

So yeah I'm I'm fine, with proposing uh uh uh removing uh removing destination and Source kind.

A

Okay understand the pure.

D

And then, basically, all the discussions here will be obsolete too.

C

D

Q versus address, so we just uh categoric knot by removing this attribute all together.

C

D

Okay, thanks Luke Miller, for uh for having all the discussions on this.

A

Yeah. Thank you also,.

D

And especially in the PRS.

D

Okay, then uh Let's.

D

Osc Carlos put something on the trender, so maybe let's take that before we go into the old tab, because usually we then spend the rest of the time just going through open all tab commands but uh uh Carlos. Let's talk about the yeah.

G

Actually, one thing that I just remembered is about uh adding links after respawn creation.

G

um That's still political, as you may have read, and uh I will follow up with the we I will be trying to push that goal can allow having Links at end time and for the rest of the six. We just add that as an actual method, you know, um there's it's there's a lot of political stuff there. So hopefully this will work out for everybody.

G

I need to talk to him because he had some doubts regarding this for sampling and other things, but hopefully I talk to him later today and I will post an update and we can decide what to do. um Yeah. Sorry for that and on the timeline. I just wanted to mention briefly. uh um So, basically, one of like the this is working with tedion from the GC about how to make progress in cooking groups and all that trying to formalize having more approvers. You know.

G

So basically, members from this team can approve the Stalls that we need, instead of just waiting for people who are really into Telemetry, and they are not familiar with this and we wait for the reviews which may take longer and they are not as involved at all as us and so on, and so on. One of the things around that um is that Ted was mentioning that there's an advantage regarding having deadlines and which is something that, for example, a trust group is trying to vote.

G

For you know trying to you know, having a deadline for making the HTTP semantic conventions table and I was wondering whether this group would consider such a thing. You know- and you may remember, that that had something like six weeks for discussing all the things like in this group come to an agreement and then four weeks to present that and to the community to wait two, two more weeks to clean the door, something like that and I was wondering whether this as I said before whether this group would be interested in something like that.

G

I think, there's a lot of value um yeah! You can tell you about that.

D

I mean I can give my point of view here and I'm in my point of view here so I think it definitely has value, but I would wait for us to come up with a timeline uh uh until HTTP semantic conventions are through and maybe are stable. Is that, like, after their timelines, are over and then basically, we kind of because I think many or at least some of the questions that we answer are the same. That HTTP needs to answer and I think once HTTP is stable, I think the spark of question is answered.

D

Our kind of surface area is reduced and I'm also not sure whether it's kind of then uh beneficial to have kind of both areas running on deadlines, in terms of kind of people being able to focus to think about it and to review or if it's better, sequential I would think it's better sequential, but I'm yeah.

G

That's a good point: I could I could say that as long as tracks, trasks group is not delayed, you know with the time expect same line. We could wait if, if it happens that they have to delay something, then probably they're they're coming overlap. You know um yeah. So let's wait for that. As you may have read or heard, uh there's one thing about things that we haven't decided regarding: ECS alignment or not. You know for.

C

G

So um yeah probably we should wait for that. um Yeah. Okay, perfect! So let me think a little bit more about that, but yeah I would say Let's uh yeah! Probably let's wait a little longer before we Define a timeline for this.

D

Do you have any opinion on that as you're involved in both efforts all.

G

A

uh Yeah I think running them together. I could not I, cannot manage it, but sequentially I'm happy to put more effort into messaging and uh push them forward. I think we are mostly in agreement regarding the big things and I think we can make a huge progress in a specific, dedicated six weeks, for everyone uh tries to make it fast and scope things properly, like I think this group will benefit a lot from it. Assuming we have our choir members committed.

G

Yeah, that's a good one, because indeed they, like you, know, trust group. They meet uh two weeks two times a week three times a week, sorry yeah! So it's three so yeah. um Okay, that makes sense. Then, okay, perfect yeah, good good thing. I will keep that in mind. So I can you know use if somebody in DC asked I could mention that this group is a little bit holding up we're still discussing stuff, um yeah, okay, perfect. That makes.

D

Sense, I think that's also. Another Point good point makes that there's a certain kind of overlap like Luke, Miller, she's, basically really deeply involved in both groups, and at least some in both groups are kind of involved in reviewing stuff from the other groups, so I think just in terms of kind of resource split. It's also there might be benefits of doing it. Sequential.

G

Yeah totally that makes sense and uh yeah okay and just for the something to consider um we had talked into C to have per each working group, two people being a product. You know um so yeah. We can talk this later. Who would like to be that you know like approvers specifically for these uh messaging semantic conventions?

G

um Yeah, okay, perfect.

D

A

D

So then, let's go over uh over the Otep over open commands. I made some changes uh last time here at I did not uh commit that change. Yet maybe you can just have a quick look, whether that makes the uh uh sense to you.

D

I think that that is based on our discussion from from last time and that is uh related to when to link to the create expense, and we said usually for individual settlement scenarios- that's feasible, so we kind of uh uh asked this to be sure and where it's not feasible, which often are track. Point based scenarios then uh uh uh yeah that, uh if not, if it's not feasible, it should not be done basically yeah. That's what this.

A

Okay, yeah sounds good, um I, I'm, sorry, I didn't read the comments yet I'll read them offline and it sounds good if I have minor comments. I'll leave them. Thank you.

D

And here we also had uh I, also summarized the discussion from last time uh about the uh the kind of uh publish of of publishments, and basically we have. We have two options: uh either we just say Okay publish when it exists. It always is producer or we kind of make it big and we say Okay producer, it's only producer if no create spans are present and we leave out like dimension of that, it's internal, otherwise, so it could. Basically, according to the to these conventions, be anything else.

D

I think those are the two, uh the two kind of options we came up with in last week's discussion and yeah. Maybe you can uh have a look here and then add, like add points or preferences in comments here, I think I think we don't need to revisit much discussing here. That was basically moving from last time. I do this or that way and.

D

And then uh yeah about the saddle span, let's go there because it also is about this mankind. Here we uh uh more or less ask or require for the settle span to be internal, and uh yes, that's also a good question that uh that lute Miller poses uh uh why internal here? What else can it be I think it cannot be produced or consumer that doesn't really make sense, I think it could either be internal or it could be a client's pen.

A

Yeah I mean this is the call to uh going out now, if they're a transport physical layer codes, but it's a logical call at least to the external system. It's kind of request response thing right, so it sounds like it's. A client's thumb.

A

An internal kind of assumes there will be underlying studs, which doesn't have to be the case.

D

Yes, so that sounds that sounds okay to me, I think it's definitely a client spend like on the, if not on the transport level, but on the logic level.

D

So I'm uh I don't have any problems with requiring this to be a client span.

B

I think it makes sense. Yes,.

A

I wish we could I, don't think the spec supports it, but I wish. We could believe this band kind like provide some options, because the assuming quite instrument underlying calls right- maybe it doesn't have to be quiet, then it can be internal run by requiring a client or saying okay. We in any case make it quiet.

A

It creates problems for our backend for Azure monitor, because it would like to separate the actual physical culture. But this is not the messaging concern. Maybe.

D

Is a similar problem that I saw this one actually be related issue where you have kind of uh the transport operations underneath the HTTP client span.

D

Is this a similar problem? There.

A

So what we are saying there that this author thing is it's like it doesn't have any semantics. It has called semantics, it's just a span.

A

Yes and probably internal I, don't remember the details, but uh there we know there are underlying patiently dispense here. We don't and it will be nice to get a clear guidance. So maybe I'll create an issue and I'll try to. uh We need to like it's a separate discussion. So for the sake of this discussion, let's say it's probably client, but maybe.

A

um The problem that in yaml we have to provide you one kind: we cannot provide two different kinds right, so um maybe we should Define it as a two different uh spans. One is logical, another is physical right and we can solve it in this way.

A

um I just want to stay away from this internal versus client discussion for the time being, good on health.

D

Yes, that makes sense, I mean that then basically have the same problem like.

C

D

A

D

Leave the type or the kind of the settles when unspecified.

A

When people would put consumer there, let's say it's internal or client for the sake of the startup right and we'll figure it out later.

D

When we say this could be, this could also be a client span, and then we basically add, like we say, Okay, client, internal or client.

B

Okay, so the best world would be if there is the underlying HTTP calls, then uh internal would be best right um um for for this logical thing, but if there are no uh HTTP calls after this, then the client will be makes more sense. All right.

A

B

A

Monitor and I hope for other backends that want to run their up map yeah.

B

Or seriously I think I think that makes sense um some yeah um but having two then two different.

C

B

Also, not not so great I guess, because there is also the other I mean it's the same situation, but there's the other uh the setup for the producer I think there was some. We had some comments in some some of the Otep or something, um but it's the same thing again.

D

You opened the pr robot like it was tested critically spent types where you have different layers of instrumentation in both like creative clients, then, because here I mean in in practice when we say Okay internal when there is like a child, and that is a client and the client otherwise, in practice, you cannot really really think that, because, if I, for example, use HTTP Auto instrumentation that they can turn on and off basically I mean off. This should be a client and then, when they turn it on, this should be from I.

D

Think it's uh in practice. It's hard to achieve, and it goes back to this problem like with those nested's playing kinds, yeah.

B

But even if we do create two different ones, it's also the same problem, because how how do you know which one you have to use depending if you have stimulation on stimulation of.

A

Yeah, that's it's a difficult problem to solve. So, let's, let's live with up to I, don't know, for example, I'm serious bus or event hubs. We know we that the underlying calls are not instrument.

A

The mqp is not instrument that they don't assume anyone, instrumental lover instrument, our own ampp stack, acceptor plus, so we kind of safely can say it's a client, but in other cases we know for sure that underlying is also instrumented, and we can say it's an internal, so I don't think we have to specify it uh that in that many details and it's more like a general spec that can adopt some more clear practices there.

B

Once we have so the the goal that we have is the V1 right, so the the the let's say, logical instrumentation, but once we work or once there is the like, the uh the broker instrumentation and so on, like we like we talked about, is V2, um uh then we would probably maybe have to revisit this or uh change the the types of maybe leaving it open now, for example, leaving a client and then maybe saying like you're having the producer um proposal there uh with some.

B

Like can also be this or something like that, um then at least, if we decide to um change afterwards, that is not so breaking I, guess not sure.

B

A

B

Yeah yeah I think so too. So the awarding like you used in the producer yeah.

D

I mean I could also like take it out of this table and just write. Some kind of a sentence about settle can be uh or internal to make. Kyoto did it. We don't have that strong, actually environments on the settle span, then we have, on the other spans.

A

B

Think that's a good approach. Yes,.

D

I mean and for me like for the saddle span when I think about it, like the key for I, think mechanical intermediaries actually uh better. It can possibly be the parent of a remote service plan, so I think if I somehow pass on the context of this settle span to the uh to the other side, and it's used there I think. Then it should be client if I don't pass on the context of the saddle span. But this is happens by some like layer. Underneath that passes context on them probably should be in turn.

D

Because I think it's too confusing, but that's how I think uh it can be. It can make sense.

A

Yeah and if it's the tooling problem that doesn't allow us to set the different kinds, we'll solve the tooling problem,.

D

Yes and yeah I I will then, if that sounds good for you, take that out of the table and just make uh write it like in in a like in a separate sentence. Underneath that is settle span basically, can either be a client or internal.

D

Okay, then, let's go on here.

D

B

D

Context that basically means when they're, when the message has a context that was created neither by this great or public spend, but by some customer specific operation that the customer wants to attach.

A

D

Yes, that definitely makes sense, I'm not sure now whether there is already wording.

B

I think I I remember reading this at some point, I started reviewing as well I. Think I I saw something like that, but I don't remember where exactly.

C

Let me check out.

D

I I'm definitely sure we have an example for this I think that's.

B

Because we discussed this uh very, very much in the past, I think is.

A

I think I remember looking for it and I didn't find it, but if I missed it I'm sorry.

B

It's a lot of text, yeah.

D

So Let's see we.

B

Talked about, we talked about it a lot, but maybe we didn't put it there somewhere.

D

It might, it might be the case that I did not manage to put it in this summary here, but that we talked about it here in the.

B

D

Oh here I mean we have descendants. In that case, sdks may provide mechanisms to allow attaching independent context with messages.

A

It's not that if I injected contacts myself for a received message from another messaging system that sdks have to preserve it, so I'm looking actually for a very strong language. There.

D

Yes, so in this uh this preserving from another message there, you basically talk about like something like message forwarding or like training messages.

A

uh This, uh like forking words, so people Fork messages to refer for redundancy and reliability. Also, if I'm, a user and I want to set this context all right just manually, then uh I should be able to do this without SDK rewriting it.

D

D

That makes sense, I I'm still 100 sure, but, like the re-existing context, how to interpret that. But.

B

uh By thinking the current spec didn't wasn't that part of the? uh What that you worked on, that it should be immutable. The context in the method, something like that I think it was your.

B

I think there's something like there. There I.

D

Definitely think once the context is attached to a message which should be immutable. Yes,.

B

And then that that kind of uh uh resolves this, this requirement.

B

Because if it arrives at create without with one already then it's immutable, then yeah I mean I I, think it still makes sense to clarify it because it could create it and just replace it. I guess.

D

If you, if you somehow get the message that already has a context on it, then uh then you always need to kind of preserve this context. That is already on the message.

A

Yeah and if we follow this approach, we should also say then then publish operations should link to that context instead, but in the same way.

D

So the published band should link to this context, that is on the on the message.

A

Yep, regardless of where this contest came from.

B

But if we have already know.

B

D

I think we have some.

B

In their drawings or something.

D

D

I think we don't specify that the publish Span needs to uh needs to link to create spends.

D

The great spans can be created during the publish operation is Children of the published span or create operations, can uh spans can be created independently of the published operation.

B

Yeah, if they're going to Independent, then I guess we have to link them together right.

A

It's even important without the existing context. So, for example, um we there are buffered producers which take uh messages badge them in the background then send after like in a background thread. So then they should capture context. One message is created and publish will happen in a different context. If any right and the only way to connect them is through links, then.

D

That's kind of what we currently have. We don't demand any kind of Connection by the conventions between publisher and create, so they can kind of be completely independent, too.

A

Yes, come from different pulse, three can be indifferent and then contexts.

D

So and we currently don't demand any linking in between them, I'm, not sure if we, if you think we should add this to this current old type or defeat open for now,.

B

If they are created as part of the public State, the link is necessary. I think right. But um if the context is created.

A

But even even in this case, assuming you have two different publish operations, how do you distinguish which messages come to which publisher operation without links look forever? Babe.

B

No, but if, if the message arrives at the publish without the context and then it's created there, then it will be, there will be children of publish. So then you know.

A

Imagine the right to publish operations and four messages created in this picture. You don't know which belong to which and if you messed up I, sent the wrong message to like to the the wrong destination. You wouldn't be able to tell.

D

I mean yeah well in this picture, I mean we assume it, but even here we don't know whether these two create spans refer to this publish operation. It might not necessarily be the case.

A

Or if they ever were sent at all.

B

Yeah, but in this case it's because the create context was created before publish right.

C

B

Yes, this diagram, yes, and that case links I, think I think we need to have it otherwise, yes, but do we also need it when the message doesn't have a context and arrives at published, so they start, publish and and I know, but you still have to create the car. Okay, I.

C

D

Then either you have this case, where you have no create spans at all, and you do everything in publish or you have to create this child of publish.

B

Yeah, but you can't have great job a child of publishing, guys guess you can, but.

D

What do you mean when you, when you send message with kind of a predefined context,.

B

Yeah sure I'm trying to think now but like if it if it arrives at the code at the published time and uh and then you start a Spam to publish it, that there will be the underlying transport calls and all of that stuff. uh And then you create so yeah I guess it depends how it is done. But.

A

So it seems like if grade is not a child of publish, then there should be links. Yes,.

B

Yes, I think so I think we need to add that too I.

E

I agree with that uh-huh.

B

C

B

A

I think um yeah. Maybe we need to chat with our friends at the uh reporting because they also want to have links for regardless, because it's there is something important they get from them, um and I will ask uh and we'll find out how critical it is for the general case.

E

I I would tend to think that it might not be uncommon for the create span to also be the ambient span.

E

If that happens, does it make sense to have publish as both a child of ambient and then link to the same span, or would that be another special case where you say well, in that case, don't bother with the link.

A

It sounds like it's it's custom, though right so the ambient context and like in in common case, you don't know if it's a great span. That's that parents, publish of.

E

Course, yeah I guess like so I guess what I could imagine is that um like so this is what I was thinking uh um Auto instrumentation might look like. Is that a AP like an API call to create a message?

E

um Would if there's an ambient span that could attach that ambient span as the creation context to the created message and then that create color return, the application does more stuff and calls publish and the ambient span hasn't changed and but it could have, but in many cases it might not, and so in that case, would it make sense for publish who's going to be a child of the ambient if it sees that the attached creation context matches the ambient span, should it be both a child and linked to the creation context.

A

In general, we would not recommend uh adding a car ambient context as a message context, because you, you can distinguish messages after that right uh and if somebody does it, then we don't know all the instrumentation shouldn't be. But if somebody does it, we don't know whether it's a random ambient context like when you look at the traces right and you don't see a link.

A

You don't know whether there was a message if there was a message why there is no link uh and it wasn't the ambient context right. It's just not clear from the consumer side. What was the message context.

B

And there's also the attributes of the methods or we could add against those as links. That's a good links, but.

D

You know basically with the solution we have currently kind of venue, then look over to the trace of a message from interpublished. Pane can be basically detached from this Tracer when you have create and receive linked. That is guarantees that we give, but where these publish ends up, who knows I mean I, think you can kind of maybe assume that the published operation is uh part of the same Trace as this great operation. So you have them kind of linked like parented here them somewhere with some relation.

D

But if there is now no kind of uh relationship you can rely on here and I mean I'm I'm, uh as it seems to have some consensus, like the link published to create here I'm a bit hesitant because yeah, basically, the only in terms of just having the high level view on this out tab. The only link type we currently mandate is always from a producer to a consumer span.

D

That is the only links we currently require, and basically here then we would kind of also more or less require a different type of Link in some scenarios. But I I agree with you that it makes sense and let's see whether we can fit it in here.

C

E

Wasn't like I wasn't sure exactly what the nature response was to my suggestion of not linking if the ambient is the creation context uh like if they are the same, do we think that the link should be there anyways or we think that should never happen to begin with.

A

This should never happen to begin with, and all the instrumentation should not do it.

E

So so I guess so I mean I, I, think and I think the the rationale behind that is in a batch scenario, where, if you're creating multiple messages in the same ambient context, you don't want the same. uh Contacts for all of the messages is that correct.

A

uh Batching or just sending to multiple queues.

E

Sending the same message to multiple keys.

A

You know sending multiple messages to different destinations or sending multiple messages to one destination.

A

Also, you know they have been contests, it's not the producer's pen, so uh the backends, if they rely on producer consumer heuristic at all, they will have troubles, surrendering.

E

Yeah I I guess where I'm coming from, is that I would it so if the ambience like, if so, if the application doesn't do anything to attach a creation context, we end up with the publisher uh being the published span being used as the creation context.

E

But if there was a different ambient span at the time of creation, it would give you some Trace back more um applicable to where the message was actually created. That's why I was thinking it could be useful.

F

Yeah because I know from a from a customer from a use case standpoint, you know what people are trying to do is is essentially have the option or the Artistry of being able to knit these together.

F

um Some people, like them tied directly some people will probably like them as links as well um and I know. That's that's a that's a counter argument to a standard and I'm sorry for bringing that up, but I think that, and maybe that's because right now we're in a state of flux, but um I think that the the and I need to I'm going to go back and understand more about specifically what an ambient span exactly is, but um I'd like to continue to talk about this in future sessions for sure.

D

Yes, we are on time today anyway, so uh maybe I'll be. We continue here next week and uh uh uh let's continue to discuss this next week when we made some some progress like slowly grinding through this comments so and maybe we can then uh continue discuss I will I will try, maybe to add some proposal here and be we will be continuing next week and maybe if you could have a look to uh give your opinion on those two.

A

D

And then we can, we can Killzone those, hopefully yeah.

F

um Are we going to be meeting twice next week or is it? Are we going to be doing Thursdays I, guess, I want to make sure that I I know uh in attending and so forth.

D

We said that at the beginning, I think that we're gonna try to meet twice so uh like Monday meeting time is still up and when we have a quorum we will kind of focus. We will uh basically go through comments on Monday too, but this Monday this month. It was just me on throughout. So we said there are two people, that's not enough. We kind of cancel I think then we have a quorum of at least three people. I think we will try to get some work done. Okay, great.

F

D

Okay thanks: everybody all right, see you next week then see you next week, Monday or Thursday.

F

Bye all right thanks.