AppDynamics allows you to monitor various aspects of your applications, databases, or infrastructure. NS1’s integration with AppDynamics equips teams to detect service disruptions or user experience issues using AppDynamics application performance monitoring and then automate failover actions in NS1 to minimize downtime or loss of availability.
During the implementation process, you will configure AppDynamics alerts and connect them to associated DNS answers in the NS1 platform. When the state of the alert changes, the up/down metadata for the associated answer changes. For example, suppose an AppDynamics monitor indicates a server is down. In that case, the corresponding DNS answer UP metadata is marked as "false," resulting in DNS traffic being steered away from that endpoint to avoid application issues.
An AppDynamics policy consists of a specified trigger and the action to respond to that trigger. Typically, a trigger activates when a monitor indicates a “critical” or “warning” status (based on the defined heath rule) for a server. For example, you can configure a health rule such that when a server’s memory exceeds 85%, the status is changed to “critical,” setting off the policy’s trigger, and the action occurs. For this integration, the action is to execute an HTTP request template, sending a webhook to an NS1 data feed. The data feed connects the AppDynamics agent to a specific DNS answer. So when the health rule evaluates a server as “critical” (or “warning”), the data feed automatically changes the answer’s UP metadata from “true” to “false.” Once the health rule is no longer evaluated as “critical,” the answer’s UP metadata value returns to "true."
Note
Learn more about AppDynamics concepts and terminology in the AppDynamics documentation.
This article breaks the implementation process down into two parts: Part 1 covers initial implementation which need only be performed once, whereas the steps in Part 2 (steps 6-8) must be performed for each agent (i.e., monitor, probe).
The first part of the implementation process (steps 1-5) are required for initial implementation only.
Log into the NS1 portal, and navigate to Integrations > Data Sources. Click Add a data source.
Under Pick a Source Type, click the AppDynamics logo.
Enter a name for the data source (for internal reference only), and then click Create Data Source.
You are presented with an option to create a feed from this data source. Instead, click X to exit the modal. You do not need to create a data feed at this time.
In the list of Data Sources, note the Source ID next to the data source you just created. You will need this ID to configure the HTTP request template on the AppDynamics platform.
In this step, you will configure an HTTP request template used to send event notifications via webhook to NS1. Refer to the AppDynamics documentation for more information about HTTP request actions and templates.
Log into the AppDynamics portal, and navigate to Alert & Respond > HTTP Request Template. Click New to create a new template.
Enter a Name for the template (ex. “ns1_webhook”).
In the Request URL section:
Next to Method, select Post.
Next to Raw URL, enter
https://api.nsone.net/v1/feed/{sourceID}replacing {sourceID} with the unique data source ID generated in the previous step.Next to URL Encoding, select UTF-8 from the dropdown list.
In the Authentication section, next to Type, select none. Leave all other fields in this section blank.
In the Payload section,
Next to MIME Type, select text/plain.
Next to Payload Encoding, select UTF-8.
Copy and paste the following code into the payload entry box:
{
"topSeverity": "${latestEvent.severity}",
"eventType": "${latestEvent.eventType}",
"application": "${latestEvent.application.name}",
"tier": "${latestEvent.tier.name}",
"node": "${latestEvent.node.name}"
}
Warning
You must enter the code exactly as it appears above or the integration will not work.
The variables enclosed in ${…} are replaced with actual values when an event is raised.
Under Response Handling Criteria,
Click + Add Failure Criteria and select the 404 status code from the dropdown list.
Click + Add Failure Criteria and select the 400 status code from the dropdown list.
Click + Add Success Criteria and select the 200 status code from the dropdown list.
Do not make any changes to the Settings section.
Click Save to complete the HTTP request template configuration.
In this step, you will define a health rule. Note that you can use existing health rules if desired. Health rules allow you to specify parameters to define what you consider normal or expected operations for your environment. When the performance of an entity violates the rule's conditions, a health rule violation occurs. Health statuses are represented as "critical," "warning," "normal," and "unknown."
Refer to the AppDynamics documentation to learn more about health rules.
In the AppDynamics portal, click Alert & Respond from the top navigation and select Health Rules from the sidebar menu.
Next to Health Rules, select the health rule scope to get a set of default health rule types for applications, servers, or databases. In most cases, integrations with NS1 utilize server agents. If so, select Servers from the dropdown menu.
Select one of the predefined rules or click the + (plus sign) to create a new health rule. In this example, we will create a health rule based on the existing “Memory usage is too high” rule.
Select the rule and click the Edit icon at the top of the screen. Ensure the checkbox next to Enabled is selected, and then set the other fields to meet your requirements as described in the AppDynamics documentation here.
Next, click the Affected Entities tab. Select a single server or group of servers to monitor. Refer to the AppDynamics documentation for details.
Note: Do not change the health rule type.
Next, click the Critical Criteria tab and select the conditions under which to raise the critical event. Refer to the AppDynamics documentation for more information. In this example, the critical condition is "if memory usage exceeds 85%."
Similarly, navigate to the Warning Criteria tab to specify the conditions under which to trigger the warning event.
Click Save to save the health rule.
In this step, you will specify an action to take when a health rule evaluates a critical or warning status. An action is a predefined, reusable, automated response to an event. See the AppDynamics documentation for more information.
In the AppDynamics portal, navigate to the Alert & Respond tab and select Servers from the dropdown list.
Under the Actions tab, click + Create. A dialog box appears, prompting you to select an action type.
Under HTTP Request, select Make an HTTP Request and then click Ok.
Enter a Name for the action, and then select the HTTP Request Template you created in step 2. Click Save.
Details appear in the dialog box about the POST payload defined when creating the request template. Click Save to create the HTTP action.
In this step, you will create a policy to apply to the health rule and actions. A policy consists of a trigger based on one or more events and an action to respond. See the AppDynamics documentation for more information on policies.
In the AppDynamics portal, go to the Alert & Response tab and select Policies from the sidebar menu.
Create a new policy for Servers.
Enter a name for the policy.
On the Trigger tab, select every policy trigger listed under Health Rule Violation Events.
Click the Health Rule Scope tab, and select the health rule(s) to trigger this policy. You can select Any Health Rule to indicate that all health rules should trigger the policy (default), or you can choose These Health Rules to apply specific health rules.
Navigate to the Actions tab and click the + (Add) icon. Select the action created in the previous step. Click Select.
Click Save to complete the AppDynamics configuration.
Repeat the following steps for each agent (i.e., monitor/test).
In this step, you will configure AppDynamics agents to monitor your applications and infrastructure. Typically customers will use AppDynamics infrastructure visibility agents in coordination with NS1. This example uses the machine agent. Learn more about agent installation in the AppDynamics documentation.
Once the machine agents are up and running, the associated servers appear in your AppDynamics dashboard under Servers.
In the example above, there are three servers — one standalone and two in the same group. Grouping servers allow you to monitor servers in tandem and send alerts. The machine-path entry defines the grouping (or tier) of servers, but note that it is not identifiable from this screen.
On the NS1 platform, data feeds connect DNS answers to the corresponding entity monitored by AppDynamics. For example, if you are monitoring three servers in AppDynamics and you want to control the up/down status of their associated DNS answers, then you would configure three data feeds — one for each server.
In the NS1 portal, navigate to the Integrations page. Under the Incoming Feeds tab, click the AppDynamics logo.
Enter the following information:
-
Name
(For internal reference) of the data feed.
-
AppDynamics application name*
This is the name of the application as shown in AppDynamics. If you are connecting a machine agent, the application name will always be “Server & Infrastructure Monitoring.”
-
AppDynamics tier name*
By default, the tier name for machine agents is “Root.” If you change the machine agent hierarchy as described in the AppDynamics documentation here, then the tier name is formed by prepending “Root|” to the hierarchy defined by
<machine-path>. For example, if<machine-path>=”Tier_level_1|Tier_Level_2|NodeNameTB”then the tier name isRoot|Tier_level_1|Tier_Level_2. -
AppDynamics node name (optional)
By default, the node name for machine agents is the server’s hostname. As described in the AppDynamics documentation, you can change certain parameters, including the hostname. If set, enter the <unique-host-id> in this field. For example, if
<unique-host-id>=“NS1-demo-host-TB”then you will enterNS1-demo-host-TB.
Warning
You must enter the application name or tier name (or both).
Optionally, select the checkbox to treat health rules that evaluate as warnings the same as those evaluated as critical from AppDynamics. In other words, AppDynamics will send one of three states: info, warn, or critical. If AppDynamics sends a warning to the NS1 platform, and this checkbox is enabled, the corresponding answer's status is changed to “down.”
Click Submit.
Note
You can find the tier name and node name in the AppDynamics portal in the Server dashboard. In AppDynamics, select Servers from the top menu, and then double-click the server/machine to configure.
The “Host ID” and “Hierarchy” appear at the top of the screen. The Host ID is the AppDynamics node name. For example, NS1-demo-host-TB. The tier name is the Hierarchy prepended with Root|. For example, Root|Tier_level_1|Tier_Level_2.
Note
Matching between AppDynamics and NS1 data feed is done at three levels: application name, tier name, and node name. You must enter the application or tier name (or both). The node name is optional. Matching is based on all fields set. To set the DNS record status for an entire application, enter only the application name—leaving all other fields empty. Set both the application and tier names if you have separate DNS answers for each tier. Set all three fields to monitor at the node level.
Warning
For infrastructure monitoring, the application name reported by AppDynamics is always set as “Server & Infrastructure Monitoring.” You must specify the tier name (i.e., machine-path, as explained above) and, optionally, the node name (i.e., unique-node-id) to match with the particular group or an individual server.
In this step, you will connect each data feed to the corresponding answer. When a health rule status change triggers an AppDynamics policy, AppDynamics sends a message to NS1 via webhook. This changes the Up metadata for the corresponding answer from true to false (i.e., it marks the answer as “down.”).
Log into the NS1 portal and click the Zones tab. Navigate to a record that contains answers you wish to monitor via AppDynamics.
 |
Click Create (or Edit) Filter Chain.
 |
Add the Up filter (under Healthchecks) to your Filter Chain by clicking the + icon or dragging and dropping under “Active Filters.”
 |
Once complete, click Save Filter Chain.
Back on the Record Details page, click the “Up” filter on the left to reveal the unset “up” metadata tags beneath each answer.
Click the tag beneath an answer to edit the up/down metadata settings. Alternatively, you can click the icon to the right of the answer and select Edit Answer Metadata from the menu.
 |
Under the Settings column, select the Up/down setting, and click the “feed” icon to the right to show/hide the list of available data feeds.
Click the AppDynamics data feed you created earlier, and then click Ok to apply these changes. The metadata tag appears beneath the answer with a status indicator showing whether the endpoint is up or down.
This completes the configuration. When AppDynamics triggers an alert, the corresponding answer in the NS1 platform is set to “up” or “down” accordingly.