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.
Here are just a few examples.
Apply Health Rules to One Node.
You do not want to alert your team if performance in a few clusters is lagging, but if more than 20% of the clusters are unhealthy, or if servers in particular clusters or servers that meet certain criteria are performing poorly, you do want to trigger an alert. You can define health rules that apply to specific tiers or nodes. If these rules violate the system knows exactly which entity is experiencing problems and therefore whom to alert. This rule affects only one node: the order processing server.
Start a diagnostic action for one business transaction.
Performance is deteriorating in one business transaction so you want to view snapshots for that one transaction.
Alert when an app agent stops reporting to the Controller.
Create a node health rule based on the value of the Availability metric reported by the agent. If Availability is less than 1, the agent is not reporting.
You want to be alerted when any business transaction's 95th percentile metric reaches a certain value.
You do not want to create a separate health rule for every business transaction. Instead of specifying a simple metric from the metric tree, you specify a relative metric path. The health rule is evaluated for each business transaction. Use a relative metric path when you need to evaluates a single metric for multiple entities.
You have a large operation with several development teams, each responsible for a different service.
You create a health rule for one service and then copy it. Then you create different policies in which you can pair each copy of the health rule to an alert addressed to the appropriate team.
Start a script to change the size of the connection pool when needed.
You have an application that performs well for normal load. However, peak loads can cause the application to slow. During peak load, AppDynamics not only detects the connection pool contention, but also allows you to create a remediation script that can automate increasing or decreasing the size of connection pool. You can require human approval to run this script or simply configure it to execute automatically when it is triggered. Create a runbook and associate it with a policy so that it will fire when the connection pool is exhausted.
Products that Alert and Respond