DX Application Performance Management

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?

Cheers

I can't spend a lot of time chiming in at the moment, so I will come back later and give a more detailed response.

For now, the best recommendation is never to instrument everything, except for development and testing.

Production monitoring should only consist of classes and method which are critical to the business process.

andfer we performed .NET instrumentation with "typical" settings. Also, if you have infrastructure monitoring (e.g. Spectrum or SCOM) then those tools are already monitoring your OS and Infrastructrure (h/w resources). We have Spectrum so I stopped and disabled the Introscope PerfMon agent altogether and focused on .NET agent only. There is a bit of an overhead running the PerfMon agent (which gets installed by default when you install .NET introscope agent). Our .NET agent is configured with "typical" setting with using "typical*.pbd" etc....

Even with typical settings, the agent provides a lot info on monitoring of .NET app and/or appserver. I don't think you need to created customized pbds at all. Deploy the OOTB agent and see what "typical" setting gives you. If that is not satisfactory then you can move forward with customizing the agent by adding your own pbds.

Cheers

Manish

Hi:

  Please let us know if the answers provided so far is helpful or you have some followup questions

Thanks

Hal German

Hey guys, thank you for the responses!

Yes, we are doing this on our dev environment for now. The thing is that we are actually trying to determine which classes are critical to the application/transactions, as there are lots of DLLs involved (also some 3rd frameworks).

We are basically doing a discover all, check what makes sense to monitor and skip all the rest, that for the custom part of it (frameworks, DLLs from other teams, etc), as there is no automatic instrumentation like the java agents. Besides that we are trying to keep the agent simple (using the typical pbl).

@Manish

Thanks for the tip on turning the perfmon off when it goes production mode

One last question is how we could reduce the number of metrics for the classes instrumented. We are using the BlamePointTracer but all we need at the moment is to monitor response times and keep those classes and methods showing on traces and errors tab (thats the blame part of it, right?).

andfer to reduce the # of metrics by focusing on "avg response times" only, you will probably need to turn off the other 4 standard metrics that are reported by the tracers within introscope agent:

>Responses Per Interval

• Application throughput

>Concurrent Invocations

• Number of transactions running simultaneously

>Stall Count

• Number of transactions running longer than 30 seconds

>Errors Per Interval

• Number of unhandled exceptions

If you disable those tracers then it will considerably reduce your metric footprint. But my recommendations is to NOT turn them all off. There are some good correlated metrics that can give you good insight to if one is causing issues to the other. But of course, the final decision is yours