Create health policies
A health policy is the definition of specific health criteria. Intelligent Management protects the environment against these criteria. The health management function uses defined policy to identify software malfunctions in the environment.
Create a health policy requires configurator or administrator administrative privilege. The health controller must be enabled.
Define any custom actions before creating the health policy.
Health policies work with the health controller to monitor the operation of the servers in the environment. When the health controller detects that the servers are not meeting a defined health policy, we can take action to fix the problem. We can notify the administrator of problems, or Intelligent Management can fix the problems automatically.
Tasks
- In the administrative console, click...
-
Operational policies | Health policies | New
- Define health condition properties for the health policy. For example...
Remember: The excessive request timeout and storm drain conditions do not apply to JMS and IIOP traffic.
Health policy conditions include the following properties:
- Set properties that pertain to the health condition that we selected.
If we chose to create a custom health condition, specify a subexpression that represents the metrics that we are evaluating in our custom condition. For more information about the conditions that we can set, click Syntax help.
As a best practice, consider the cost of collecting the data, analyzing the data, and if needed, enforcing the health policy when defining a custom condition. Consider the amount of traffic in the network, especially when you scale out the number of servers that produce data. Before introducing new health policies into the production environment, analyze these aspects of our custom health conditions.
We can further configure our custom health conditions that leverage PMI modules, notably the webAppModules, at finer granularities than the server granularity. For example, we can use the subexpression builder to create a webAppModule policy as a starting point, then edit the expression to define a finer granularity:
- PMIMetric_FromServerStart$webAppModule$SlamSess\#SlamSess.war\/webAppModule.servlets\/SlamSess\/responseTime > 100L
In this example, the application name is displayed as SlamSess when we list the applications in the administrative console. If we are using an EAR file, specify the Web archive (WAR) file name after the EAR file name. If the WAR is not embedded in an EAR file, specify only the WAR file name. The SlamSess value is the servlet name listed in the web.xml file. The responseTime value is the statistic listed in the Performance Monitoring Infrastructure (PMI) module definition.
- Choose a reaction mode.
Supervise mode allows the administrator to approve or reject actions before they are taken.
- Select the actions to take when the health policy conditions are not met.
The available actions depend on the health condition type. These actions can be the existing default actions, or we can define custom actions to run an executable file. A list of actions are displayed in the sequence in which they run when the health condition breaches. We can add and remove steps from this list.
- If we select a custom action for our health policy, we must indicate the targets for our custom action.
If we select Node hosting the sick server as your target node, the target server options are Node agent of the sick server and Sick server.
- Set properties that pertain to the health condition that we selected.
- Select the members to monitor.
Layers of logic can apply to monitored members. For example, we might want to apply a specific health policy to each member of a cluster and to an application server outside of the cluster.
- Review and save our health policy.
Created a health policy and applied that policy to a target environment. The health controller monitors the conditions definedd for the health policy members, and takes the defined actions on the members when the conditions in the health policy breach.
What to do next
If we chose the Supervise reaction mode, then we receive recommendations to improve our health conditions. These recommendations display as runtime tasks that we can accept, deny, or close. To manage runtime tasks, click...
-
System administration | Task management | Runtime tasks
If we chose the Automatic reaction mode, actions to improve the health of the environment occur automatically.
For supervised reaction mode runtime tasks, we can set the JVM custom property...
- com.ibm.ws.xd.hmm.controller.ControlConfig.approvalTimeOutMinutes
...which specifies the number of minutes that can pass before a runtime task for the health controller expires. If we set the value to 5 minutes or less, the default value of 30 minutes is automatically used instead. If we do not take any actions on the runtime task, the task expires in the number of minutes specified in this property. If the runtime task expires when the health condition still exists, a new runtime task is generated.
If we configure our health policies often, consider using AdminTask commands to automate the process.
Subtopics
- Custom health condition subexpression builder
- Create health policy custom actions
- Modify the JVM heap size
Related: