AnsweredAssumed Answered

Instrumenting .net application

Question asked by andfer on Mar 30, 2016
Latest reply on Mar 31, 2016 by mparikh72

Hello all,


We want to improve visibility on the transaction traces for a .Net application. To get there we created a pbd like this:


- IdentifyMatchingClassesAs to identify all classes on our DLLs (using * for the classes e.g: [assemblyname]* )

- TraceAllMethodsIfFlagged to identify all methods from the classes on the DLLs

- And then we BlamePointTrace them


This has really improved visibility but generates A LOT of metrics for that agent (due to the blamepointtracer) and on the log we see that we are reaching 5000 components for a single trace.


How can we keep the visibility on the traces but not generate those extra metrics? (or maybe only show response time and keep the blame part of it for the traces and errors). I see that for java there is a BlamepointTracerLite but not for .Net...

Also, what would the best way to avoid reaching the 5000 limit? Start skipping classes that do not help us is our next step but we found it a bit hard to to identify the traces that are causing those log warnings.


What would be the right way to instrument an .Net application from scratch? Any extra tips on what we are doing?