Remote Services

This page describes the monitoring information available for remote services, also known as backends.  

What is a Remote Service?

A remote service is a process that resides outside of the application server and provides a service to the application. An example of a remote service is a web service, message queue, or caching server. 

Cisco AppDynamics automatically detects many common types of remote services when instrumented nodes make outbound requests. For more details on backend support by app agent type, refer to the supported environments page for your agent type under Install App Server Agents, such as Java Supported Environments. 

To monitor call performance to a service, first make sure it shows up in the remote services list, which you can access by clicking the Remote Services link in the Applications menu. If a service you expect to see listed does not appear in the list, make sure the backend detection configuration is configured appropriately for your environment, as described in Backend Detection Rules.

Monitoring Information for Remote Services

Cisco AppDynamics monitors the overall performance of calls to a remote service, as well as the performance of those calls from within specific business transactions. 

Metrics for remote services are presented in the Controller UI in the following locations:

• Business transaction metrics: The Transaction flow map shows the metrics for a specific business transaction for a specific service
• Tier metrics: The Tier flow map shows the metrics for all calls from a tier to the specified service
• Remote service metrics: The Application flow map and the Remote Services Dashboard show the overall remote service metrics across the application (all business transactions)

Remote Services Health Rules

You can create health rules to monitor the parameters that represent the normal or expected operations for your remote service. The parameters rely on metric values, for example, the average response time. When the performance of a remote service violates the conditions set by a health rule, a health rule is violated. Alerts notify you of any violation and initiate remediation actions to mitigate the violation event. It is important that you configure alerts appropriately to ensure that you do not miss any alerts or receive false alerts. Alert Sensitivity Tuning (AST) helps you configure alerts with appropriate sensitivity. AST provides historical data for the metric or the baseline being configured and hence helps you visualize the impact of the alerting configuration. To create a health rule to monitor remote service parameters and fine-tune the sensitivity of the health rule using AST, see Create a Health Rule and Fine-tune Metric Evaluation.

View Remote Service Performance on Flow Maps 

Remote services detected during the specified time window appear on the Application Dashboard flow map. You can view the detected services in the context of the entire application's transaction flow. The application flow map displays calls per minute and average response time for calls made to remote services. These metrics include all calls made from a specific tier to a service across all business transactions. The tier and node flow maps display the same metric in their respective contexts.

The detected remote services show up on the Tier dashboard flow map. You can view the detected services in the context of the traffic on this specific tier.  

For business transactions involving calls to remote services, the services appear on the Business Transaction dashboard flow map. You can view the detected services in the context of the traffic for this specific business transaction. The transaction flow map shows the average time spent in remote service calls for the business transaction. See Flow Maps.

View Discovered Remote Services

The Remote Services list shows all detected remote services along with key performance indicators. Services that are not active are removed after a configurable time period. See Stale Remote Service Removal.

From the Remote Services list, you can select a service and click View Dashboard to see the Remote Service Dashboard. The dashboard displays a Database Flow Map, backend properties, and graphs of the key performance indicators (KPIs). The properties indicate how the service is identified and determine how it shows in the flow map and how the metrics are aggregated. For a discussion of baselines and how they are used and configured, see Dynamic Baselines.

The Remote Services Dashboard has two tabs and an action option menu:

• Dashboard: Displays the flow map showing traffic from the calling tier to the remote service, the backend properties used for auto-detection and naming, and key performance indicators.
• Slowest Remote Services Calls: Lists up to ten calls to the service with the longest execution time, by tier and for all tiers. 

• From the Action menu, you can also rename a backend, delete a backend, or resolve a backend to a tier.

Slow Remote Service Calls

Cisco AppDynamics displays a list of the slowest remote service calls with call details. Click Troubleshoot > Slow Response Times > Slowest DB & Remote Service Calls tab to view specific call details and related business transaction snapshots that can help you to troubleshoot.

The Slowest DB & Remote Service Calls tab lists up to ten calls to a remote service with the longest execution time over the selected time frame, by tier and for all tiers, and relevant metrics. 

Max Time determines which calls are displayed in the Slowest DB & Remote Service Calls list. Max Time must exceed 50 ms before Cisco AppDynamics tracks the call as a potential candidate for this list. App agents aggregate and report call data to the Controller every 15 minutes.

If Query, Queue, or URL are not specified in the custom exit call, the details for the slowest service call will not be displayed.

Data Resolution and Retention

Depending on the period of time you're viewing in graphs, how old the data is, and the resolution of the data for slow remote service calls, graphs may display data at a granularity of 5 minutes, 1 hour, and 12 hours. The table below shows the data retention for each data resolution period.

For each day, there are two 12-hour data intervals [00:00 GMT, 12:00 GMT] and [12:00 GMT, 00:00 GMT].

For the data resolution and retention for other metrics in the Controller, see Metric Data Resolution over Time.