Create health policies
A health policy is the definition of specific health criteria that you want your WebSphere Virtual Enterprise to protect itself against. The health management function uses the defined policy to search the environment for software malfunctions.
Before you begin
- To create a health policy, have configurator or administrator administrative privileges. The health controller must be enabled.
- Define any desired custom actions to run on the target server when the health condition that you define in the health policy breaches.
About this task
Health policies work with the health controller to monitor the operation of the servers in your environment. When the health controller detects that your servers are not meeting a defined health policy, you can take action to fix the problem. You can notify the administrator of problems, or WebSphere Virtual Enterprise can fix the problems automatically.
Procedure
- In the administrative console, click...
Operational policies | Health policies | New
- Define the health policy general properties.
These properties include...
- health policy name
- description
- health condition
The excessive request timeout and storm drain conditions do not apply to JMS and IIOP traffic.
You can specify either a predefined condition or a custom condition. With a predefined condition, you choose among a list of predefined conditions that the health controller supports. These predefined conditions are optimized to minimize the impact of the policy on your environment. With a custom condition, you create a subexpression that is evaluated against other metrics in the cell.
PMIMetric_FromServerStart$webAppModule$SlamSess.ear\#SlamSess.war\/webAppModule.servlets\/SlamSess\/responseTime > 100L
In this example, the SlamSess.ear file is the name of the EAR that is displayed when you list the applications in the administrative console. If the WAR is not embedded in an EAR file, specify the WAR file name. If you are using an EAR file, specify the WAR file name after the EAR file name. The SlamSess value is the servlet name that is listed in the web.xml file. The responseTime value is the statistic that is listed in the PMI module definition.
- Define health policy health condition properties. Health
policy conditions include the following properties:
- Set properties that pertain to the health condition that you selected are displayed. If you chose to create a custom health condition, then you specify a subexpression that represents the metrics that you are evaluating in your custom condition. For more information about the conditions that you can set, click Syntax help.
When you define a custom condition, consider the cost of collecting the data, analyzing the data, and if needed, enforcing the health policy. Consider the amount of traffic going over your network, especially when you scale out the number of servers that produce data. Before introducing new health policies into a WebSphere XD environment, perform analysis of these aspects of your custom health conditions.bprac
You can further configure your custom health conditions that leverage PMI modules, most notably the webAppModules, at finer granularities than the server granularity. For example, you can use the subexpression builder to create a webAppModule policy as a starting point, then edit the expression to define a finer granulatrity:
PMIMetric_FromServerStart$webAppModule$SlamSess.ear\#SlamSess.war\/webAppModule.servlets\/SlamSess\/responseTime > 100L
In this example, the SlamSess.ear file is the name of the EAR that is displayed when you list the applications in the administrative console. If the WAR is not embedded in an EAR file, specify the WAR file name. If you are using an EAR file, specify the WAR file name after the EAR file name. The SlamSess value is the servlet name that is listed in the web.xml file.
The responseTime value is the statistic that is listed in the PMI module definition.
- Choose a reaction mode. Supervise mode gives more control to the administrator, so that they can 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 you can define custom actions to run an executable file. A list of actions are displayed in the order that they are run when the health condition breaches. You can add and remove steps from this list.
- Set properties that pertain to the health condition that you selected are displayed. If you chose to create a custom health condition, then you specify a subexpression that represents the metrics that you are evaluating in your custom condition. For more information about the conditions that you can set, click Syntax help.
- Select the memberships to monitor for your health policy. Layers of logic can apply to monitored memberships. For example, you 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 your health policy.
Results
You created a health policy and applied that policy to a target environment. The health controller monitors the conditions that you defined 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 you chose the Supervise reaction mode, then you receive recommendations to improve your health conditions. These recommendations display as runtime tasks that you can accept, deny, or close. To manage runtime tasks, click...
System administration | Task Management | Runtime Tasks