所以我通常理解像New Relic这样的.NET应用程序 – CLR Profiler API是非常有意义的。 但我不明白的是，AppDynamics是如何理解服务器和仪器之间的关系，而不是实际上基于.NET的东西..任何人都可以阐明这些东西如何在内部工作？
然后，您还可以进行非侵入式监控，帮助您通过录制的脚本主动执行应用程序，并监控响应时间，以获取有关问题和减速的警报。 这个空间中有许多APM工具（Gomez现在AppDynamics，Catchpoint，SolarWinds APM，Ipswitch APM等）。
如果您的Citrix或Microsoft托pipe环境将应用程序的映像传送到客户端UI，则应该使用实际的客户端连接UI查找具有图像识别function的脚本。 然后通过比较屏幕和testing脚本开发期间创build的基线响应图像来完成监视。 可能要看看http://www.tevron.com/load-testing-citratest-vu-load-testing-methodology.aspx
APM产品以不同的方式对每种语言进行testing，他们使用API（如性能分析API）的组合，并使用其他方法将代码注入到应用程序中。 这提供了各种指标，您可以观察应用程序的连接（入口点和出口点），以便确定应用程序是否连接到其他位置。 你也可以根据代码中的协议解码截取和存储诸如SQL或HTTP调用等。
现在到您的主要问题，AppDynamics如何工作。 如果他们这样做的话，每个APM工具都会有不同的做法。 Dynatrace和AppDynamics都有不同的跟踪模型。 每个方面都有好处和坏处。 AppDynamics将事务ID注入到协议负载中，这是以无害的方式完成的，但是下游连接（如果它具有代理）可以将该数据取回并将其关联到事务。 如果没有代理，它不会中断应用程序。 Dynatrace向上游收集器发送更多关于它踪迹的数据，这些收集器以不同的方式拼接在一起。 一个是分布式（高规模，但很难对协议进行逆向工程），另一个更容易缝合，但需要大量的处理和networking带宽。
APM监控正在使用来衡量响应时间。 我们都从第一手的经验中得知，没有什么比响应时间出乎意料的缓慢而让最终用户感到厌烦。 事实上，缓慢可能是一个比应用程序停机时间和不可用性更大的问题。 对电子商务网站的研究表明，减速发生的次数比停机次数多十倍，累计减速加起来是网上商店的底线的两倍。 这意味着确保您的应用程序正常运行非常重要，但这还不够。 除了基本的可用性监测之外，例如使用自动化软件testingIP协议和networking服务，一旦function发生故障或低于设定的阈值，就可以发出实时警报 – 对APM的综合方法应该采取一些额外的因素如上一节所述，以便帮助提高应用程序的总体可靠性和速度。 我知道使用Selenium的应用程序来检查这个响应时间，并在交易不正确时获取信息。