APM monitoring model: the following section list of steps required for managing the problem in the application landscape.

• Collect response times by transaction and determine the first level alerting criterion. This is best achieved by using:
  • Passive agent that provides true end user performance.
  • Active agent that provides availability data.
• Understand and map all the components of the transaction. Several solutions are possible, but we believe that this model must be able to track each type of transaction, or each transaction, through the infrastructure, provide a template for debugging performance problems, and give full visibility into the transaction path. In addition, this dependency data should be available to improve the mapping of dependencies in a CMDB or CMS.
• Monitor applications built leveraging the Java EE and .Net frameworks.
• A connector is leveraged to collect performance data coming from mainframe-based transactions using IBM CICS/DB2 or IMS, messaging technologies such as WebSphere MQ or MQSeries between distributed systems and mainframes.
• Monitor packaged applications provided by vendors such as SAP, Oracle, or other ISVs, and custom applications not written in Java.
• Monitor the physical and virtual components of the infrastructure.
• Monitor performance of the database(s). This includes the ability to analyze specific database performance issues.
• Provide all this information on a single-pane-of-glass dashboard.
• Combine all these parameters, which leads to the ability to determine an alert, identify the root cause of this alert, and if possible predict an impending performance issue.