appdynamics

Dashboards. Useful for displaying and sharing information across teams or departments. Allows integrating other tools via iFrame widget. Dashboards can also be embedded into other services or even web pages.

A dashboard can also be converted into a report. One can also schedule periodic emailing of reports to a recipient list. This might be useful to create a “weekly/monthly digest” of data relating to an environment.

Policy triggers define events that trigger actions. When the criteria in a policy is met, a corresponding trigger is activated. This can be used to control behaviour such as increaing thread pool size as load increases etc. The trigger must be associated with a health rule violation. For example, if a health rule specifies “calls higher than normal” then a policy can be created based on this heath rule. The trigger gets executed when violation of the specified health rule occurs. Triggers can span different stages of health rule violations, for example, start and/or end. More than one health rule violation event can be specified.

Health rules are conditions that if fulfilled relate to good health for a particular node. The conditions can be based on load (calls/min), response times (x ms average) or error rate. AppDynamics provides 7 health rules out of the box. When one or many health rules are violated, an alert is issued. Depending on the integrations configured, this alert can be an email or SMS.

Health rule can be based on transaction performance or node health. In case of transaction performance, it can target specific transactions or all transactions in a tier. However, in case of node heath, this can target specific node or nodes in a tier or nodes by type.

The data that health rule uses can also be configured. This can be a time period that it should use. This can be in free form numeric minutes. One can also specify wait time after a violation, i.e. how long should it wait to reassess health rule after it has been violated. This should be long enough so that it has enough new data to positively reassess the condition.

Node is mapped to individual JVM or CLR application in environment. If an environment has multiple JVMs running then each maps to a node.

Tier is a logical piece of application. For example a piece of functionality. Each web server has node. A single tier can span multiple web servers and each of those web servers can contain multiple nodes.

Application traffic is organised into business transactions. Each transaction is a distinct user activity like Login or register etc. When a request comes in for the first time, it is tagged with a GUID and that GUID is tracked across the environment. Requests with similar patterns are grouped together. This group is then given a default name. This is default name is based on how the application is designed.

Since each business transaction works across nodes, each has its own flow map.