As businesses are undergoing digital transformation and the application complexity is exploding, many companies are moving their applications and services to the cloud or leveraging web services from third-parties whose core competency is their service. Increasingly enterprise applications are consuming third-party web services, however, they do not usually have direct control nor visibility into those services.
In the AppDynamics Winter ‘16 (4.2) release, we introduced a new Service Availability Monitoring (SAM) solution to help our customers track the availability and essential performance metrics for HTTP services that are not natively monitored with an AppDynamics agent.
In this blog, I will provide some additional details on the use cases and configuration of Service Availability Monitoring for our APM customers.
Check availability of web services not initially monitored by AppDynamics
Although AppDynamics provides visibility into applications and web services written in the most popular languages including Java, .NET, Node.js, PHP, Python and C/C++, there are still many packaged software and third-party applications that we don’t manage natively.
The new Service Availability Monitoring solution, which runs as an add-on to the Server Visibility module of AppDynamics Application Intelligence Platform, can help check the availability and responsiveness of those applications with an HTTP interface.
Inside-out view of external web services from the datacenter
There are many synthetic monitoring solutions out there (including AppDynamics Synthetic Monitoring), which can check the availability of any web page or service from different places in the world. However, in many cases when enterprise applications and web services consume and depend on external web services, then it’s important to get an inside-out view of the availability and responsiveness of those external web services.
With Service Availability Monitoring, AppDynamics helps customers to get this inside out view of external web services previously undetected.
Easy configuration for Service Availability Monitoring
Configuring a service for availability monitoring is pretty easy by entering (a minimum) of the following 3 values in the main tab:
- Name – Name of your choice for this target configuration. This name appears in the Service Availability list.
- Target – The resource to be monitored, for example, http://externalWebService.com Specify which HTTP method to use to send the request (GET, POST, HEAD). Default is GET
- Server – Select the name of the server from a drop-down list of servers on which Server Monitoring is licensed and enabled.
There are various advanced configurations that can be done on the main tab, but a default value is selected for all of them.
Fig 1: Service Availability Monitoring Configuration
To complete the basic configuration for server availability checks, you need to set at least one validation rule under the “Response Validators” tab. You can provide a list of rules to validate whether the monitored service is healthy. If any rule is violated, the response is considered failed.
For each rule, you can specify an HTTP property (e.g. Status Code), an operator (e.g. equals), and a value (e.g. 200). The list of operators varies depending on the property selected in the first drop-down list.
Optionally, in the “Request Configuration” tab, you can define a list of customized headers to send with requests. For example, the list can mimic desktop or mobile browsers. You can also define a request body for POST requests.
Once a service is configured for monitoring, the Server Monitoring Agent (or Machine Agent), checks the service according to the configuration, evaluating the response against your specified validation rules. When a validation rule is violated for a response, the response is categorized as a failed response. If no rule is violated, it’s classified as a successful response. The state of the service is evaluated based on the values you specify for the results window, success threshold, and failure threshold.
An E-Commerce example that consumes external web services
Let’s look at an example E-Commerce solution that uses shipment services from FedEx and UPS as well as a Google search for their customers to search for things that’re available on their site. The E-Commerce solution is written in Java and instrumented for monitoring by AppDynamics. However, the vendor does not have any control on the three web servers it uses.
They can now use the new Service Availability Monitoring solution to check the availability and responsiveness of these external web services via AppDynamics. After some simple configuration, they view (Fig 1) the health and responsiveness of these web services by clicking on “Servers” from the top menu and then on “Service Availability” from the left-hand side menu.
Fig 2: Service Availability Monitoring of external web services
For example, let’s look at the FedEx Shipment service. The response validator is configured to look for HTTP status code 200. As you can see in Fig 3 below, the validation check passed during the last 15 minutes of when the screenshot was taken.
Fig 3: Service details of a healthy web service
In another example, let’s look at the UPS Shipment service, where the response validator is configured to look for the phrase ‘Ecommerce Success’ in the HTTP response body. As you can see in Fig 4 below, it always fails to validate since the response body does not contain the phrase ‘Ecommerce Success’.
Fig 4: Service details of a web service that failed validation
Hopefully, this gives you an overview of use cases and how to get started with the Service Availability Monitoring add-on of the AppDynamics Server Visibility module. Learn more about the configuration and additional details in the Service Availability Monitoring section of the AppDynamics documentation.