Open Telemetry Uncategorized, 21 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-03-21 meeting

Description

cncf-opentelemetry meeting-2's Personal Meeting Room

A

B

C

B

Let's start in maybe another minute or I'm, not sure if sijo is gonna join.

C

True, it's a different kind of meaning when CJ's not here.

C

How do you uh pronounce your first name, uh you to cars, done you close, let's put Gosh Look cars. Thank you.

B

Cool um I guess you can start, uh am I.

C

B

You guys see my screen sure.

C

B

Okay, um so I've added the first item on the agenda yo and then there's another item. I see I I also see Seth Allen has joined us I'm, not sure if, like you've been joining meetings before like or exclusive.

D

No yeah, this is my first I uh wanted to see what what you guys chat through I've kind of followed lurked, the uh the me the agenda notes in the past.

B

So like would you like to give us like a little introduction of yourself like what you yeah absolutely yeah,.

D

Yeah I'm a product owner for observability platforms at navitare, so this will be challenging to spell, but uh navigation uh related is I, guess the idea, but Airline software we serve Airline clients, so about 50 of them. um So we are moving all our Tech into Azure cloud and instrumenting all their applications, which we've been dot net shop since Net10 um and I'm trying to help move us off proprietary logging patterns into open Telemetry.

D

So just looking to learn, all I can in terms of helping a few pilot teams that are walking through uh on our side, the instrumentation story, as well as my team, owning the uh managing of Auto collectors and so on. Getting all that data into a centralized via Splunk for the back in but yeah. That's me.

B

Cool awesome thanks.

B

um Sure I think let's get started with the agenda, then uh gender items so.

B

There's this PR on the contract, repo, uh which is now adding a sampler for the AWS x-ray extensions package.

B

So the main question I wanted to ask here was uh I think that editor has already yeah so I know: we've been discussing like what how we should name packages but I wanted to ask like uh what is our take on bundling up uh different components into a single package versus like having a separate package for each of the components like here in this case, I think AWS extensions previously used to have resource detector and propagator.

B

Now, there's a sampler getting added, and there are some other packages too, which will have like similar, which will come and fall into a similar situation where they have these different components related to that back end, and then you just wanna bundle them all together into a single packet. If you wanna like what should do, we want to have any general guidance here for the concrete component owners.

E

Well, I'll chime in since I opened that issue about package naming I, don't think, there's any hard and fast rules here, um especially as it applies, at least in my mind, to vendor uh specific kinds of things like AWS x-ray. You.

A

E

I think that folks, from AWS, uh or at least experts on AWS tooling, um should have a pretty strong say uh in terms of package naming and organization, and otherwise, um but that said in the general sense, like I, don't think it's a problem to have multiple types of SDK components in a single package um I for a lot of situations.

E

I think it makes sense for packages to be very like precise in what they what they contain and in the in that way, like that's, why I've suggested in the past that we'd be uh very descriptive in our package naming like if it only contains a resource detector like it's nice, to have that in the name um and then you know, we could follow that up with you know meta packages, if need be if it makes sense to like we haven't reach an example like that.

E

But if, in this specific case, like AWS x-ray has a whole bunch of of features that are closely related and should be used uh in order to best take advantage of AWS x-ray, then absolutely I think it.

A

E

I'm not the expert here, but if that's the case, then absolutely it makes sense to have just one package and maybe maybe it's just open Telemetry dot. Aws x-ray um is the package name again. I think that I'm still a little dubious of the term extensions, because I, don't I, think it just means so many different things um in so many different contexts. But um if other people feel strongly that that's very descriptive in this case, then you know I again know hard and fast rules. In my opinion,.

B

Okay, um by the way like the AWS x-ray component owner Prashant, has agreed to like, firstly, get rid of the word term content and also I. Think in one of the other PR's he had commented that we can drop like he's. Okay with dropping the X-ray part itself. So it's like he's favoring, uh open, telemetry.extensions, Dot AWS as the new package name, uh so that again becomes very generic, just extensions dot, AWS, but because I think when they started out, they were just like targeting x-ray.

B

But like that's what he had commented in that PR that now it targets a lot of other AWS offerings.

E

Remind me, is there there's another package and another AWS package.

B

E

Key rotation for the SDK right.

B

E

Yeah there's an.

B

Instrumentation AWS.

E

And then there's a Lambda package as well and.

B

There is these two and then there's Lambda.

A

Instrumentation.

E

Yeah sure so again, not not the expert in these areas, but like you're, for to provide them guidance. What is the wood in your mind, is the distinction here between having these is three packages versus just having like one Mega package for AWS stuff? Is there a? Is there even a reason to have three.

B

I I think in general, like instrumentation, packages have been like their own Standalone thing uh compared to like resource detectors and propagators select.

A

Two of these are instrumentation.

B

B

And this one has like uh now: it's going to have sampler as well, so it has the resource, detector and Sample, and maybe that's what they thought when they going with the different package for instrumentation or AWS, and this one.

E

Yeah just tossing out ideas here, um but extensions being kind of an overload term what about just like, since it has a whole bunch of different SDK extensions. It kind of seems like that's the point: how about open, telemetry.sdk extensions, dot, AWS.

B

Yeah I mean I think that's also making it very clear that that it's extending that these are SDA extensions. We can do that then then I think we should do like. We should probably have that guidance for every other component. That has extensions.

E

Yeah, if you open up that issue, that I have open I, think that, like the docker one I think is just a resource. Detector and I think the suggestion that uh We've tossed out there is um sorry I think it's in the main repo.

B

E

um I think the docker one uh The Proposal that's being floated is that it be called open, telemetry.resourcedetectors.docker.

E

F

That device that.

E

It's unlikely that there's going to be like you know, a sampler, that's Docker related or a propagator or whatever you.

F

Know um on the AWS one I've been talking to a fairly large customer. That's wanting to use um specifically the sqs stuff. Their argument was, they didn't want to bring in the Lambda stuff because they weren't using Lambda.

F

So the package was too big.

F

Don't know whether that's of relevance, but they asked me to specifically look into the whole AWS stuff, um so that would be an argument to split out Lambda differently from the resource detectors and differently from the X-ray exporter.

B

E

Where's, the sqs stuff. Currently we were talking about the AWS x-ray I. Think when that's what Irish was it's in that package? That's the problem. It's in the X-ray package, yeah.

F

There's a PR for that x-ray package, that's adding um the sqs stuff, which was the one that he was asking me about.

B

uh Yeah I think this is the one.

F

Yeah that one basically trying to roll it all into one big package um and it's just a bit of a mess at the moment, because they wanted to do some stuff with sqs and inbound in one package and then Lambda is outbound in another one and it was yeah. They didn't know what they were doing. Basically, um they didn't know which way which ones they were supposed to be using, um but that was a PR for both of them. I think both of the two repos.

E

I'm, just looking at the pr description, I haven't looked at this PR, but he doesn't reference. The X-ray package he's referencing the oh.

F

Is it the London this I know it was all over the place in terms of the instrumentation of it, um and they didn't really know what they were doing so we're asking for some clarity on it, but they've rolled their own at the moment.

F

But yeah that was because they they didn't want to bring in one big Mega package, foreign.

B

E

Yeah yeah, so the the docker one is basically just.

E

It was kind of an eye of trying to eliminate the word extension where, where possible and where it makes sense, you know again I'm not trying to make a hard and fast rule or suggest one but uh yeah. Even the AWS x-ray I had kind of a question mark again I'm, not the expert here.

A

E

X-Ray, really in order for it to operate, requires that you configure all those various SDK extensions, then in like that case, I think they all make sense, is the same package um and I think just like a general term like SDK extensions. Replacing those question marks probably makes sense if somebody more AWS informed, can kind of validate that.

F

It's really hard with AWS, um because SDK is so ingrained and not Hotel compatible.

F

It is a kind of special case really because it does spider into quite a few areas that it needs to make changes of.

F

um I wouldn't be an advocate for having that as the only package, um because there are separated bits like Lambda, which may or may not require x-ray.

E

You know I just asked that as a question I, don't think I, don't think merging the instrumentation makes sense. My understanding is that you know. Obviously the instrumentation is going to be usable by regardless of your back end, but my understanding of X-ray is that it's a back end, so it absolutely makes sense as a as a package, not mixed in with the instrumentation itself.

E

That said so so.

A

E

We're clear on that separation, the instrumentation not being part of that, because it's not today, so we don't even have that problem. The AWS x-ray package having you know, Samplers and propagators and and all that stuff. My understanding there is like, if you're, not using the correct, Samplers and propagators like you're, not going to actually like have like a good experience with AWS x-ray, and this is my very limited understanding so like I I.

E

Think in that sense, then, if, uh if we're just looking for like a good package name to describe that then I I guess my suggestions would be either a uh open, Telemetry, dot, AWS x-ray or open Telemetry dot, SDK extensions, Dot, AWS, I, guess I.

F

Mean would there be an argument to say that actually, this would be better as lots of individual packages and one meta package, foreign.

E

But again my limited understanding of AWS x-ray I don't know I've wanted somebody to tell me like if you don't use this. This is an assertion that I've heard and I don't know whether it's true but like, if you don't use the sampler and the propagator paired together, AWS x-ray won't work correctly like in that. In that way, I don't.

A

Think they should be.

E

Separate packages like you know, it makes sense that they'd come together, but I have no idea. Does anybody on the call? Would it no.

F

Would it be worth me bringing James Ethan on the call next week to discuss it? Is he someone from AWS um he's one of the lead solution, Architects on.net and serverless in AWS, and has been doing a lot with open Telemetry recently.

E

Yeah, if somebody if somebody right now joined our calls, that would be great.

F

And bring somebody on next week and discuss it, then, if that works.

E

Does that help you with karsh.

B

um I think if they could review that PR and then also like just put their suggestion in if they, if like, if they think it makes much more sense to like bundle them all together into a single package versus Because the actual component owners they they haven't been coming to the Sig meeting so like we would need that feedback to go there directly.

A

B

Mean I mean I think just commenting on the pr would be much more uh direct feedback.

F

um He said he'll um look at it, so I'll uh I'll see if I can grab in between now and next week and get some coherence.

A

F

He's the one to do it because he deals with all of this stuff um he's been doing a lot with all the aot stuff and.net as well.

B

C

I clear up some other questions we may have just generally speaking, it sounds like foreign.

F

Be the right answer.

B

Yeah um Alan I had another follow-up question to that um naming suggestion of.

A

B

I was thinking, opened, Elementary, dot, SDK or extensions make. It makes it much more clear, but uh that should be implicit right like because usually our packages are named, opened Elementary and open telemetry.api.

B

So if somebody has open Elementary API extensions, then naturally it would be open telemetry.api.extensions, but.

A

B

Just open telemetry.extensions, it should be like it's kind of implied that it's SDK extensions. Isn't it.

E

um Maybe I yeah not not really like. We have open Telemetry, Dot extensions, dot dependency injection, for example, which is like very much uh about it, being uh a library of extension methods, I guess in my mind, versus you know, extensions to our SDK.

E

Again, just to me it's about package names being as descriptive as possible about what they contain and extensions um in a lot of these cases, at least if you're looking at the current name in this in this table, doesn't well describe what it's what's inside, so like the top one like open, Telemetry extensions, dot, serial log, um it's probably better, named either instrumentation or like log appender or something extensions, is nebulous in that in that way. So, okay.

B

And another uh just another thing like this: one I think it when it started off it will it only had Samplers, but this might be extended to have other components again so uh yeah so I think like if, like I, think a lot of projects might just start with extensions and then keep adding other components to it like, instead of just having a soul, sampler or a resource detector,.

F

um I think it does need to be specific to that thing, though. So though the sampler with Azure monitor is that only ever going to be useful for Azure monitor.

B

I think so this is, do you know.

B

G

B

I know uh so the question is like this uh sampler that we have in Azure monitor that's only applicable to Azure, monitor right. Oh.

G

Yeah yeah, it's application. It's like specific example. Yep.

F

So you're going to use that in with a different back end,.

G

Technically you could um yeah I mean like it's possible to to use it with a different back end, but I'm not sure if, like how much uh sense that would make so this this. Basically, the the package is out there so that, like um the the Legacy not legacy the the old application, insights SDK has some sampling mechanism um so that we can have a compatible way of doing sampling in open television. That's the uh main idea behind this.

G

Eventually, we would just like go ahead and use the Samplers which are available in hotel uh spec, so.

F

It is, it is interesting, I think you've gotta give hit on something else about. Sometimes you need not just the back end or not just the front end of hotel to be edited. You might need the middle as well um or both I need to change the front end on the back end and put a bit in the middle. Maybe it's attributes you need to add um to each of the spans. Maybe it's a processor you need to add it could be all of them. I suppose.

G

uh Just uh something what would a bad effect, so you uh for that application inside Space sampler you will. There is something specific in the back end um that works that is dependent on the sampler. So even the sampling will work in like other backends, but I'm not sure how much the backends would be able to the other. Backends will be able to make out of it. So just just wanted to clarify that.

F

Maybe there is a different category: Alan.

E

F

E

To clarify something here, you were basically saying that, like this Azure monitor package.

A

B

E

Something other than Samplers um in the future is that right, yeah.

B

In future yeah so.

E

It's not really the case like again. This is a vendor specific package like again like it's up to you all uh from Microsoft. To, like you know, be the judge of what this name is best, but I would the guidance I guess that I or The Guiding questions I would ask is like.

E

Opentelemetry.Extensions.Azure monitor does the word extensions, bring any additional, meaning, that's helpful to you, or would you just consider something maybe like open, telemetry.azure, monitor.

G

um To me it is an extension because it's like even.

A

G

It just is a sampler right now it is extending the uh the functionality right in some way.

C

I think what uh sorry it's just kind of be on the outside. We had this conversation a little bit in my company, uh I followed the pattern of extensions and then my other lead devs were like. Why are we calling this extensions and it's like everything's extensions um so that to them they felt is important.

C

If we're going to use a name noun there or you know, description is more about signaling uh either it's native to the core or the library or it's something that is brought in by a third party or it's uh something we natively support.

C

uh They'll not be part of the core of the library, but it's not a third party contribution, but it's something the group supports in general. So, like the gamut, is those three groupings, that's what they kind of decided on and for us it was a totally different name. So not extensions. However, that sounds like kind of what you're after it's like. How do you signal to audiences uh what this library- and maybe you know, is it the native? Is it something third party?

C

Is it something first party or you know, supported, but not necessary for the core of the library to work.

D

Might add just from a end user perspective here, something I've been trying to find support on is how to get Azure monitor, specifically telemetry out through an Hotel collector over to our back end, and it's this to me could be um something that I would have looked at to figure that out, and it sounds like that's not relevant here. If the back end is implicitly up insights, maybe a misunderstanding, but we are trying to pursue that in the naming conventions to help or hinder, if they're, overly generic a degree.

F

I think that's a really good point, because, if I'm not using the export apart of the sampler but I do need attributes to be added so that I can actually send it through a collector I'd only be pulling that in and pulling part of the packaging.

F

If I understand what this Rush was um explaining on that, one and I wonder whether that translates to other vendors as well, where I might need my processor and my sampler, but I wouldn't need the exporter, and that would mean I wouldn't need to bring in specific sdks.

F

So would make this package smaller.

G

Or just different foreign.

G

Package itself is different, but as a monitor, so those are like all different packages. Even right now, I have a package out there, it's for resource detection um and which is following this naming convention so which is only doing the resource detection for azure, um so that that is what our current thinking is like we'll have different packages for extensions dot. Azure monitor yeah, like we started with that.

G

Initially thinking that it could have something else at this point, um I'm not sure if we're gonna have something else in it or not yet so this is still an open thing. You'll decide on our side, I guess.

E

C

Think it's ultimately.

E

A TL have the packages organized or you.

C

E

If it's multiple packages in The Meta package and what those package names are just as a point of contrast like you know, I work for New Relic, uh we.

A

E

And maybe we will again in the future, um have an open, telemetry.new, Relic uh package that has various extensions that make SDK extensions right that make um using open Telemetry with New Relic easier, and that package is just called open. Telemetry New, Relic I named that back in the day, um we've since deprecated that package, because it was just an exporter, but now we support otlp ingest natively, so we haven't had a reason to have folks use it, um but we may have additional extensions in the future right. That could be useful.

E

You know other than just exporters um and I'm I'm gonna at that point in time, if it happens, uh bring back the open, Telemetry, dot, New Relic package, and that's just what I'm going to name it. But that's um that's just my take. You know from my from from from the vendor that I work for, um but there is no right answers here.

A

In, in my opinion,.

F

I think as a massive package, I think that works, so the idea that it is for the vendor, removing all intermediary bits, makes sense to me from a if I was um doing this and saying right, open, Telemetry, dot, honeycomb! Well, that's what I use to do all of the honeycomb things.

F

Not an extensions, it's a rapper I mean we have our own and we go the opposite way. So we stick it under our namespace, so it's honeycomb.open telemetry, um but that's because obviously we don't want to stick it in the the contrib stuff.

F

um It makes more sense to us to do it ourselves and manage the release processes.

E

Right, we've done the same thing with like I: don't have the intention to bring the New Relic package into the contributory poker uh if again, if it ever comes back and we have a need for such a package, but I thought.

F

We were limited, um I thought the open Telemetry base was limited um to only being published from the hotel stuff.

F

Don't we own the namespace.

E

Oh right, I misspoke earlier our package is called New relic.open.

A

E

Open geometry.com.

F

That's that was the thing that was confusing me because I'm like well anything that's open, Telemetry or starts with open Telemetry should, in my opinion, be either core or contrib yep.

F

So I think what we're kind of trying to say, then, is that it should actually be Azure, monitor, dot, open, Telemetry, not the other way around and shouldn't live in contrib. If it's a meta package to make it easier to work with that particular vendor.

E

Yeah I, don't have a strong opinion there, there's other contribute repositories that have uh vendor specific stuff like The Collector, contribute repo and multiple language. Freebots have various artifacts that are vendor specific and, in my opinion, of the contributory bow. Maintainers are okay with that I, don't necessarily see a problem with that and if they want to use like the standard naming.

F

With the collector, though, the collector each one of those is an individual element, isn't it so it's a particular filter, it's a particular sorry, a particular processor, a particular receiver. There's not a this is for all of the things um which I think is what we're saying is what we're doing with some of these I suppose. The question is what happens in other repos other sdks versus The Collector.

E

That's what I'm saying there are.

F

A

E

That have say AWS components and probably Azure components too. I don't know.

F

Doesn't sound like it's an easy answer.

F

Extensions to me just seem just way too non-descript.

B

Okay, um yeah I think, like this guidance, is still good, like the naming guidance we can and ultimately we can have like we can just layer it up to we. We are going to do that anyway, like it's up to the component owner, whether they want to bundle the package together or not. Like I started this discussion with asking. If we want to have a guidance towards like bundling of different components into a single package or not, and that again it's best left to the component owner to decide how their packages would be used.

B

They would have a better idea of that.

B

Yeah and I think uh whenever this, whenever that PR comes out for dropping the contract for dropping the term contract from the AWS x-ray, we can I can like always go and comment there saying that maybe we can just get rid of the extension as well. They.

A

B

To uh work on renaming the package soon.

B

If there are no questions about this item, then we can move on to the next.

G

Yeah, that's me.

A

G

It might take some time um if no one else has any other topic. We can start with this.

F

So once I don't have anything.

G

Okay, um all right so just to give some background uh to the folks who might not be following this: um the PMS that I've been creating. um So there is a issue out there like. We are trying to add uh some metrics for the SDK internal events, um so that it would be helpful for users to see what went wrong or what?

G

What are the uh the general statistics for the SDK internal workings, um some of the very high level metrics that, at this point we are trying to add, is like, for example, uh the one that I'm I have added in. This PR is like how many um items from the badge export processor was dropped or um how many measurements was dropped, because um because the SDK reached the limit of 2000, uh distinct metric points. So things like this, we are trying to add.

G

um I, have an open PR already um with one way of like doing this. This is just like some implementation detail that we are trying to figure out at this point, um so the pr that I had was very specific, um so uh this one you want to go. Yeah I think yeah.

G

This is this, is the one I think, so so the idea, uh um so this the pr this uh that I have right now is uh the ideas taken from um like Ellen and Blanche uh from my other PR so like there were some comments on my other PR, where branch and Ellen shared some of the feedback they had and I took that feedback and implemented it here um so I now like after actually writing um some of the code I figured there are some.

A

G

Open questions that I wanted to understand and I wanted to clarify. So um basically the idea here is we will have an SDK Health reporter, uh which will be managing which will contain the the actual meter and the instruments to report those uh metrics on, and we will have a health reporter one Health reporter per provider. So, for example, we will have um for one Tracer provider. One meter.

A

G

And then the another one for the logs. um So that's that's the the summary behind this PR and uh now, if you scroll down because I think there's some discussion.

G

Yeah right here, yep so I think there was some uh naming uh suggestion from Ellen and uh plans as well. So basically so this this particular one is reporting. The number of items that are dropped by the batch uh export processor um Alan had a suggestion where he mentioned that we would. We could have like some standard prefix, so that we know uh with who is generating those metrics and at the like. Some of the one of the use case would be at the collector side.

G

It can be segregated so like for example.net.sdk DOT star, um each instrument uh will have that prefix and then we will have some uh like the specifics on uh following that, like, for example, patch processor, dot drop count or um measurements, dot drop count. Things like this um now, the the question that I had was like I think there's. If you scroll down I, don't think I have seen that yeah, um so Ellen uh I think, uh like the discussion uh that we were having over here is like.

G

If, if the the tags or the the dimensions uh go out of control, uh then we need to do something to you know, make sure that they are restricted.

G

um That's the part that I wanted to discuss a little bit more um because, as my mind is standing whenever we like, as in like uh the the metrics that are being emitted by the SDK, we know exactly what those are and I don't see an issue with that. So just wanted to clarify like um and I think Blanche also mentioned the same thing of for the dimension part uh so could either one of you like clarify. What were you uh referring to in that case like? How is that possible.

E

So I think one of the things that I'm assuming and maybe it's just a maybe it's a false assumption- is that one day um we may want this health reporter to be able to be used by custom components as well so like today, it's internal and whatever and I think that's great for for now, as we kind of continue to vet out this work.

E

um But let's say that in the future I create some sort of a custom batch processor or something right.

E

um Then exposing the ability to just have any arbitrary set of tags, and so on could mean that my metrics are different than those produced by the or the dimensions on. My metrics are different than those produced by like just the standard out of the box, SDK thanks, so that that was an assumption that I had and I I was just kind of suggesting that we we constrained that mainly as a means to just make it easy right for custom extension, authors to utilize, the the health.

A

E

In a standardized kind of way, I don't know whether that's nice or not, but I think it does ultimately uh um helps some of these potential explosions right again like if we're only using this for like internal things, then like yeah, we're in complete control like we're gonna, do our due diligence and make sure that's not a problem for our components.

G

um Got it um yeah I do have some thoughts on that one I'll go I. Think Seth has a question.

D

Yeah or just maybe comment on on along those lines, um so we're very focused on trying to provide uh end-to-end visibility of the pipeline of telemetry so from the instrumentation SDK all the way over to our Splunk back end and understanding where there are breakdowns, if any in the transmission of that Telemetry was on the end user working group last week with in Ted Young, he was saying as well that something he'd love to just see generally available across the entire pipeline. Experience's ability to see similarly end to end where there's challenges or integration problems.

D

When you set up a pipeline of telemetry, so starting in this kind of SDK, you know to see the health and understand if a certain package is failing or certain batch is dropping, and you know pull all those metrics into a common set of analysis tools alongside Hotel collector health and so on. So I I personally, do see a lot of value and agree that it would be helpful to have that in a consistent manner that um could be consumed for monitoring the pipeline of telemetry foreign.

G

Okay, uh thanks yep, so this is when you're, focusing on the the SDK component, so um uh but yeah I mean it would be helpful if it can like expand this to other components.

G

um So Ellen, just getting back to that, like so um taking the scenario that you have where, like you say, like somebody, has a custom implementation of uh batch right, um as per my understanding and I could be wrong uh to me. That's that's not something that falls under the SDK Health part, because that essentially means they change the SDK implementation itself. That's basically like I mean I would consider that separate from the SDK because they are not taking the out of the box SDK and they're doing something different um to it.

G

So in that case um my idea was to just you know like we can expose the the metric uh of the meter and they can create their own instruments and Report. However, they uh where they want, so that we don't like, restrict um the extension owners to kind of emit the metrics in only a particular way. If they want to do any any anything extra, they could just like create the instrument and just like report, their own metrics. uh That way um so like what do you think about that part?.

H

Current components have their own meter.

G

um They could yeah I mean if they want to have like the same.

G

um You know like same meter emitting the metric so that they can, you know like just separate it out, uh so maybe they want some uh metrics coming from rsdk, but then they also want to emit something extra uh which for their extension uh they could just create a new instrument and emit them using Hardware.

G

That's in future right right now, I I, like my plan, is not even to expose that meter. Also.

H

To me, it's kind of similar to like the event sources, so we have one in SDK, but we have one in basically every package, so I, don't I, don't see why they would need to share a meter. Every each package having its own meter just increases your options when it comes to selectively listening to things, you could always just listen to like open, Telemetry dot star to get them all right.

H

We don't need to solve this right now, I'm, just kind of throwing up my thumb, I.

G

See yep um makes sense, uh so yeah I mean like uh so just to close on this like. Should we go ahead and um like Ellen I mean? Are you okay? If we just keep the uh like, let the processors access the instrument directly rather than um what you have and then, if, if we think that this won't work, then we just like updated and make it the way.

G

As per your suggestion, or uh do you think that that might just like we, we will run into some issue or it will be like a lot of work to do it later.

E

Yeah I'm not opposed to uh to.

E

Moving forward with what you have and as we introduce more metrics, you know that may bring some clarity about.

A

If another approach makes more.

E

Sense but I um your your previous back to one of your previous points, which was, like you know, custom components being kind of outside of the SDK um I.

A

E

Agree with uh Mike that I mean if I have a custom component and I have all my own kind of metrics and so on.

E

Then I may, as well as just have my own meter and just like I can I can record whatever I want right, but again my assumption of some of this work going forward this health reporter work is that we are effectively like setting uh effectively can like sort of semantic conventions for for recording, SDK health, and uh that's why I kind of proposed sort of like an API so that even extension, authors right can conform to those those conventions much in the same way as like instrumentation authors conform to like the HTTP conventions.

E

You know just like making making an API that that's um that assists people again, I, don't think we need to solve that today, or you know, like necessarily think too hard on what that needs to look like in the end, especially because all of this is all internal, um but that's kind of where my mind is my mind is going if that kind of helps me understand kind of where I'm coming from with with some of these ideas.

G

I see nope uh that that that makes sense that makes JoJo sense uh branch. Do you have.

H

Yeah I'm just gonna, say vishwesh I would go with Alan's style, where he's exposing kind of a helper method and not the counter directly. Only because it's better separation of concerns that way the batch processor doesn't need to know about the implementation. It's just calling the helper and we've kind of encapsulated inside the SDK Health reporter the details of how that is managed. So if we ever wanted to switch it from the metrics API to something else, as unlikely as that is it's all in one spot, I kind of get. What I'm saying.

G

Yes, yeah, that makes total sense, yep, cool, um okay, so I have another one that I wanted to bring up. Dan has uh Andrews stuff.

I

Yeah I'm, just curious in general, do other sdks. Do this similar reporting of internal metrics I'm wondering if there's like an opportunity to have some consistency there with with some of the naming that exists.

E

I've, looked at that a little bit I've looked at Java, um they do have some health metrics, not this one in particular at least not that I could find so. I won't say that definitively um they have. Some I was looking at their otlp exporter and they have a number of uh metrics that they record um on export about things that are drop, truncated whatever um and their their names are totally their own today, but I think to Seth's Point earlier. I would not surprise me if this became a larger like Community conversation.

E

Maybe there will be. You know, conventions around some of these metrics. It's not that! Maybe we wouldn't have you know some that are specific to like the.net SDK, but I'd. Imagine that there may be some standardization across sdks um at some point.

I

A

I

Of these also seem similar to the metrics that the actual collector itself generates, um I I think it's I think it would be overall helpful if those aligned somewhat because it doesn't require you to like change your perspective depending on what workflow you're sort of troubleshooting, uh but maybe maybe something for the future.

E

G

um Ellen you had suggested like we have like a provider id as a dimension right.

G

um Instead, I was passing it like in our instructions so that we can construct where we can maintain the ID um yeah right here. Yep, um if you don't do that, like I, think Branch mentioned that uh and I was thinking about that. Like I tried to update this, but before I. Do that, like I, wanted to make sure we uh we have the common understanding.

G

um So your suggestion is to just like use the ID as a dimension and uh and not include that in the instrument. Name. Is this what you are getting to, or you also wanted to be like the name of the included in the name of the instrument.

E

um No I think the my suggestion here is that the provider id is best served as a dimension. I think it's weird to have like uh metric names have a variable component.

C

E

um So that's why I suggested being a dimension, um I think there's another discussion here: bishwesh about provider id you know you and I spoke briefly on slack last week, yep um my you know: we've been kind of talking amongst ourselves and thinking that this provider, id concept uh is useful and I think it is, um but I think you pointed out that it does make this kind of cumbersome in a way.

A

E

That, like in the future, so right now, you're working on batch export processor dropped count. But in the future you know you were. You were going to work on like the the metric cardinality uh limits reached and that stuff resides in the aggregator store, which is not a publicly like visible uh component, um which means that the provider is going to need to be passed down to like all of these internal components, which might be kind of a pain in the ass honestly.

E

um But I think that that's a that needs to be balanced with, like the value of this provider id um and knowing knowing it I'm I'm curious to hear other people's thoughts.

H

In the case of the metric limits, the provider id will be that of the meter provider so like what we see on the screenline 23 I would just set that provider id to a private field so that the SDK Health reporter instance, which lives on the parent provider basically has the idea ID of the provider that it is bound to so that into aggregate store will just pass the instance of SDK Health reporter. So it can do like you know, this.healthreporter.record drop metric, and then it has that provider id to add as a dimension.

H

Does that make sense? That's.

E

That's exactly what I'm that's exactly what I'm saying is that, like every single internal component, like aggregator, store you're going to have to pass down an instance of this SDK Health reporter, which is, unlike you know, like events.

H

Or you just ask the like parent provider and you get it all hit, but yeah yeah.

E

One way or another, you're gonna have to pass something down to be able to get that information, um which is unlike say like our Event Source stuff, which is all static. You know it has. You can call it from anywhere.

G

So uh I also had like I was thinking about it a little bit more like. How often is that case, and we have like multiple providers.

H

I think multiple providers is less likely than like multiple exporters, yeah.

G

H

Or multiple batch processors.

G

um So yeah, so, like think about that case, do we really need the provider id.

H

You mean for like the meter provider, yeah.

G

Like, for example, in this, what I have right now, it will be like Tracer provider dot one or something like that right. Do we really need that like because it's a batch export processor dropped, count, I? Think it's given it's coming from the Tracer provider. Now, if having multiple trace of providers, is not a very common scenario um but having the batch export processor is.

G

Could we just do some like internal count in the batch export processor itself and add it as a dimension um rather than adding the provider id into all of this extra work?.

E

I don't know if I have a strong opinion yet, but I I can think of like cases where it might be helpful, like I, think one that I cited in the past was like, if I have two two Tracer providers again, which we're presuming is maybe not a very common scenario, but if I did and like I had one provider that sampled one way because I was you know exporting Trace data to like some local source and then I had another one that was exporting data to say Microsoft.

E

um It would be useful to be able to facet my metrics based off of those two two scenarios.

G

So that means I will have the batch export processor gown type like the magic sport processor will still have some unique number in there.

E

I'm not sure I.

A

E

Does that help distinguish between the the two pipelines effectively.

G

um Well, actually like even now, it's one and two, it's not right, like you could still figure out which, when the providers once batch export processor was added in the pipeline.

G

H

I'm just gonna share that the batch export processor is also used in logging and I think it will be way more common in the logging world to have multiple logger providers or longer factories where you're logging, some things you know to cheap storage and high volume and you're logging high priority stuff somewhere more expensive. So just something to keep in mind when you think about this provider id is, we will also use it in logs. Presumably at some point, thank you.

E

I think metrics is going to be common too. You know people.

A

E

Be exporting to Prometheus and then also to some other uh back end um I. Think it's a pretty common setup.

B

I have a few questions here: I'll just like. If you're going to maintain an ID for provider, then within a provider you have to maintain the numbering or the ID identification for the different instances of batch export process that it will have right.

H

And you kind of need, like provider id and component ID.

B

Yeah because, like if you have a let's say, single Tracer provider, which has two batch export processors, then, like you, need a way to distinguish between the dropped count of these two right, either through the metric name or dimensions.

G

So basically, like batch export processor, one batch expert processor, two, something like that: yeah um yeah, that's, that is what I was saying, but I was suggesting like we don't have the provider at all. um Just have that yeah.

B

I think your suggestion was like, like the default thing, which would be just Tracer provider and then, if there are other instances of credit provider than you do like at least provided one or like two or something like.

G

That this is my current PR. Yes,.

B

A

G

I think we are running out of time, but um yeah. Maybe we need to discuss this little bit more.

B

um Yeah and for metrics I think we discussed this a bit last time like I, don't know if, like if it's completely safe to uh to like use our own Matrix SDK to like keep to for troubleshooting of our own Matrix SDK like use the same thing to diagnose it. Yeah.

H

I'm, a little worried about in the the metric limit strain stuff you're in the middle of an update call. So if we add or we take a metric inside of a metric update, is that safe I don't know we need to? We need to check that out. We.

B

Could like create a new meter listener, or something and not.

B

And also I think here we would need another dimension for three so long, because this okay, I haven't looked at the PR, but I. Don't know if, like there's a way to distinguish between yes.

G

So that provider id is will be something like okay,.

G

And like meet a provider dot one, something like that.

B

That's not super easy to consume right like it's. The from the metric name like how do I know if this was for a log, batch export processor or a trace process.

G

um We will have additional Dimensions uh from the batch export processor, which will be like the the type will be there. The type will be log record or activity and also the exporter name, um so those will be additional Dimensions yeah thanks. You guys.

B

Just one quick thing: do we want to add Hotel here in the naming convention.

B

Or it's from the meat- oh it's probably coming from the meter. So that thing that should be.

B

Yeah I think all of the backends actually store the meter name. So maybe it's a good idea to have that in the magic name itself. um Yes,.

G

Yeah um I think we can yeah. We can definitely trade on the names. It should be quickly. Changeable, Just, One, Last Question, um we're already out of time, but the static part. So then, if if we are putting the provider id as a dimension, then this whole thing can be made static. Right, like we don't have to.

E

If we decide, we don't want the provider id then yeah I mean then this becomes very much like Event Source. You can just call this thing statically and you don't need to have that Constructor at all.

H

If you do decide to keep the vishwish better I think to have the class and keep that value on the class, then forcing everybody that's going to call it to have it and pass it in. Does that make sense.

G

um Yeah yeah because it's very big it's going to be the cumbersome if I like do the provider id on each processor like I, have to check if the processor is batch, export, processor and then sending set the provider id on the processor and I was trying that last night and it didn't look very nice.

H

We might want to consider like would a user want to have their own control of that ID? Like a name, you know like log, you know primary log, backup or whatever I feel like yes, but I, don't know it's just a wild guess, yeah.

G

I think this, the one that I have is more ex like expandable. In future, we could like allow the users provide the provider id um if they want to, but yeah okay, I think I'll keep it for now. I'll just go ahead with it. I'll address the comments and then, if we think about something else, um we can interact over it. Let me work on that.

G

um We'll follow up on the pr itself. Thank.

A

G

Much guys this was had fun.

B

All right thanks.

E

Everyone yeah thanks, y'all good work.