JMX Health Rules

This page provides an overview of JMX health rules, which establish the health status of entities in a monitored Java application based on JMX metrics.

JMX Instance Names

For health rules based on JMX metrics, you can create health rules on a node or on an entity called a JMX instance name. If you create the health rule on the JMX instance name, you have the option of restricting it to specific nodes. If you create the health rule on the node, you have the option of restricting it to specific JMX instance names.

A JMX metric is identified by its JMX metric path, its JMX instance name, and its metric name. These are determined by the Metric Path, Object Name Match Pattern, and Metric Name fields specified in the AppDynamics JMX metric MBean Configuration screens. The instance name is derived from the value returned by the object match pattern. Identical JMX instance name values are considered distinct when their metric paths differ.

JMX instance names appear in the Metric Browser under the appropriate JMX metric path. Specific JMX metrics are reported under each JMX instance name.

For details about how JMX metrics are configured, see Configure JMX Metrics from MBeans.

Creating JMX Health Rules

To create a health rule on one or more JMX metrics, in the Affected Entities panel of the health rule wizard, set the type of the rule to Node Health-JMX–connection pools, thread pools, and so on. 

Determine what JMX objects the health rule will be evaluated on. In some IT organizations, different teams are responsible for different MBeans. In other organizations, different teams are responsible for different nodes or tiers. 

The way your organization is set up determines how you think about JMX health, especially where it intersects with node health.

• As a team member responsible for a node, do you consider your node unhealthy because one or more of its MBeans is unhealthy? If so, which nodes or how many?
• As a team member responsible for your JMX infrastructure, are you primarily interested in the health of your JMX data regardless of the nodes that use it? Or are you interested in just specific JMX metrics in specific nodes? Which ones?

It is recommended to have the JMX rule with instance identifier because it helps in selecting the metric under category in the metric select tree of the UI.

For the purpose of configuring JMX health rules and using them in policies, the ultimate question is: who will receive the alert when the agent reports unhealthy performance detected by JMX metrics? The flexibility of the AppDynamics health rules lets you fine-tune your JMX health rules so that the right people are alerted for the code for which they are responsible. 

Select whether the affected entity should be the JMX instance name or the node. In either case, you can configure the rule to cover one of the following scopes:

• All JMX instance names in the application
• Specific JMX instance names
• All nodes in the application
• Specific nodes in the application
• Nodes within the specified tiers
• Nodes matching a given criteria

You can limit the evaluation of the health rule to either the specified JMX instance names or nodes depending on the evaluation scope.

JMX Health Rules Affecting a Node

In one organization, teams are responsible for nodes. Mark is responsible for WEB1_NODE, Tao for WEB2_NODE, and so on.

If an MBean in WEB1_NODE generates JMX metrics that violate a critical condition, and a health rule is configured to evaluate a JMX object in that node, Mark or someone on Mark's team will get an alert. The configuration of the health rule would be:

If different people on Mark's team are responsible for different MBeans used in WEB1_NODE, they could refine the rule further by selecting specific JMX instance names for evaluation. For example, the last decision of this configuration can restrict the rule to evaluate only metrics in the jdbc/ECommerceDB JMX instance name.

Mark's team could create a similar rule for the remaining JMX instance names to use in a policy that alerts whoever on Mark's team is responsible for the jdbc/OracleECommerceD JMX instance names.

Mark's team could also create different rules that evaluate a different set of JMX metrics by choosing a different metric path in the Select JMX Objects field. For example, they could select All Web Container Runtimes.

For problems on WEB2_NODE, they would create a different health rule with WEB2_NODE as the affected node, so that the alerts for those problems go to Tao's team.

JMX Health Rules Affecting a JMX Instance Name

In another organization, teams are responsible for various parts of the JMX infrastructure. Mary is responsible for jdbc/OracleECommerceDB, Meera for jdbc/ECommerceDB, and so on, regardless of which nodes use these MBeans.

So if metrics in jdbc/OracleECommerceDB violate a critical condition, they want Mary to get the alert because her team is responsible. The configuration of the health rule would be:

The rule could be refined to evaluate the JMX metrics in the specified JMX instance names in all nodes in the application or only in specific nodes.