With the health monitoring and management subsystem, you can take a policy-driven approach to monitoring the application server environment and take action when certain criteria are discovered.
The health management subsystem continuously monitors the state of servers and the work that is performed by the servers in your environment. The health management subsystem consists of two main elements: the health controller and health policies.
The health controller is the autonomic manager that controls the health monitoring and management subsystem, and acts on your health policies to ensure that certain conditions exist. The health controller is a distributed resource managed by the high availability manager, and exists within all node agent and deployment manager processes. The health controller is active in one of these processes. If the active process fails, the health controller can become active on another node agent or deployment manager process.
The health controller runs on a control cycle. The control cycle length defines the amount of time between environment checks initiated by the health controller. At the end of the control cycle, the health controller checks the environment and generates runtime tasks to resolve any breaches in the health conditions.
You define the health policies, which include the health conditions that you want to monitor in your environment and the health actions to take if these conditions are not met.
You can disable or enable health management using the health controller, while still having multiple health policies defined on the system. You can limit the server restart frequency or prohibit restarts during certain periods.
The health management subsystem functions when Intelligent Management is in automatic or supervised operating mode. When the reaction mode on the policy is set to automatic, the health management system takes action when a health policy violation is detected. In supervised mode, the health management system creates a runtime task that offers one or more reactions. The system administrator can approve or deny the proposed actions.
With these predefined health policy conditions, actions have been taken to optimize the distribution of the needed data, minimize the impact of monitoring, and enforce the health policy in your environment.
You can also define custom conditions for your health policy if the predefined health conditions do not fit your needs. You define custom conditions as a subexpression that is tested against metrics in your environment. When you define a custom condition, consider the cost of collecting the data, analyzing the data, and if needed, enforcing the health policy. This cost can increase depending on the amount of traffic and number of servers in your network. Analyze the performance of your custom health conditions before you use them in production.PMIMetric_FromServerStart$systemModule$cpuUtilization > 90L
Health actions define the process to use when a health condition is not met. Depending on the conditions that you define, the actions can vary. The following table lists the health actions that are supported in various server environments:
Health action | WebSphere® application servers that run in the same cell as the health controller | Other middleware servers, including external WebSphere application servers, that run the node agent |
---|---|---|
Restart server | Supported | Supported |
Take thread dumps | Supported | Not supported |
Take Java virtual machine (JVM) heap dumps | Supported for servers that are running on the IBM® Software Development Kit | Not supported |
Put server into maintenance mode | Supported | Supported |
Put server into maintenance mode and break HTTP and SIP request affinity to the server | Supported | Supported |
Take server out of maintenance mode | Supported | Supported |
Generate a Simple Network Management Protocol (SNMP) trap | Supported | Supported |
You can also define a custom action. With a custom action, you define an executable file to run when the health condition breaches. You must define custom actions before you create the health policy that contains the custom actions.
Health policy targets can be a single server, each of the servers in a cluster or dynamic cluster, the on demand router (ODR), or each of the servers in a cell. You can define multiple health policies to monitor the same set of servers.
If you are using predefined health conditions, the support varies depending on the server type. Certain middleware servers do not support all of the policy types. The following table summarizes the health policy support, by server type:Predefined health policy | WebSphere application servers that run in the same cell as the health controller | Other middleware servers, including external WebSphere application servers, that run the node agent |
---|---|---|
Age-based policy | Supported | Supported |
Workload policy | Supported | Supported |
Memory leak detection | Supported | Not supported |
Excessive memory usage | Supported | Supported for WebSphere Application Server Community Edition servers. Not supported for other middleware server types. |
Excessive request timeout | Supported | Supported for other middleware servers to which the ODR routes requests. |
Excessive response time | Supported | Supported |
Storm drain detection | Supported | Supported |
Garbage collection percentage | Supported | Not supported |
You can create default health policies using predefined health conditions installed with the product.
To create a default health policy, click
, and select one of the predefined health conditions.To view the recommendations made by default health policies and to take actions on these recommendations, click
.