Regarding .net instrumentation with the threading sensor Group - the "moveNext" method is spamming the purepaths with irrelevant information.
we are considering a globally exclude as this is part of a core sensor package, but - this might meddle with your behind-the-scene code injection.
any advice ? or recommendations?
Sorry about that Stefan - I didn't notice it was an internal link. Nice to see you again too. 🙂
Here's the suggestion:
MoveNext that I see is in the .NET Thread Tagging sensor pack, and it's
part of the System.Runtime.CompilerServices.IAsyncStateMachine class.
And while that sensor pack is placed in easyTravel, that method doesn't
show up (for me, anyhow) in the Deployed Sensors area. I'm having a hard
time seeing how that low-level method is required for stitching
together PurePaths. It almost seems like this is for something that is
being JIT compiled.
So as a SWAG: if we have to leave that method instrumented, perhaps enable Delegate Suppression on that sensor definition???"
I believe i got it to work simply by setting the "inheritance" to "this method" - where its default setting was "inherited methods"
now it could also be that some of the internal tagging is now off, could you possibly ask Development what the impact of meddling with this setting could have?.
By the way, i should probably also point out that i believe you're right regarding the JIT'ting - since this application is a heavy user of the .net EntityFramework. Which is known for dynamically generating code eg. JIT must to be part of its execution context.
Since i have you here Rob, i would like to raise the second issue we have with this - its also related to a sensor configuration running amok udklip.png
It is congesting the purepath overview, as you can see - its mostly irrelevant information. - some internal thread handling in .net. (of course it could be relevant in certain situations - however).
In some cases, we will have perhaps 10-20 of these nested scheduleandstart/executeentry, which Again is mostly irrelevant, and also serves to annoy users attempting to diagnose issues.
could it perhaps be possible to disable this?, or is this done by dynaTrace to track task handoffs from thread to thread - in which case, could we simply just choose to ignore it in the purepath data?
Yeah, changing the inheritance to "this method" could definitely cause problems since none of the specialized methods will now be instrumented. For this issue, and for the one with ExecuteEntry, we'll have to wait for someone who knows the code to weigh in. There is often magic in the system instrumentation; I would hate to suggest turning something off that was key to internal operations.
Just for the sake of it, to make it more official, ill create a support ticket as well. It seems like there is just something not right about how these purepaths are tagged/stitched.
Appreciate your insights on our issue 🙂
Let me know the SUPDT number and I'll follow the ticket. As you may recall my email is rob dot vollum at dynatrace.com
BTW, did my "suppress delegates" suggestion not work? I've been dying to know since the first time I made that suggestion, but the other person never replied. 🙂
added two pps with and without (same call) delegate suppression (see support ticket). and it does seem to look better, but the question still remains - if Theres some underlying technical reason to why it is as it is with the standard config.
I have the same issue with MoveNext() in .NET Thread Tagging sensor making my PurePaths very large. I can't see the ticket nor the solution. Can you post what you did to make this work? I'm concerned that one of our calls is timing because of the thread tagging sensor. Our app is a heavy user of async/await.