Additionally, if an HTTP call is destined for an http router which could route the request to one of several instrumented downstream tiers then the default naming rules will need to be modified such that the name includes enough segments of the target URL such that each destination tier is associated with a differently named backend.
About HTTP Backend Naming
To ensure that the HTTP backends detected in your application have meaningful names, and that Business Transaction correlation functions correctly, your custom configuration will need to take into account the specific format used in your environment.
The format can vary even within a single environment. For example, some backend systems may have hostnames prefixed with ec2storage, which may not be meaningful in naming, while others may use hostnames such as salesforce.com, which may be meaningful.
To account for different formats, you should create a custom rule rather than changing the automatic discovery rule. This lets you apply different rules for different URL formats.
You can then apply a specialized approach for each case, as in the following examples:
- For format "ec2storage/servicename", you would use the URL
- For format "salesforce.com", use the host name
- For the other backends, you may use a query string
- For calls that could hit one of several downstream tiers via an HTTP router, you should use sufficient segments of the target URL in the name such that each downstream tier that could process the request is associated with a differently named backend
In some cases, your HTTP backend discovery configuration might consist of a combination of the default rule and custom rules. The following section walks you through a specific example:
Using the URL Path in a Detection Rule
For example, when all the HTTP backends for a tier or application have a similar format, such as a prefix like "ec2storage", you can generate the right name and the correct number of backends to monitor by editing the automatic discovery rule. This enables you to monitor the KPIs that are interested in.
Consider an application with the following HTTP URLs:
http://ec2-17:5400/service1 http://ec2-17:5450/service2 http://ec2-18:5400/service1 http://ec2-18:5450/service2
In this case, measuring performance based on host name would not be useful, since the IP addresses are transient and all performance numbers would be irrelevant after the IP addresses recycle. Instead, you can monitor by service name by avoiding the use of Host and Port properties and using only the URL property, as follows:
- Edit the Automatic Backend Discovery rule for HTTP for your agent type. See Backend Detection Rules for details on accessing this screen.
- First, select and disable the use of Host and Port.
- Then select and enable the property you want to use to uniquely identify the backend. In this case, select URL and check Use URL in the Backend Name.
- For the field How will URL be used in the Backend name?, select Use a segment of it.
From the segment options drop-down list, select Use the first N Segments.
The important URL segment is for the "create" service, so your configuration is the same as in the previous screenshot.
Enter "/" slash for the Split Delimeter.
Use a similar technique to strip out some segment of the URL, such as a user name as in the following URLs:
Once you change the configuration, delete all HTTP backends. When the agent rediscovers the backends with the new configuration, the flow map shows only the service backends.
Custom HTTP Backend Detection and Naming Configuration
You can now customize HTTP backend detection and naming for the .NET Agent for Linux through the Controller UI.
Customizing HTTP backend detection and naming is a feature preview in the .NET Agent for Linux version 4.5.13, recommended for pre-production systems. To enable this feature, see Enable Preview Features.
By default, AppDynamics uses the host name and port number to detect and name HTTP backends. This may be suitable in many cases, however, when your microservices, containers or serverlets are managed by an API gateway or portal, backend services communicating with a client or with each other cannot be correctly mapped to the proper tiers unless you edit automatic discovery to use a portion of the query string or use HTTP custom discovery rules to uniquely name them. AppDynamics recommends you create a custom HTTP backend discovery rule in this case.
The following screenshots provide an example configuration.
Here we choose Match Conditions to describe the API gateway host, in this case, api.appdynamics.com.
This screenshot shows where we choose to use the First 3 segments, using '/' as both the split and merge delimiters.
Configuring the HTTP Backend Discovery Rule as above detects backend metrics and reports them under a business transaction name that begins with api.appdynamics.com followed by the first three segments of the URL of the transaction, such as api.appdynamics.com/api/catalog or api.appdynamics/api/payment. Transactions matching the configured HTTP discovery rule are recognized as individual backends even when they share the same host name and port number. These transactions can be mapped to different tiers so you can analyze the metrics of the transactions that occur behind the API gateway.