Open Telemetry Uncategorized, 10 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2022-11-10 meeting

Description

cncf-opentelemetry@cncf.io's Personal Meeting Room

A

Good morning, John.

B

C

Zoom looks different.

C

D

Hey John, hey Trask, hello,.

B

It's probably different because I'm actually at the meeting, that's what's different foreign.

A

Let's prioritize here.

A

D

Yeah we got a full agenda today. We've got to be conscious of time all of a sudden.

C

A

Okay, go ahead, check and move anything that is priority above the this is the cut line here: okay,.

D

Well, the first topic is uh about the Java 1.20.0 release. um I, don't think, there's there's any uh critical PR's that are open. The two that I've linked here are nice to have um you know, they've been open for some time and uh I think they're they're, pretty solid myself, so John. If you have a a chance to look at those, um please do and we can make a decision on whether to merge them or not.

D

uh Trask, the the one about the test utilities, the new assertions for search a it- would be good if you could take a look at that, because that addresses an issue that you originally opened.

C

C

E

A

um Okay, so that's on schedule for tomorrow yep all right.

A

um So let's chat, um instrumentation release.

C

A

I will talk more. The next item is to talk about the GMX metric Insight, because hoping um to be able to get include this in the release.

A

A

Else that is oh, this one Jack would.

C

Yeah for your thoughts, I.

D

Don't think we should merge that unless until the spec is merged, you know there's some debate going on about whether it's duration or time, and um so, let's, let that play out, sounds good.

C

I will and Milestone it.

A

All right! Well, if there's, if anybody um thinks of anything that they are, would really like to be in the next release um ping, either on the pr um or Slack.

F

And just notice one of the later items about open some natural resources- I mean the new Java agent, I, think uh I. Think we haven't replaced uh the old SDK package in the Java agent yet which we should do so. We are actually publishing a new SDK Library instrumentation for resources from instrumentation repo, but the Java agent still uses the old duplicated one.

G

D

I, don't I'm not sure, that's the I, don't think that's the case, because um so there's um I posted another issue in here. That I think relates to this uh yeah. The.

A

D

Yeah, the shading one so yeah. If you look at that, the um you know: I I debug this on my machine and let's see what was the ultimate class I had to use.

D

I had to use IO open, Telemetry, Java agent, shaded instrumentation.

A

D

Well, this didn't work. The configuration the poster included didn't work. So if you scroll down to my comment here, you can see the configuration that actually works.

F

Yeah this okay I understand the original, but uh are we even including this in the in the division, I'm kind of surprised.

D

F

D

Including something we're, including one of them and I, believe it's the one, that's uh uh you know in the instrumentation Repository.

F

Oh yeah I see okay yeah, we are including it and uh okay. uh I was under the impression that we were not including it because I prepared a separate, uh gradual plugin for this kind of SDK extensions. It was not it's not used for this particular module, but it's it's just like being included uh like hard-coded in the Java agent, build file so yeah okay, never mind, then.

D

Okay, but then so the question, while we're on the subject, I think we should probably talk about whether we should shade that or not um so I think you know shading it reduces it. Has you know, ergonomic implications on people that want to exclude those resource providers because they have to be aware of how we change the packages, um so I'm inclined to not shade it.

D

Are there any reasons not to do that to keep it shaded.

C

A

It should be able to live in the because it's only the SDK, um it should be able to live in the agent class loader, which would mean it should be able to be unshaded.

A

We only have to shade things when we put them in the bootstrap class loader.

A

D

D

So I'd say that's probably an action item we should take before 1.20.

D

And then you know should be clear about that in the in the release. Notes, I can I can take a look at this and you know try to open a PR to to stop shading it. If folks are busy.

A

um Cool, if you go for it um otherwise yeah. If you get uh uh into circular loops with all the shading and Shadow stuff, uh uh kick it over uh yeah it can. It can sometimes about one out of every five times it works smoothly.

D

Maybe I should leave this for more practice. Dance.

A

Will coordinate okay.

C

A

Okay, so that is yes for 120., okay,.

A

um So, let's go on to the jmx metric inside, um so I would uh I think it would be good to get this merged for 120 um I. Think to start getting some user feedback on it.

A

um I think user feedback would outweigh. We could definitely keep reviewing it like um there's a lot of levels of detail that um uh you know that we haven't gone into, but um I think the feature as a whole and the structure seem uh like a good first cut.

A

um So first wanted to. You know just kind of put out there that if anybody can or wants to um take a look to review it, the other thing is um whether we should more clearly Market as experimental.

A

um For the uh config args and we have had a practice in place of marking things that aren't of configuration items that aren't specked as experimental.

A

um We even mentioned it in our sort of stability, versioning dock, um but I was noticing. We have missed I. Think we've missed it in a couple places recently.

A

um I don't know if we want to say well if it's instrumentation specific, it doesn't maybe need experimental in it. It does make. This would make this incredibly long.

A

And then there was this one also, um oh,.

C

A

You are that oh yeah.

A

um Where we're introducing.

A

um These, which also haven't inspect so I, don't know if these should be experimental, marked experimental or not.

F

The HTTP 1 haven't been inspected either so like almost all of instrumentation configs, if not all those ones.

A

But oh those ones that somebody opened a spec PR, but it didn't get merged. Yeah, okay,.

F

I think that the spec has avoided uh adding instrumentation specific configuration. Until now, there is only SDK drinks.

D

And there's been talks about uh accommodating instrumentation configuration in the file based configuration format.

D

But yeah that's going to be some time.

D

I think maybe so is it clear that all the if it's clear that all the instrumentation specific configuration options are subject to change like if we make that clear in the documentation, then we can probably continue the pattern that we've already been doing, because there's I think there's a number of options that are available, probably on the order of five to ten different options. So you know, is this a big enough reason to rock the boat.

D

D

Experimental in there you know we'd probably want to continue the pattern that we've been doing and then in a separate change, add experimental to all the the variables so that they're consistent but I'm, probably not in favor of doing that.

C

A

Okay with documenting it clarifying.

F

You know we tested that experimental to every single property which would make kind of using digivization to really convert someone, because you would have to prefix everything with total experimental, instrumentation and then the actual stuff foreign.

A

Yeah I was looking at um like as kind of a mix like this does not have experimental.

C

um Oh yeah, these ones don't, but these do.

A

Yeah I mean that maybe maybe that's an open question, should we remove experimental everywhere and just make it clear that all config options are subject to change at this point.

F

I think it would make sense it would make the config also a bit simpler.

A

Saw a couple of heads nodding as I scroll through there's, so many people here.

C

A

A

um Okay, I I, like that, any any thoughts sort of against doing that.

C

All right, um I'll I, will take that.

A

um So back to then Jim Max metrics, so then would don't need to prefix it with experimental and yeah. So just um you know anybody who's interested, um especially I, would say um really. If, um if there's one thing to review, um it is the doc.

A

um So this top first DOC here um describes, you know the feature, and this is um I, think the you know the implementation details are less important than it's a big new feature and so sort of you know from a usability and documentation perspective um extra eyes on this. One document would be great.

A

All right, um yeah.

C

And I saw Emily's here, yay yeah.

H

A

Hey um I had a question because I had a user ask this um about they're using micro profile, metrics like from uh wildfly 26 I, think, um and they want to know how to if they can get that into well. If the Java agent could pick that up, um so I was wondering if there's a way already to get those funneled to either micrometer or open Telemetry metrics API. Today.

H

Yeah, it's a actually it's a very good timing on the upcoming micro Matrix 5.0, basically is a brilliant micrometer. So, basically uh like the implementation, although the specs are done in the enforce, you have to use a macro meter. However, the apis is refactored, so basically it's um basically, it works really well. With macro meter like at a momento like open Liberty, we have the implementation, basically using macron video in the background, so it's the The Matrix coming out is pretty much the the conform to the micrometer The Matrix format.

H

So it's always uh I know. Jonas is here as well. Micrometer Works has the same with the Oto Matrix right, so.

A

Yeah, so is that something users is there an extra library that users put on their path to get in 5-0 to have it use micrometer.

H

So for using micrometer like Autobox, you should be able to do so. It's basically it's a the. For example. If someone using open Liberty macro profile, metrics 5.0, so it's a macrometer was shaped in open Liberty, so it's uh they shouldn't need to do anything.

I

But you also need to choose the Irish history.

H

Rights uh choose what the.

I

United States, you want to use. Oh.

H

Yeah yeah you need to plug in that.

I

Yeah, that's very that's where you can plug in uh open Telemetry as well, so either you plug in the OT appear registry of micrometer or you can just plug in the auto SDK vtd micrometer Bridge.

E

I

That should depend on the open SDK, so hopefully just one extra dependency that you need to bring in which you should bring in a dependency anyways.

H

I

H

Good use use case, I think it's uh yeah, I will feedback and to say, maybe we could come up with a Blog and demonstrate I think we need.

E

H

Try it out, we need to try it out. Yeah.

A

Awesome yeah, if you have a link to also um where does the work on this micro micro profile metrics take place. What.

H

Yeah I'll give you a link: the micro profile, metrics.

C

A

H

No problem I will put on the minutes anyway,.

A

um ah I put this on here um because of things I learned from Jonathan, but since he's here, uh would you mind sharing.

I

uh So uh the observation API is like a new edition in micrometer 1.10. It was released on Monday, thank you and what it does. It basically gives you like one set of tools that you can use to instrument your components and after you did, that it actually can delegate uh these. These calls to like other set of tools and to make this a little bit concrete.

I

Is that the observation API looks like like starting and stopping a timer or starting and stopping a span, and you can also attaching our store handlers and, if you, for example, attach a matrix reseller that can create a timer for you.

I

If you like, start and stop an observation, if you attach a Spam listener, that thing can create a span, a start and stop a span when you start and stop an observation, and also you can do other things like attaching like metadata like text or attributes, signaling errors and so on, and this new set of apis.

I

This will be used in Spring framework, 6 and spring boost 3 and across the spring portfolio and right now, what it does is we are providing to uh listeners, and one of them will be like a micrometer meter listener which will create new, a micrometer, timer, actually more timers, but doesn't matter and the other one will be like a micrometer tracing this, which will create you, uh like micrometer, Trace expense, which later can be delegated, for example, to open, telemetric tracing. We have a bridge for that.

I

That's the same thing as what we have today for suit. It's the same code Base by the way, it's just like what we pasted.

A

Foreign yeah, so this sounded to me and the impact on that. It could have a really big impact on all of our spring instrumentation in open, telemetry, um potentially starting with spring framework. Six, that we could basically potentially rewrite all of our spring instrumentation as just these listeners on the top of the spring observability API um and um basically let now it sounds like spring framework and the spring projects are going to are essentially instrumenting their their code. uh Making appropriate calls there and we can just listen.

D

What kind of information is available to those listeners is? Do we have enough of the metadata to populate required uh attributes for semantic conventions.

I

Yeah, so uh you will get uh so if you have a observation, uh it has a backing, object, called the observation context and you can put like arbitrary metadata into that. It's basically a hashman uh and also it has uh like it- has like special kind of metadata that you can attach, for example, attributes, and you can Define if it is a low, cardinality or high potential attribute, so you can choose like which one you want to use in your metrics and in your stance, because for your spans, you want to attach everything for Matrix.

I

You don't necessarily want to attach High character that you have to use. uh Also, you can signal errors. So if there is an error happen during the during the execution and you instrumented that piece of code, then you can just say hey, there is never happened during this observation and The Listener will get it as well, so that it connects accordingly.

I

If you have a couple of samples- and uh we have a documentation about this as well, you can you can take a look. There are. There are examples and uh also a car.

I

Yeah, you can, you can check those there in the samples and also in the in the uh in detox too, and also the the implementation like you can check what the micrometer uh implementation for, like such listeners.

G

So a few questions, if you love me so this observation, observability API, is inside micrometer. It's not specific for spring right.

I

Yes, it is micrometer, it has nothing to do with spring. Micrometer doesn't have any spring dependencies correct. Oh.

A

And if I can clarify that question, um my understanding was the spring observability API is not related to micrometer. It is a low level API inside of spring. So.

I

There is, there is no spring acceptability API spring observability. It is kind of like an effort. We did this year, which was uh like one one thing for this was coming up with the observation API, which belongs to my Twitter: it's not in Spring, and the other one was basically instrumenting what we already instrumented, but twice like we had the instrumentation with micrometer, and we had the instrumentation of this sprinklers tools.

I

They basically like put these two things together and instrumented this spring framework and all of these spring projects response with the observation API, and then we can get like multiple benefits out of it. So yeah. If you want to use the observation API that doesn't have anything uh like uh speak specific. It is just pure micrometer. We just like uh publishing a new uh artifact made and Central called micrometer observation.

A

I see, but it doesn't pull in all of micrometer. It's just it's branded as micrometer observation API. It.

I

So it doesn't pull in all micrometer in a sense that, for example, if you want to use it's basically an API layer, and it has some like implementation as well, for the uh uh 40 basic building blocks. But, for example, if you want implementation for the listeners for those you need to bring in, for example, micrometer tracing, because that will contain that implementation or micrometer core. That will contain the the other implementation like four metrics, so yeah.

I

uh If you, if you check it out my limited observation, API or the multimeter observation artifact, it should be fairly small.

G

So Jonathan, let me let me try to condensate what this does um so. Basically, this is observation. Api is more or less to give the equivalent for the instrumentation apis that we have for tracing and from metrics on open telemetry, but then in a unified way. So you just instrument uh one library in one spot and you have both capabilities tracing and metrics. Yes, okay,.

I

Or everything else that you can think of like uh introvert is your roster. You can add, like audit logging or whatever login, that hey somebody started like an observation or somebody stopped it or, like you can only react. Tornado said: hey, like an error happened during the observation or you can like emit like events and write them into a data store.

I

It can be applied for anything we are just like providing you default, implementations for micrometer, metrics and micrometer tracing.

G

Okay, so this kind of sits on top of the existing open, Telemetry apis and it's they are kind of a utility API for to handle things.

I

So no so this is this has nothing to do with open parametric by default. Yes, but uh but you can, you can write like uh open, Telemetry listeners if you want, but uh if you are using, if you want to use, for example, open Telemetry uh tracing, you can do it as of today, because micrometer tracing has a breach to open telemetically. Open Telemetry is one of the tracing libraries that we support. So it is just like getting two jars and you are good to go.

I

Okay well, actually checking one.

A

Well and I think in the future, though, we would probably in open Telemetry implement, provide our own handlers, observation listeners.

C

um To go directly.

A

um Instead of you know having to go through the the bridge, Bridges.

A

But the yeah, so my um this seems like a very low level, like almost like an event: API like a low level event API um and um since it's small and has um assuming it has no dependencies um that, because all the spring libraries are gonna have are now Jonathan, taking a hard dependency on this right.

I

A spring framework will have a heart dependency on it, uh which means that uh everything in in the spring portfolio will have.

A

Well, um this next one was kind of also um something um from um uh discussion with Jonathan that um so right, we've been struggling um over time of what is sort of the future of uh the spring boot starter occur. Oh look at this fancy new GitHub UI.

A

Spring right, our Auto configure story, um and so they in Spring boot Auto configure in the actual spring boot. They have some Auto configure for micrometer tracing that you can plug in like open, Telemetry exporter, open Telemetry and open telemetry exporters, um but they don't yet have really a configuration story for those um sort of, like we've, been we've defined over here of how to auto, configure that open Telemetry exporters through the spring yaml.

A

So today, basically, it's just very basic and users have to provide their own Tracer provider beams or span exporter beings um to get wired up. But it sounds like all of this stuff could be. This configuration story um could be upstreamed into boot itself, as Auto configure beans. So if the you know conditional on these, the user bringing in these classes and then both that could benefit the micrometer tracing configuration as well as we could, then we could use that.

A

I

Okay, I'm just right now we are the only thing that we are actually two things that you are Auto. Configuring is a Zipkin, a t16 exporter and uh we are also Auto configuring uh Bayfront. But that's like a VMware product.

A

Cool yeah I just wanted to kind of get um the not that we need to, or will um do this necessarily soon, but um as something to kind of think about for the long-term direction of the spring. Boot starters. If we I think we would probably continue to have like a lightweight spring boot starter in our in for just open, Telemetry directly, as opposed to going through micrometer tracing. But the more that we can share. Upstream um could help.

I

Also, just a quick FYI I put I placed like two links in two deducts. uh One is pointing to the micrometer observation chart, so you can see the dependencies and the other one is uh basically the uh the documentation.

A

Okay, all these other ones are options.

I

Yes, everything is optional, except as common.

F

Speaking of that spring, with starter, uh even if we were to have like a very lightweight implementation of that we would, it would still need some effort to make it usable, like even the starters. We have right now, doesn't fully Implement all the SDK configuration that we support in general. It's like very basic. So uh honestly.

F

My opinion is that, if possible, we should Upstream everything this thing um and maybe provide some kind of implementation. Module like if spring hosts all the interfaces. We could just provide an implementation that sets it up with open Telemetry and that's it, but uh nothing more than that.

A

How do you do strike through? What's the key edit strike, uh there's got to be a it's.

C

D

Shift X I'm, not a control.

F

D

Depending on, if you key swap yeah I'm I have mine swapped as well.

I

Also, it should be in format, I guess, for format, options.

I

Maybe yeah and on the text, I guess.

A

Thank you. Yes, like your Control Alt shift, five wow I'm, not gonna,.

I

Run yeah! Good luck! If you get it I.

A

Didn't expect that.

D

That is not what it is for. My key bindings I, don't know how that's different for you than me. Yeah.

C

C

A

Right, yes, I agreement.

A

Yeah and what's cool with the making it basically Auto configure of like the SDK? Is that really does benefit the that's the same for gonna, be for micrometer tracing users who are using they're going to have the exact same, want the exact same configuration options for configuring, the underlying Hotel SDK, okay,.

A

um Let us prioritize not me and Jack.

A

E

I

Just noticed this, uh if that speak, I, guess uh that uh the documentation says that if I put the peer service attributes on a span, that should mean that the zip can remove. Service name is set, but it seems it is not.

D

Yeah right there's a this is just not implemented, so um we should open an issue for this and do this.

I

And just give you the like the idea: where is it important? If you are not selling this and, for example, you are like cooling, great I, don't know like a database uh MySQL, which is uh like most of it, I'm, not instrumented. So if you're not send uh like uh stands to see, pin as it can, you show these pants as it would be emitted by the application, and if you set the remote service, then it will, they will appear appear as it would be emitted by the database so yeah.

I

This is a really nice touch from the from visit team UI uh was they are doing for like Leaf spans. uh The whole thing like looks way better. uh If, if you set this.

A

Is this something that's clear to you, Jonathan, where the fix would go or.

I

I am not sure if, if you are asking, if I am open to like uh opening a PR, yes, I can open up VR.

D

I I can take a look.

D

The link that I included is is the relevant place. That's where the transformation takes place from uh the open, Telemetry span, data to zipkin's representation, and so there's a there's. A set around here called remote endpoint um that we don't set and we could easily set it and extract the value from peer name.

E

I

All right, just a very, very quick question out of curiosity: I'm, not 100 sure, but uh does OTL, because the same notion, if you moved in the local endpoint uh for a protocol.

D

It's just defined in semantic conventions, so the peer name is uh okay. That's.

I

That's that's good enough. Yes, that's good enough for me yeah that basically means that yeah, whoever will process those uh expense uh in the otlp format. They can have that information yeah. Thank you.

A

Yeah and you're right, like uh in our exporter, we have you, know backends, have kind of similar Concepts, so we map peer service to whatever our back end. Once.

I

I I just asked this, because I saw back ends uh that doesn't have this concept, and uh the network called to them is only like who sent that Network code, and there is. It is not that information is missing, who is receiving, which is uh quite important in some cases.

A

E

A

um So you had a topic here: um asking: is it possible for others to implement otel Java apis? Yes,.

B

So this is this: topic has come up in the past and the answer is really there. Is it's not possible to write a tck because there's no specification for precisely what would happen in a back end and the only way to test this thing. This stuff is to verify it with a back end like if you're implementing apis with a completely different SDK.

B

We can't say what that SDK should or shouldn't do so. It's not possible to write a tck.

H

I see so basically is some people came up and like um physically saying, if it is no possible for other implementations, it shouldn't be in code. That is back because there's uh and there's no multiple implementations, because the API is a just come up with one info seriously is not API per se. Well,.

B

You can certainly implement the SDK, implement the apis to do whatever you want. There's nothing.

E

B

Implementation, for example, that just turns everything into a log rather than than doing anything else, so it is a valid API and we have two SDK implementations. One of them is the no op implementation that does nothing and that's a completely valid implementation as well, um but our full SDK that you know supports Jaeger and Zipkin and uh Prometheus and otlp. That is also a full implementation.

B

um So if what you want is a tck for that that I guess the question be, why do you need to implement it? Implement it differently? We already have one, um but if I think that would be a very large project to build a tck that was kind of needed to implement Jaeger, Zipkin, Prometheus and otlp, uh because those are the things that are in the spec, so I'm not sure what a tck would really mean. In this case,.

H

Yeah, so so actually so this is a just like because we discussed this in the micro profile group is is someone else came up, is saying. Basically, this is saying: okay, it's so bad I can't even have a tck. So basically it's done yeah. So your answer is is because it's too complicated right if they don't foresee any other people.

I

B

Guess what spec are you talking about? You're talking about the SDK spec or the API.

H

Talking about uh STK talking about the API API is bad, so.

B

What would you, what would you verify with an implementation of the API.

E

B

Not a complexity issue, it's literally a question of what would you validate.

A

Well, here's a thought is like there is a no op API right.

B

A

That is a perfectly valid API according to the open, Telemetry spec.

A

C

There's really.

A

The API is it's just a sync, a data sync right, you put data in so as long as you're, conforming to the signatures. There's you can do anything you want and it's valid.

D

And there might be one more thing too, which is that you don't throw unexpected runtime exceptions, um because I think the the API does specify that certain methods shouldn't throw. So um that's not explicit anywhere. But maybe you could write a tck that just validated that, for a variety of conditions, no exceptions were thrown um I'm, not sure how valuable that would be so.

H

Basically, so basically you can do whatever you want. As long as you generate a data you, you want right or.

D

No data at all that's valid.

H

Too, oh, no, oh there's no point! No differential.

G

I had to follow the Protocol, no.

B

That's not true at all. That's definitely not true like, for example, if you disable otlp in your SDK and you just have Jaeger and Prometheus, that's a completely valid implementation and it generates no otlp whatsoever.

G

But that's after the exporter.

B

I mean otlp is only at the exporter level. There is no otlp inside the SDK.

G

I was trying to remember some diagrams where I saw something between the well receiver and something else.

A

So there is a spec for the otlp exporter right and you could design a tck for the open. The otlp exporter, like John's point, is that that's a separate component from what we call the open Telemetry SDK, which is a separate component from what we call the open, Telemetry API.

G

Which has a scope, much larger.

A

um Which? Which one.

G

A

Yeah, probably the SDK has the largest scope, but it's it's side by side with the exporter, I mean there's a contract between I guess it defines some contract for the exporter, but nothing there's nothing. Otlp specific in the SDK spec.

G

H

So it's a SD case back and together always is um St SDK implementation right, the API I I I, don't have a computer at home, so is it I can't remember the API is in one one, one gr right: it's a new one, Maven coordinate and then the SDK uh is separately or is it oh yeah, okay, but uh basically SDK is kind of the is the one used in the real production environment.

H

D

H

Dedicated it's.

D

The most common implementation of the API we expect most people to use it yeah.

H

Okay, yeah, that's fine, so Bruno and I will try to yeah talk this through yeah. Thank you. Can.

G

You explain: can you explain this in probably some other words like the the open element spec, it's kind of the definition of what the uh apis that we have in Java need to conform to and because I do we have a specification that says exactly what the the sdks need to do. I need to behave, yeah.

D

That's in the specification as well.

B

But but I should say it's a separate specification from the API and it.

E

Is the specification.

B

For what we call the open telemetry like the standard implementation of the API okay, but the API and the SDK are two separate specifications. The SDK specification is, as I said, it's the specification for the standard implementation that we provide. You could consider the reference implementation, but I think it's a bit bit more than that, like it's intended to really be like. If you, if you like the standard wire formats, Prometheus Zipkin, Jaeger, otlp, uh I, probably left one out, um then it's it should be 100 production usable.

B

So it's a little bit more than just a reference implementation, um but we like open Telemetry, has no stance on whether people provide completely separate implementations of the SDK. They do completely different things.

B

um I know that at least one vendor I can't remember who has, for example, an implementation of the SDK which is streaming. It doesn't do the export in the way that that any of the current SDK exporters do it does a streaming back end that sends that uh for everything that is, that happens to a back end and that's a completely different implementation of the SDK completely valid.

G

And on the side of all these, in Java, specifically, we still create the instrumentation API, which is a totally different API from all all this.

A

Yep yeah the instrumentation API um does not. There is no spec for that.

A

um We there was anorak had opened the Otep at one point to attempt to gather like cross language support for such a thing um and I think at a high level, there's support for what the instrumentation API provides, which is sort of a uh one one place where you can create both spans and metrics, for example.

A

um But beyond that there was no agreement cross-language at this point.

F

Okay, somebody even pointed out the different languages will have different patterns of implementing such a thing, so uh yeah I mean, in my opinion the instrumentation API should be just an implementation of the somatic conventions so that it's easy for instrumentation authors to correctly incremental pathometric conventions. It's.

D

Syntactic sugar yeah.

F

A

F

B

Going to say it's semantic.

A

Sugar, but that's.

F

On the plumbing code,.

G

Yeah, that explanation is quite simple and easy to understand: can it implementation aismatic conventions, okay,.

A

And importantly, it's yeah: it's syntactic semantic sugar on top of the open telemetry apis, so it doesn't really like. You can still swap out the open Telemetry sdks under the hood um and the open, Telemetry API is still valid.

G

A

Cool does that um uh Emily? Does that answer what you need for now.

C

A

um Yeah uh Jack, we.

D

Talked about that already earlier, so we can skip that.

A

D

A

Scope attributes yeah.

D

So bad attributes um there is a PR that I've had open for a long time to add, extend the uh the meter Builder Tracer Builder and log ger Builder apis to allow you to set scope attributes.

D

um You know what are scope attributes. We should probably talk about that. First um and I'll include a link in the notes.

D

There we go. Thank you. Trask.

D

So the relevant section is this: so an instrumentation scope is some scope of code that produces uh you know, instrumentation uh the most. The the only required field on a scope is its name. We commonly use a class name or a package name in Java for that um or something akin to that, and a scope can also have a version and a schema URL uh recently. The most recent addition to his scope was that they can now have attributes, um and so this last paragraph describes what scope attributes mean.

D

So uh an example is you know? Maybe you include an attribute representing the the git repository URL uh of that of that library that is being instrumented or some other things.

D

So um uh the pr that I have open adds the ability to set these scope attributes when you're, creating your meters, tracers or loggers, and it's been open for a while, and the question is whether we should actually do anything with it, because we don't actually have any concrete uses for scope, attributes today, they're part of the spec so and they're not going anywhere they're a stable part of the spec. But uh you know it doesn't seem quite right to to add API surface area without uh without a without demand.

D

So the question for the folks on this call is: does anyone have a use case for this type of concept, or should we put it on hold until such a use case arises.

A

Well, it looks I mean with this was I was just looking over this. The event domain is currently proposed as a scope attribute, I. Think.

D

It is, but this is a special exception, because it's supposed to manifest as a scope attribute by the time it gets to um the data model, but you don't actually have to have a Setter on your logger builder in order to set that, because the API for logs has a special Setters that explicitly sets the event domain. So you don't need to set at scope attributes just for this field, so this use case goes away and in fact, there's some conversations going on right now to move event domain down to the log record level.

D

Instead of as a scope attribute too so that that entire conversation is kind of not really relevant.

E

F

I want to have a version of instrumentation scope as as an attribute.

D

Well, the version of the instrumentation is the top level field, so scope is primarily defined by its name, its version and then a schema URL. So.

C

Three versions explicit.

D

B

I mean you could imagine wanting to put an author, for example, into your instrumentation scope, attributes or, like you said, or a a git repository where this, where the source code lives or something like that. My my concern is less the increase of the surface area and more the fact that nobody really understands a use case for this and putting a method on our Tracer meter. Logger builders that just says set attribute leaves like it open, like everyone's going to be like well. What the heck are these attributes for? What's going on here?

B

What and I think it's going to lead to confusion and and more user support unless we can provide motivation and provide a name for it. That is very clear to what it does um and I think. The thing that's confusing is that we build this scope without calling it a scope in our building. Tracer Builders right, we like say here's the instrumentation name, the version or whatever the fields are anymore schema, but we don't ever call it a scope.

D

Yeah the name scope emerged after the apis were already in place and.

C

D

That doesn't appear in in the method names so.

B

What if, instead of adding this method, called set attributes what, if we had a method that said, was called set scope with a scope, object that had that stuff? Bundled up that, if you wanted to provide the full scope, you could do that or you. We have the helper methods that we already have there like the syntactic sugar methods. That would give you the pieces of the scope.

B

So what do you think about that idea about literally calling it set instrumentation scope or whatever you want to call it um on the Builder, so that it was very clear that the stuff that was going into that instrumentation scope was all related to the instrumentation scope rather than having kind of these things dangling off the top of the the Builder one.

D

Thing that's strange about that is that that opens up the possibility to overwrite the name and the version and the schema URL that you've previously defined of.

B

Course, yeah, obviously, and so this would be a very rare I mean it'd, be very rare that people want to do this anyway, right I mean the most common use case literally is open telemetry.getracer with a name right like like people, I think very few people accept Instagram like deep instrumentation authors care about this level of things. So I think that it's I think that with careful documentation there we can just say like hey. If you set scope after you set these other things, you're gonna wipe out what you already did an.

D

Alternate an alternative to that same design is at the top level, so you can get a tracer with its name right now. What if you could get a tracer with its instrumentation scope, yeah.

B

Yeah yeah, you pass the.

D

Whole thing up top and then there's no sort of ambiguity about what's going to overwrite what.

B

No I think that'd be I, think that would be an excellent alternative.

A

I gotta Play Time cop yep yeah me too. Thank.

D

You I took on this conversation, take.

B

A

C

A

See everyone see.

C