Related pages:

Watch these videos:

 

Alert and Respond: Quick Tour

Alerts let you know when problems exist and help you anticipate problems that might be developing. Responses let you automate preventative actions to address those problems before they cause a severe slowdown or outage. Think of alert and respond as the automation of your runbooks.

The alert and respond system is made up of three parts:

Sample Use Cases

The AppDynamics platform recognizes some broad-based health issues commonly experienced by applications, such as "Business Transaction response time is much higher than normal" or "Memory utilization is too high". These are configured as default health rules, which define how high is "much higher than normal" or "too high". Use policies to attach these rules to alerts (whom to notify) and responses (what to do) when these problems exist. You can use these rules "as is" or modify them for your environment. See Default Health Rules.

In addition to the broad-based rules, you can customize precise automatic alerts and responses for narrowly circumscribed situations. This lets you fine-tune your system, ensuring that the right alert goes to the right person, the right action is taken for the right problem on the right cluster or server.

For example:

Scope and Access to Alert and Respond Features

Typically different types of users with different types of roles set up and use different alert and respond features.

Email templates, HTTP request templates, and Email/SMS configuration are account-level features. The scope of these features, once set up, is the entire AppDynamics account. The items created at the account level are available to all the applications in that account. Account-level items are created and managed by users who have account-level roles that include permissions to create them.

By default these roles are account owner and administrator, although custom roles could be created that include some of these permissions. For example, an account owner or administrator could create an email template manager role that could be assigned to other users to give them the ability to create and modify email templates.

TBD? In addition, custom roles could be configured with view template permission. For example, an account manager could create an HTTP request template user role that allows users to view templates without being able to modify them. This would enable power users creating HTTP actions to examine the contents of the templates that might be appropriate to their needs.

Policies, health rules, actions and email digests are application-level features. The scope of these features is the application in which they were created. Only roles with application-level permissions are required to create and manage these items.