|
AppEnsure calls this new capability Proactive APM. Before this, APM was most useful once an app launched, delivered a poor end-user experience, and was flagged by New Relic. Proactive APM gives business managers, engineers, and testers a way to anticipate the end-user experience while the app is under development. It then simulated user load to real user load once the app launches. This allows for instant diagnoses when there are production issues, by comparing expected transaction times with potential issues. If you are already using New Relic, you’ll want to add AppEnsure Unified Test Platform to your app development and testing environment. AppEnsure Unified Test Platform is the first beginning-to-end test system which accurately drives 100% of the actual user interactions, even with complex HTML5 and AJAX client-side code. AppEnsure has had a monitoring capability to correlate resource – CPU, Network, Memory, and other aspects of performance – to app end-user experiences. Adding integration with New Relic helps surface and pinpoint app end-user performance issues and functional issues in Web apps, Ajax apps, Mobile (iOS/Android), and Oracle Forms apps more easily and more accurately. Proactive APM gives business managers, engineers, and testers a way to anticipate the end-user experience while the app is under development. The new features include: • Integrated New Relic Monitoring to App Server, DB Server, Load Balancer, Node.js Server • Quickly create Benchmarks to App Performance for DevOps and Engineers • Live Web-based Results, Drill Downs to Request/Response Level As The Tests Run • Analysis From Simulated Use Of Your App to CPU, Net, Memory, DB Query Analysis • Use New Relic Application Performance Management For Deeper Root Cause Analysis • 85 Reports from Results Repository for ?App Functional and Performance Analysis • Define Appvance Unified Test Platform Integration To Any New Relic Report • Select An App Transaction, see New Relic Report on Server, App, DB • Runs AWS Cloud, Private Grid datacenter, or Both • Compatible with Selenium, JMeter, Sahi, Appium, Java, PHP, Perl Tests • Data driven tests and analysis from live operational test data sources I first came upon the term Root cause analysis (RCA) while working at a network management start-up. The concept was to determine why a problem occurred so that repair could happen sooner and service restored. To do this required a discovery of the topology of a network and its devices in order to understand where a problem could occur and the relationship between the various parts. Monitoring was necessary in order to identify that a failure occurred and provide notification. However, the challenge in doing this was that many failure events are received in seemingly random order; thus, it is very difficult to differentiate which events signified symptoms of the problem and which event represented the actual cause. To resolve this, some solutions constructed elaborate causality chains in the hope you could follow them backwards in time to the "root-cause". This is akin to following smoke and having it lead you to the fire. Well it does work, if you do it fast enough and before the whole forest is in flames. The obvious next thing to do was apply this to applications. It certainly seemed like a good idea at the time but it turned out to be much harder than expected. Why harder? Applications are far more complex than networks with many more variations in behaviour and relationship. So, instead monitoring systems were applied to the various silos of application architecture such as web servers, application servers, middleware, databases and others.
Related Articles -
APM, Root cause analysis,
|
