So I generally understand how things like New Relic instrument a .NET app -- the CLR Profiler API makes perfect sense. But what I can't figure out is how things like AppDynamics understand correlations between servers and instrument things that aren't actually .NET based.. Can anyone shed some light on how these things work internally?
Then you also have non-intrusive monitoring that helps you proactively exercise your applications via recorded scripts and monitor response time to get alerted of problems and slow downs. Many APM tools in this space (Gomez now AppDynamics, Catchpoint, SolarWinds APM, Ipswitch APM, etc.).
If you have Citrix or Microsoft-hosted environment where an image of the application is delivered to the client UI, you should look for scripting with image recognition capabilities that uses the actual client connection UI. Then the monitoring is done by comparing the screen to baseline response images created during test script development. Might want to take a look at http://www.tevron.com/load-testing-citratest-vu-load-testing-methodology.aspx
APM products instrument each language differently, they use a combination of APIs (such as profiling APIs) and also injection of code into the app using other methods. This provides all kinds of metrics and you can observe the connections (entry point and exit point) of the application so you can determine if the application is connecting somewhere else. You can also intercept and store things like SQL or HTTP calls, etc based on your protocol decoding in the code.
Now to your main question, how does AppDynamics work. Each APM tool does this differently if they do this at all. Dynatrace and AppDynamics each have different models for tracing. Each has upsides and downsides. AppDynamics injects a transaction ID into the protocol payload, this is done in an innocuous way but the downstream connection if it has an agent can take that data and correlate it back to a transaction. If there is no agent it doesn't break the app. Dynatrace sends a lot more data about it's traces to an upstream collector which stitches the transaction together in a different manner. One is distributed (high scale, but difficult to reverse engineer the protocols) and the other is easier to stitch, but requires a lot of processing and network bandwidth.
APM monitoring is using to measure the response times. We all know from firsthand experience that nothing irks end users more than unexpectedly slow response times. In fact, slowness is arguably a bigger problem than application downtime and unavailability. Research on ecommerce websites shows that slowdowns occur ten times more often than outages, and those cumulative slowdowns add up to twice the impact to an online store’s bottom line. This means that ensuring that your application is up and running is important, but it’s not enough. In addition to basic availability monitoring—such as testing IP protocols and network services with automated software, which can issue real-time alerts as soon as functionality breaks down or dips below established thresholds—a comprehensive approach to APM should take a number of additional factors into consideration, as explained in the previous section, in order to help improve your application’s overall reliability and speed. I known applications using Selenium to check this response times and get information when the transaction is not correct.