Open Telemetry Uncategorized, 11 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2023-01-11 meeting

Description

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

A

B

Hi welcome hey.

C

D

Okay, I think we can probably get started foreign.

D

Come on there it goes um I guess, I will add one right here actually and out next week. uh So for those that aren't already aware, I will be out uh next week. Mark is going to run the meeting in my absence so should expect still to have this meeting um but yeah just so. Anyone is aware, if you need something from me, uh try to get my attention on slack by the end of the week.

D

Okay, um the first thing I want to talk about. Is the release um not going to talk much about this because I already talked about it. Last week, I've been holding it a little bit to wait on the clock drift PR, which we'll talk about in a minute, um but once that clock drift, PR emerges, I was going to merge and release.

D

So this is uh just letting everybody know if there's a PR that you think should block the release or a bug or anything along those lines. This is uh your last last chance to uh request that the release is held for any particular issues.

D

E

Have questions on.

D

D

Okay, um next item here is the high resolution histogram support or the uh exponential histogram, depending on what you want to call it um again. We talked about all of this. The last couple of meetings, uh but the first part. The first PR has been approved by myself and Mark I was going to merge it, but I first wanted to make sure that uh nobody wanted me to hold it for their review or that Matt was okay with. Is it ready to be merged.

A

Yeah from my side, I think it's ready to be merged. I will need to um rebase and apply those changes to part two before part. Two is really ready to get into because there was um yeah. There were a few changes and some minor refactors that happened.

D

D

um I assume it doesn't fundamentally change the way that part two works or anything like that right.

A

No um it it just changes, some small details about how how we get the mappings I guess um and if anything it actually makes that a little nicer. So, okay.

D

Sounds good to me, then uh I will probably merge this uh after the release. Today, that's.

A

D

um So this is the pr that I have been holding the release, for um it is the fix for uh clock drift on a performance timer. uh It's been reviewed and approved by uh quite a few people at this point, uh most of which it looks like are green check. Marks um I wanted to uh uh give everybody one last chance to uh take a look at this if they, if they want to so I, was going to merge this this morning, but I figured I would wait for the meeting.

D

Is there anybody that feels like I should hold this PR until they review it? Or is everybody okay with me merging this when the meeting ends.

D

Okay, so I will plan on merging that when the meeting ends and then merging the release and cutting the release, uh there is a related PR uh to use date. Dot now in instruments.

D

um I would encourage people to review this PR uh it's similar in spirit, but it doesn't do uh nearly as much complex time logic, because the performance timer is not needed for durations in metrics. uh So it should be quite a bit simpler, but I would encourage people to please review that PR.

D

Oud um all right, one more PR that I want to encourage people to review is the eager exporting for the batch stand processor. uh This has been a little bit waiting for specification, uh but it's been kind of sitting for a while. uh The spec PR that it was waiting on is now uh more or less complete.

D

uh It's been reviewed by a lot of people I believe it will merge soon uh we're just finalizing some details actually with Amir here and it looks like uh Nev commented a couple of times uh so I have to go through those, but I expect that to be done soon. So the the pr for the implementation in JS is likely uh uh ready to be reviewed. I don't expect the spec PR to change in fundamental ways.

D

Anyone have questions on that.

D

D

um This next item is a PR. That's been around for quite a while. uh I have already uh talked about this in the past. Nothing's really changed here. uh I just want to make sure that the logs work is not going to stagnate. uh So I would encourage people to please review this PR. It's a fairly straightforward PR, um but I'm particularly interested in the reviews from people like Martin, who have worked on logs regularly.

D

I have not followed the log spec that closely in the last couple of weeks. Some changes there um so I'm going to defer to to those people as experts on this topic.

E

Yeah I can I can talk to that really quickly. um We we talked.

E

We discussed this during the client side, the client instrumentation sick this morning actually and uh there the events, the events API is still under discussion in the spec, um and so it's not clear if this is the direction that we want to go uh so I'm going to propose that we just close this APR for now um and focus on implementing the SDK instead, so we get that done and then we can revisit the API once once uh things settle in the spec.

E

um Okay, so I'm gonna, yeah I, know that this.

E

This yeah, this user also has a log uh log, SDK implementation that they were. They opened the pr in the past, so I want to sync with them also, but uh if you know we should you know if we should go with the one that I worked on or there's implementation, but we feel like it's more important right now to focus on the SDK okay, um I will I will comment on the pr and see what the user says.

D

E

D

Appreciate that.

D

uh It looks like somebody else added uh and related issue. Is this just the issue that you were talking about a minute ago.

C

I added that one yeah- this is the case with piggeron's, proposing basic changes to the the two definitions. So this is the part. That's still under discussion. That's causing issues.

D

When you say basic changes, do you mean basic like simple or basic, like fundamental.

C

Fundamental, like removing.

D

Okay, uh if that's the case, then I generally agree. I, don't want to thrash the API too much. uh um You know unless they they need I'm sure they need prototypes for the API as well, for the spec, but uh I I will defer to those that have paid more attention on this subject uh and I'll I'll follow the direction that you guys set.

D

Okay, um anything else before I move on here then.

D

Okay, um this next item uh has been around for a while um I wanted to talk about this. uh In particular, I made a suggestion uh a few days ago or a few weeks ago, I I think that we should consider removing the concept of the async resource entirely um I saw Amir. You commented earlier today that you don't necessarily agree there.

D

um I was hoping that we could discuss that a little bit. um Do you? Do you want me to start with my reasoning, or would you like to to talk no.

F

D

Ahead, go ahead, Okay, so, right now uh the SDK start is blocked by async resources. That's something this PR is trying to address.

D

um This PR is very complicated and complicates the implementations of every uh span processor. uh They have to know the internal implementation details of the resource async stuff in order to implement one uh and while reviewing this I was thinking that it would just be. It would certainly simplify the SDK if we just didn't have async resources.

D

If everything was synchronous, the SDK package, which uh you can start with just like the dash R flag and node, or one line change to instantiate the SDK, would be synchronous, and that would be that if you do need asynchronous attributes in your resources, you, as the application author, would be required to handle any asynchronous work before starting the SDK.

D

uh The biggest problem with this is that you would lose. You would not get any spans uh that start before the SDK is started, but actually in the current situation. It's already like that. You lose those spans because the SDK doesn't start until after the resources are resolved. Anyways.

D

um This PR does fix that problem. But uh there's a lot of complexity involved here, including when uh resources resolve asynchronously after other spans have already ended. Are they? Is it considered to be a change the resource, because resources are supposed to be immutable?

D

uh If you start the collection of two different resources and then they resolve in the opposite order, which one do you consider to be the new one and which one do you consider to be the old one, I think that is this is going to be handled. It has to be done in the spec I think this is just too complex.

F

It's already fixed in the pl I think like it's. uh No, it's implemented according to the spec. If you merge two resources, then the attributes are taken based on the order of the resources.

D

Yeah so I, my point was not that it can't be resolved in this PR. It's just that this really complicates the export pipeline uh in a way that I would prefer to avoid.

F

But then what will uh Lambda users do if they want to the classic resources and they can control the start of the application and also like a Frameworks like an sjs? Well, you are not deciding when the application starts it just the framework. Does it.

D

Does Nest JS start asynchronously I, don't think so.

F

I think it just starts. You don't have like the it's, not you stouting in sjs, you want like an sjs command and it just starts right. But but I think these are just examples, but uh it's I think users cannot always be expected to to be able to modify the code. To start like this, to to be able to resolve resources, asynchronously and only then start the application right.

A

F

D

Yeah I mean it makes sense. I just think that the asynchronous resource attributes is not the common case. The only the only one that I can think of that is definitely common. Is the Lambda uh uh whatever it's called function, ID, which is obviously not available uh until the uh first request.

F

Yeah yeah for sure, but uh if we want to give the experience of like uh an agent I could just um install the SDK, you don't have to change your code, then this will make it impossible right because you have to change how your code's doubts, if you're using async resources and this PR I agree that it's not clean. It's not it's complex things, but it will make it so people can just install the SDK and do no changes in the code at all, which I think a lot of users.

F

If you tell them to change things in the code, they will not do it.

D

The only people that would have to change things in our code would be people that have need of asynchronous attributes, which is Lambda essentially and I. Think that this is a problem that could be solved in the Lambda layer. You could, for example, have a uh Uh custom span processor, which takes an asynchronous resource and buffers all spans until it resolves and then exports, and then the SDK would still start synchronously.

F

Yeah, that's what the SPL is doing right. It's like it, postpones the resource uh to the processors and then the processors wait for the async data to arrive and then export you're saying we need like two different uh processors, one for same corners and one for asynchronous.

D

E

D

Saying that we wouldn't have cheering processors, the Lambda instrumentation layer would Implement a custom one that only handles that particular narrow use case.

D

F

D

Pr adds a lot of asynchronous handling all the way through the SDK in the the Tracer and the Tracer provider. That would be just a custom processor that the Lambda instrumentation would Implement and it would be included in the Lambda layer, and that would be it.

G

What would this be possible without the need of a custom resource implementation as well, um because you would kind of if, if all the resources are synchronous, then uh passing them through uh won't be possible? Right.

D

The startup resources would be synchronous and then taking Lambda as an example. They would have a Lambda processor which you know reaches out to you know whatever API. It needs to to get the the function. Id.

G

So that would be part of the processor. Then.

D

It would be part of the processor.

G

D

Right, I, don't think that's one one way that it could be solved for Lambda taking Lambda as a specific example, um I think, generally, most users don't have resources that need to resolve asynchronously.

F

Yeah but like everything that uses the like AWS resource, detector or gcp resource detector, they all rely on on a network request. Right and Lambda is just one example. But if you learning your application in like in ECR in ECS and you need asking resource detector, then you also need to use this span process. So right.

F

Like everyone that runs the application in the cloud and wants like a cloud attributes in the resource will need us Inc resource detectors, and then he has two options: either to add the resource attributes like later and then the the first spans will be with different results before it resolves, or they can change the code so that it postpones the starting of the application until the resource resolved.

F

So, like I, don't think it's only for Lambda. It will be for a lot of use cases.

A

F

C

F

I also I, don't like how complex it is, but uh I think like for years. People are talking about it and um how much it battles them and I think they will not stop. uh We have to find like a solution for this.

D

Yeah well, I think most of the people that are complaining are complaining that our existing SDK startup is which is in like the getting started guide and everything is asynchronous and most of those users, because they don't have asynchronous resources. They don't understand why the startup is asynchronous.

A

D

F

D

Of the complaints that I hear.

F

If I remember correctly like something like three years ago or the resource detector was sync and then people wanted the ability to to resolve them asynchronously because of Cloud vendors and attributes, and then we change them to be asynchronously right and if we change it back, then we will get the same problems that that we had before this change.

F

D

um Yeah I wish it was easier. I know what like some of the other languages do like in Java, for example, they just block the startup because they could do that and we can't.

F

I think new versions of node are able to do it right. You can await something in like the the global scope, and this will probably solve the the issue in the cleanest way, but I think it's not supported for a node 14.

D

Yeah, which means we can't depend on it until the year 2035 or something like that.

F

Yeah but once it will be supported, then we can simplify everything, because then users can just await the SDK start and that's it.

D

Okay, I think for now I'm convinced that we should continue with this PR um and we can reevaluate in the future. If uh the top level 08 becomes available enough that we can use it.

C

um So I haven't looked at the details, but it sounds like we can probably do both of what you're talking about so effectively change the start startup to be synchronous, but if it detects that a resource detector returns a promise, uh we have a hook into the processes to say, there's a an asynchronous detection that needs to happen. So all that happens then, under the covers, rather than saying you need to have. You need to install the the delayed span. Processor.

D

Yeah that that's what happens in this PR, uh the issue is that it then complicates every uh processor and every processor needs to be able to handle this sort of async uh use case.

D

C

D

I would encourage you to read the pr it is it's fairly complex and uh I. Don't know I uh it's solving a problem, so I don't want to use the word like unreasonable, but it seems unreasonably complicated for such a simple problem. But I that's the case in in many. That seems like just what programming is.

F

Yeah I do have some questions about it, which I would like to hear your opinions. um Look if you can jump to a the type CS file in the resource package.

A

And type CS.

F

Yes, so the changing the pr is now the detect function. Can we return a promise or a resource? I? Think it's a breaking change, but I'm not sure if, like what to do with it, because existing users can call the detect function and then do like a DOT, then on the result, and now it will break the code right.

D

Yeah, that would be for anyone using resource detectors, directly you're, saying.

F

Yeah, which is part of the stable package open television resource, so I I, think it's very unlikely that people are doing it, but it is possible and I'm not sure if we should introduce a new interface for the sync detector or not.

D

I think that we probably should yes, um foreign, that is a breaking change. I mean it's a very simple change, but it's breaking.

F

Yeah, so let's further complicates uh things and um also if you can go to the implementation of the merge function on the resource class, that's in the resourced. Yes,.

F

Two resources, but it assumes that they are both uh like a new resources and I think it is possible that one of them is new and one of them is like uh old right and then this function will not work.

F

I. Think right, because the user can use like a new resource detector and an old resources, and then it will try to merge those two resources and I think it will fail.

F

um So I'm not sure what to do with it.

D

You think it will fail. Yeah.

F

Because the merge function, the parameter for the other, it can be like a new resource and then everything will work as expected. But it can also be like a resource from an older version which we lack, the underscore sync attributes and underscore async attributes and and then the merge will not succeed because.

D

They don't exist yet.

F

Because, uh like the the other parameter can be an implementation of an old resource right.

D

Yeah it can I'm trying to figure out where these are created, shouldn't they be created at Construction.

F

Yeah yeah, they created the construction.

D

So then, why would it oh you're saying it the async attributes had not yet resolved.

F

um No, maybe someone is uh using um resource detectors like a new resource detector, with this API and like an old package. At the same time, right.

C

And then so it doesn't exist, it would be undefined.

D

Oh with an old yeah I, you don't mean old resource. Like previously created, you mean old in terms of all the instance, yeah yeah.

F

D

F

Yeah yeah, um so in this case the merge will not work. I. Think it's uh valid for users to do it's very unlikely, but uh I think it's valid and I'm not sure. If we can just not support it or because I don't think that there's a lot we can do to actually support it.

D

I mean we can detect whether it's the new or old, just by the existence of this sync attributes, probably.

F

Yeah in in this direction, we can but it's possible that the merge function will be called on. An old resource is this and the new resources other.

D

Then you would just lose the async attributes right.

F

Yeah so I don't think it's a very likely to happen or I'm, not sure. If it's a big deal, but the users May encounter it.

F

And there's not a lot, we can do I. Think.

D

I think there's not a lot. We can do there either.

D

D

D

Let's see it was read only attributes now it's a.

D

Defaults, replacing attributes.

D

There is no attributes property on the new one. Is there.

F

Yeah, actually, the constructo.

D

Well so this oh that's, default, never mind.

D

It's tough to find in the diff. Let me open.

F

Yeah, actually we don't have to do it now, just uh yeah.

D

It is definitely possible, um I was going to say we could log if uh uh attributes are.

D

Like if the attributes are red using the old method, I, don't even see how you get attributes out of.

F

Yeah it's in the Constructor, so in line 61 it starts with public, so it creates the property automatically.

D

So we could make that a getter and if the getter for attributes is called then and the asynchronous resources are not yet resolved, we could log a warning.

F

Yeah, that will work for One Direction if we're emerging a new resource and an old resources other, but the other direction. So.

D

If, because the the old uh implementation of merge gets the attributes, it calls like other dot attributes, and if that was a getter, and when you call it we could say have uh like um in the getter we could say if uh async attributes are not resolved, then log a warning and just returning synchronous funds. That's old school.

F

D

You still lose the attributes, but at least you get a warning.

F

Yeah and and I think it's very unlikely to happen, but just in case foreign.

F

Of resources and resource detectors yeah, but it sounds good.

D

D

Anything else before I move on to the next one here.

D

um Amir, can you comment on that PR just to make sure that the discussion we just had isn't lost.

F

Yeah yeah I will do it.

D

Okay, thank you. um Mark. Do you want to talk about the browser Packaging.

G

Yes, um in this PR on the uh on adding browser support for the author, B Proto export a uh stumbled upon this uh thing right here and I was just wondering if some uh uh people who are more familiar with it than than I am could chime in here.

G

um So basically, uh this adds support for uh yeah. Using this. This export and the browser and uh I think in this file right here we will need to include the esm and Es. Next builds uh build files in there and uh possibly also add the entry points as they are used by um a webpack I think to uh directly to the right one. We already have this uh browser field populated, but I think we might need um the the modular fields and such also populated to kind of make it work everywhere.

G

B

G

D

Okay, so files is missing. The esm build.

G

D

G

I think that may uh maybe an issue and maybe also missing uh module and uh what's the other one called I, think I already forgot uh es next I think uh for the entry points might also be needed for stuff like angular, uh but also read that but I'm not too familiar with it. So I can't really say for sure this is the last comment that would block me from approving the pr so I'm uh yeah kind of a bit lost at the moment. So if someone uh knows for sure, I would appreciate some help.

G

D

um I guess Nev is usually the person that I ask about packaging now. Do you have time to take a look at this.

C

Yeah I I heard this open I was going from the background. It's definitely missing the module on the es. Next. That needs to happen. um The mapping is already there for the browser definitions, I'm, not sure about the file, as I have to go. Look that up again.

D

Yeah I think it does need files um and then I think we should consider. uh Let's see, do I still have this documentation. Page open, yes, um I think we should consider across the board not as a part of this PR uh but uh adding the uh there is now an official specified uh way to add, uh like comma JS and Es modules uh to one package using the exports field of package.json, uh which we don't do in any packages.

D

So I think we should consider uh adding that across the board, but that would be a separate, uh separate issue in a separate PR.

G

um All right, thank you. um Yeah.

H

Yeah, so for for this PR, uh we we don't need any further changes right with with respect to you know this. This comment.

D

I think we do so I think at least you need. Let's see where did I go. I am open to many Windows here. I think you at least need to add uh modules and.

D

uh Yes, next to the package Json, so.

G

If you look at I think it's uh the files we agreed on right, um otherwise they won't be included in the npm package that we publish.

D

The files definitely needs to be done because they, yes, they won't be included in the npm package, but I think it also needs a module uh entry and an es next entry yeah and then it also needs the additional TS config files which are missing which generate the esm, builds because this is only only generating common JS build right. Now.

G

Aren't the uh created automatically now or am I if.

D

We look at another.

G

Clip indicus it's a magic, uh but it might be.

C

Wrong I think core has yeah core's got them all listed.

D

C

D

Core as an example uh right, there's, multiple uh Ts configs for each build and I think they're still required.

C

Yeah in the package, Jason Oracle uh typescript, the silver like PS complex, to build.

H

So this this additional uh modules in the uh the esm and Es next I, don't see them in all the packages, though, uh is there a particular reason there missing.

D

In browser supported packages right now,.

A

G

I'm sorry go ahead now.

H

uh Can you say that statement again Daniel, so it won't be like all three are not needed for the browser packages.

D

They are needed for browser packages, they're not needed for node only packages, I.

H

See: okay and then I'll add them here.

G

All right, um thank you, um I I, just wasn't sure about uh if I'm, what I'm remembering was correct. uh I I just remember breaking something at some point and it was kind of related to that. So I I just uh saw that in the pr.

D

Thanks for bringing that up.

D

um Nev more sandbox stuff, it looks like.

C

Yeah I had originally planned to get this ready for branching and start my minification stuff at the end of last year, but some internal stuff came up and pushed my my window out so I'm now uh hoping to restart this week, which means I, should hopefully hope, there's not a plan but I'm hoping by the end of next week.

C

um You know Maine will be ready and then then we can start the branching process and people can start contributing to the branches.

D

Okay, uh I am looking forward to that. uh Let me know if there's anything you need me to review or help out with uh yeah. You can find me on Slack.

D

um Okay, uh Santosh yeah yeah.

H

Could you open the link yeah so in the uh plant, instrumentation Sig uh nav me and a few others we came up with um you know this document. It's basically a listing uh the documentation on each of the events emitted uh I mean we plan to emit from the instrumentations for browser, um so I'm wondering what would be a good place to put this in, uh because this spec repo um there isn't a precedence to something like this.

H

As far as I know, tigran suggested to put this in the JS report, so I'm wondering if you have some thoughts on this.

D

Why what's different about it, that there's no precedent for it in the spec repo.

B

C

Which is why tigrant saying it shouldn't be in the spec repo, because.

C

uh You know generally, we wanted to find events, so there is a generic event shape um and then there will be different domains. So we'll have browser we'll have you know, probably Android, iOS, Etc and other clients, but yeah at this point, we've uh we've only really got the browser ones to find.

D

Okay, I would uh probably make the argument that this belongs in the spec. um It will likely share a lot in common with the other event. uh Specifications like Android I I have to assume I um obviously could be wrong about that.

D

um It is also possible to.

D

uh With with things like web assembly to run non-js in the web, uh I'm not aware of anyone running like the C uh SDK in the web, using webassembly or anything like that, but is entirely possible.

C

um Yeah you've got like Blazer, which is like G-Shock converts to JavaScript, so.

D

Yeah I I think that, uh right now the current situation is that the the de facto standard uh language of the web is Javascript, but I would not necessarily say that it's guaranteed to be that way uh forever or.

F

D

For you know, five years from now, 10 years from now, it's entirely possible that everybody will have moved over to using some other language. uh Even if JavaScript is used as the runtime, it would just be a compilation Target using webassembly or something like that. Okay, I'm, not saying I, think that's gonna happen, I, just it's possible um and I, don't think the JavaScript repo is like a browser.

D

Spec repo, it's just the JavaScript, API and SDK, which implement the spec uh I I would argue for this to be on the spec, uh okay, okay and as more and uh you know, uh uh real user monitoring topics come up in the future. I expect a lot of these events to overlap with uh things like Android things like iOS things like you know. If we buy applications.

D

H

Okay, okay, yeah.

D

That would be my argument: I'm I, if, if the TC says no and they want it to be in the JavaScript repo I won't reject it. uh But that's that's my initial thoughts on it.

H

Okay, yeah I think yeah. We can start with the spec repo and see what uh feedback yeah.

D

H

D

Other questions before we move.

H

On no uh that's it yeah thanks.

D

uh Cabinet help on PR yeah hi.

B

uh Yeah, this is uh just to remind you, like I I mentioned this last time last I mean before the on the last meeting on before in 2022. Like uh you, you I, don't know if you have seen it and I just want to remind you to just check into event.

D

Yeah so I did uh I, don't have any update on this since the last time I talked about it, um I was not able to reproduce this locally last time, but I have not spent significant time yet. um I will try to I. Probably can't promise today, but tomorrow uh we'll try to spend a little bit more time trying to reproduce this.

B

Okay, thank you.

D

um Yeah I I can try to get to it today, but I don't think I'll be able to, but I will I'll try to look into it tomorrow if I don't get to it today.

B

Okay, all right, thank you.

D

um Anyone else have a a topic before we move on to triage.

D

Okay, uh let's start with the main repo here, then periodic reader should collect and Export when flush is called uh I, believe there's already a yeah so currently being worked on at 35 17. So that's already linked.

D

um I think this is P2 and I will assign agendicus, since he wrong.

D

Since he is the one that made that PR.

D

And update to 34, using ES bill previously using 32 and to stop at 33, because 34 does not work with the S build.

D

Our Thrift files cannot be read, um I think this is probably related to.

D

uh When we switched to.

D

I, don't remember what version uh we switched to uh pre-compiling the protophiles into Js, um but it was somewhat recent and it might be related to this uh for now, I'll assign this to myself I'm going to leave the triage label until I figure out what is going on here.

D

um The last two are information requested, looks like that one's not updated, and this one for resolution, 3502, okay, okay, so I think that's good. For now,.

D

um And contrib.

D

Ute and QP lib, you loses baggage.

F

Yeah yeah, like it looks like you already found the issue and it's a small fix. I hope you will create a bill.

D

Oh, it's just the the instrumentation that needs to be updated.

F

Yeah just using the wrong context using a context active instead of parent context. Okay,.

D

So I will add a P2 to that I'll leave it unassigned for now until he responds.

D

I start up memory with instrumentation FS.

D

D

After disabling instrumentation FS, there might be a memory leak, I guess, update of Auto instrumentations. You know from 33 to 34.

D

Oh that's just when Fest was added.

F

Yeah I guess his application is just doing a lot of FS calls which creates like a storm of spins on stalked up.

D

um So what was the yeah problems in user apps, but not crashes?.

D

um I'm just gonna mark this as up for grabs since.

F

I'm not sure, what's the solution is because if his application starts like thousands of spends on when it begins, then what can we do about? It.

D

uh Well, we could look into the I I'm, not that familiar with the fs instrumentation, but there may be ways to optimize its uh memory. Use I, don't know how complex the fs instrumentation is.

D

Yeah um it there may be something in here: that's causing undue.

D

You know more memory, use than is required, it may be leaking or something like that.

D

um I'm really not sure.

D

I mean 200 to 600. Megs is a lot so if his application is only 200 Megs of memory to begin with and we're using 400 men, 400 Megs of memory just to store the traces from the file from the the fs calls said. You know the files are all in memory in the original application anyway, so we shouldn't be using more memory to trace them than they are.

F

D

F

F

D

I I wouldn't expect 400 Megs of memory in uh in spans, because even using the batch span, processor, the the maximum queue size would be hit. I, don't know what the default maximum queue size is.

D

I suspect there's something in the instrumentation where uh maybe the files are being held in memory or something like that. I'm not sure I, like I, said I'm not familiar with the instrumentation.

F

Maybe you can tell us how many spins are stouted and if the memory drops after some time or it stays High.

D

G

um It already says uh in in the what did you do up above that the memory uses usage went back to normal, so um it might actually just be like really really disabling. Oh sorry, oops should have should have read more carefully.

F

Yeah, it's it's actually not only files. It's tracing everything FS related.

F

D

Yeah I I think requesting a little bit more information is, is a good start here and we can. We can go from there.

D

Compare both when you're using okay.

D

Azure service bus does not propagate correctly to open Telemetry context. This seems similar to the amqp lab, always actually using the amqp live instrumentation.

D

So yeah it looks like Florida already commented and Mark already added the information requested label, so that should be okay, uh I think we're into Old. We talked about this last time right.

D

uh Yes, we did into older issues now so I think we're good and we're out of time anyway. So uh thank you, everybody for your time.

D

um I will not see you next week, uh but I will see you in two weeks.

F

I will not be here in two weeks.

D

H

See you in three then: okay, okay,.