Creating a health policy: Define health policy general properties

Specifies the name of a health policy. The health policy name is required and must be unique among all the health policies in the cell.

The name cannot begin with a period (.) or a space. A space does not generate an error, but leading and trailing spaces are automatically deleted. Use meaningful and consistent health policy names. For example, age-based health policies can be indicated by naming the policies AGE_20DAYS, AGE_15DAYS.

Specifies an additional description of the health policy. The description is optional. You can edit the description when you are creating or editing a health policy. Consider using the optional description when you are using many health policies or when multiple administrators manage the same set of health policies.

The health condition defines the specific policy that is implemented. Predefined health conditions are those that ship with the Intelligent Management.

Some policies are prevention-based and some are detection-based. Prevention-based policies are used to avoid conditions that might lead to problems, while the detection-based policies are used to identify existing conditions and to achieve resolution. These policies can be used to perform health-based assessments on clusters, dynamic clusters, and application server instances running on nodes. In the case of dynamic clusters, regardless of the health policy that you are using, the minimum number of dynamic cluster instances remains running.

• When the age-based condition breaches the user-defined age value, the associated health actions are executed. This restart cleans out all cached and memory acquired data. If you select age-based condition policy, you must define the age criteria. The age-based condition is supported for all server types.
• The excessive request timeout condition policy tracks the memory that is used for request timeouts. When the percentage of timeouts exceeds the breach of condition, the associated health actions are executed. If you select the excessive request timeout condition, you must set the memory used percentage threshold. The excessive request timeout condition is supported for all server types.
  Restriction: The excessive request timeout condition does not apply to Java Message Service (JMS) and Internet Inter-ORB Protocol (IIOP) traffic.
• The excessive response time condition policy tracks the requests and the amount of time they take to complete. When you select the excessive response time policy, you must define the response time threshold. If in a specific time interval, the average response time for the requests exceeds the threshold value, the health policy is triggered. The excessive response time condition is supported for all server types.
• The memory condition: excessive memory usage policy tracks the memory usage for a member. When the memory usage exceeds a percentage of the heap size for a specified time, the health actions are executed. If you select the excessive memory usage policy, you must define the memory used and the time-over-memory threshold. The excessive memory usage condition is supported only on application servers on nodes that run WebSphere® Application Server or WebSphere Application Server Community Edition. You cannot define the excessive memory usage condition for other middleware server types.
• The memory condition: memory leak policy tracks consistent downward trends in free memory that is available to a server in the Java heap. The detection level setting determines when these trends are detected. If you select the memory condition: memory leak policy, you must define a detection level. The slower detection level setting requires the most historical data. The normal and faster detection level settings require the same amount of historical data, but the faster setting allows analysis before the Java heap expanded to its maximum configured size. This provides earlier detection capability, but is also more prone to false positives. When this condition is breached, the health actions are executed. The memory leak condition is not supported for other middleware server types.
• The storm drain condition policy tracks stuck requests. The health actions associated with this policy are executed when the specified detection level is reached. Storm drain detection relies on change point detection on a specific time series data. The metrics that are used for detecting storm drain are the response times and deployment workload manager weights that are observed for the server. The storm drain condition applies only to dynamic clusters and cells. If you select the storm drain condition policy, you must select the detection level.

  To detect change points, the health controller calculates a left mean and a right mean for a specific point. For a point, the left mean consists of the mean value of N samples that arrive before this sample, and the right mean is the mean value of N samples, including the current point, that arrive later. The difference of the left and the right mean values is stored and compared with other differences in a set of values to N to determine if this difference is a local maxima. If this difference is the maximum difference, then the point to which this difference corresponds, is declared as a change point. The two metrics that are used for detecting storm drain are the response times and dynamic workload manager weights that are observed for the server.

  The storm drain condition is supported for all server types.
  Restriction: The storm drain condition does not apply to JMS and IIOP traffic.
• The workload condition policy executes the associated health actions, when a specific user-defined number of requests are serviced. If you select the workload policy, you must define the total request criteria. The workload condition is supported for all server types.
• The garbage collection percentage condition policy monitors a Java virtual machine (JVM) or set of JVM’s to determine whether they are spending more than the specified percentage of time in garbage collection over the sampling time period. Since garbage collection increases processor usage, this policy can inform you if poor performance is a result of time spent in garbage collection.

You can define health conditions if the existing health conditions do not fit your needs. Custom health conditions can be tested against metrics in your environment.