AppDynamics Application Intelligence Platform
Business metrics capture data from a method's parameters or return values to report on the performance of the business.
AppDynamics gathers business metrics using information points. Information points instrument methods in your application code outside the context of a particular business transaction and extract data from code. When the method configured for the information point is invoked, the information point metric is captured.
To access the Information Points List, in the left navigation pane click Analyze -> Information Points.
The Information Point List summarizes metrics for all the information points in an application. Business metrics show a value in the # of Custom Metrics column.
From the Information Points List you can:
Each information point has its own dashboard, which reports KPIs (average response time, load, and errors) for the information point, as well as any custom business metrics defined for the information point.
Business metrics appear in the Information Points tree of the Metric Browser.
Business metrics can be accessed from the AppDynamics REST API, just like any other metric. See To Copy the REST URL for a Metric.
You can configure snapshots to display information point invocations in call graphs by setting the enable-info-point-data-in-snapshots node property to true. By default the property is false. See App Agent Node Properties.
When the enable-info-point-data-in-snapshots node property is set, information point calls appear in the User Data section of the call graph.
You define an information point based on the class and method signature of the method being monitored. See Configure Business Metric Information Points.
You can use any parameter or return value of the method to generate a custom business metric across multiple business transactions. You can then create a custom health rule based on the performance of such a custom metric. See Health Rules.
Exceptions are expensive to create even in modern JVMs. If a particular exception is ignored but still happens often, it can contribute to a CPU spike in the JVMs. The metrics for ignored errors can provide insights into such situations.
In the above code the 'ServiceException' is not really fatal since the code has logic to handle it, so you may decide to add it to 'ignore' list. But if this exception is not truly an exceptional case and happens every time the code executes, having the metric for ignored errors will help you become aware of the additional overhead.