This page provides an overview of policies in AppDynamics.
A policy consists of a trigger, which is based on one or more events, and an action, directly in response to the trigger. You can use policies to automate monitoring, alerting, and problem remediation.
View Policies
To view and create policies, access the Policies UI by selecting Alert & Respond > Policies.
The policy list displays all the policies created for your application, with its triggers and actions taken. You can modify a policy by double-clicking it in the policy list.
Policy Triggers
Policy triggers are events that cause the policy to fire. The events can be health-rule violation events or other types of events, such as hitting a slow transaction threshold or surpassing a resource pool limit. See Health Rules, Troubleshoot Health Rule Violations and Monitor Events.
The triggering events can be broad, affecting any object in the application, or very narrow, affecting a specific object. For example, you can have a broadly-defined policy that fires whenever a resource pool limit (such as >80% usage of EJB pools, connection pools and/or thread pools) is reached for any object in the application. Additionally, a narrowly-defined policy is one that would fire only when existing health rules on memory utilization or JVM garbage collection time are violated.
A policy is triggered when at least one of the specified triggering events occurs on at least one of the specified objects.
Policy Actions
You can assign the actions that are taken when a policy is triggered, such as an email or SMS notification. Other types of actions do more than just notify. For example, a resource pool violation can trigger a script that increases the pool size.
Other common actions include restarting an application server if it crashes, purging a message queue that is blocked, or triggering the collection of transaction snapshots. You can also trigger a custom action to invoke third-party systems.
Because the definition of health rules is separate from the definition of actions, you can specify different actions for an event in different contexts, such as a threshold crossing in either a tier or node context.
See Build a Custom Action for information about custom actions. See Actions for more information about the different types of actions.
Policy Actions in Batch
You can configure a policy to execute its actions either:
- Immediately for every triggering event.
For example, if in a two-second period a policy matched 100 events, it would start its actions 100 times as soon as each event occurred. - Once a minute for all the events that triggered over the last minute. This is the batch option. The Execute actions in batch checkbox is selected by default.
For example, if in a two-second period, a policy matched 100 events and then no triggering events occurred for the next 58 seconds, the policy would start each action just once. The context for the actions would be all 100 events.
Which you choose depends primarily on the type of action. For a notification action, it probably doesn't make sense to send 100 emails or SMS messages in a few seconds. In this case, it makes sense to batch the actions with a summary of the events occurring during the last minute. This can be easily accomplished using an email template that iterates through the event list. See the example in Predefined Templating Variables.
However, if the actions are thread dumps, there is no reason to expect that all 100 events are on the same node. They might be on different nodes. For that kind of action, you probably want the thread dump to be taken for each event and also, not to wait another 58 seconds before taking the thread dump.