Create health policy custom actions

Use custom actions to define custom corrective tasks that we can use when a health condition broken. We can also use custom actions to invoke wasadmin scripts.

Create a Java or non-Java executable file to run when the health condition breaches. We can use environment variables in the executable file to display the cell, node, and server that is affected by the health action, for example:

#!/bin/sh
echo "The sick server is "
echo $server
echo " which is on node "
echo $node
echo " which is a part of cell "
echo $cell

By default, we can define the following actions to occur when a health condition is broken: restart the server, take thread dumps, or take heap dumps. If we have more specific needs for actions that occur when a health condition breaches, then create a custom action. Custom actions consist of Java or non-Java process definitions, and can run on the deployment manager, a node hosting servers that breach health conditions, the node where the health management controller is running, or a node specified.

Create a custom action before creating a health policy. When defining the health policy, select the custom action as part of the action plan that runs when the health condition breaches. We can also define a custom action when we are creating an action plan in the health policy creation wizard.

When a health policy contains multiple custom actions, updating the custom actions can cause the health controller runtime to be out-of-sync with the administrative console configuration. If we add, delete or modify a custom action for a policy containing multiple custom actions, start, and stop the health controller after saving your changes.

If we use a custom action to invoke a wsadmin script, create a custom script on the target endpoint, containing the wsadmin invocation. For example, create a custom script test.sh, which uses a Python script to achieve its goal:

test.sh:
#!/bin/sh
/opt/IBM/WAS/bin/wsadmin.sh -lang jython -f /opt/IBM/WAS/wsadmin_test.py param1 param2 param3

wsadmin_test.py:
for arg in sys.argv:
#do something with args

In the administrative console, click...

Operational policies | Custom action | New

Choose the action type and define the custom action properties:

• Name:
• Executable:
• Executable arguments:
• Operating system:
• Work directory:

Tasks

1. Select a Java or non-Java action type. In the administrative console, click...
   Operational policies > Custom action > New

   Choose the type of action to create.

2. Define the custom action properties.

   For health actions that run non-Java and Java executable files:

   • Specify a name for the action, the fully qualified path and name of the executable file, and any arguments to pass to the executable file.

   • If required, specify variables for the user name and password, and specify the actual values to pass for the user name and password at the time the executable file runs.

   • Specify the operating systems on which the executable files can run.

   • Specify a fully qualified path for a working directory, which is where to run the executable file.

   For health actions that run Java executable files, we must also specify the following properties:

   • Specify the location of the Java executable directory.

   • Type of target: a Java class, or an executable Java Archive (JAR) file.

   • Specify the environment variable that stores the process ID (PID) file name. The PID file name is stored in a WebSphere variable. Remember the name of the variable so that we can create the variable in a later step.

   For example, if you had an executable file to collect logs called logCollector.sh, you enter the following values for the custom action:

   Name	LogCollect
   Executable	/opt/mws/bin/logCollector.sh
   Executable arguments	-arg1 excludeCores -arg2 compress
   Operating system	UNIX
   Work directory	/opt/mws/bin/

3. Save the custom action.

4. If our health action is running a Java executable file, create the PID file name environment variable. The PID file name specifies the location of the PID file where the server operation runs. To define the PID file name variable, click...
   Servers > All servers > middleware_server > Variables > New or Environment > WebSphere variables > New

   Enter the same name for the variable entered in the health action panel, and for the value, enter the fully qualified or variable qualified location of the PID file.

Created a custom action that we can add to the action plans of our health policies.

(ZOS) Enable the custom action feature:

1. Add a WebSphere asynchronous administration procedure to the dataset in the PROCLIB concatenation. The following is an example of the job control language (JCL) for this procedure:

   //*--------------------------------------------
   //SHELL2 EXEC PGM=BPXBATCH,REGION=0M,
   // PARM='SH &CMD. &OPT.' 
   //STDERR DD SYSOUT=* 
   //STDOUT DD SYSOUT=* 
   //*-------------------------------------------- 
   

2. The default name for the WebSphere asynchronous administration procedure is BBO8ADM. If a different name is required, change the procedure name, and update the WebSphere environment variable WAS_SERVER_ONLY_shell_command_proc_name to point to the new procedure name.

   To update this variable in the administrative console, click...

   Environment > WebSphere variables > <YOUR_NODE>

   Select the WAS_SERVER_ONLY_shell_command_proc_name variable. Change the value to the new procedure name> OK. Save and synchronize the configuration. Restart the servers that use the custom action feature to begin using the new procedure name.

3. Configure the start command for the WebSphere asynchronous administration procedure so that only the started task ID for the node agent can issue the command. Use the following RACF commands:

   RDEFINE OPERCMDS MVS.START.STC.<ADMIN_PROC_NAME>.**UACC(NONE)
   PERMIT MVS.START.STC.<ADMIN_PROC_NAME>.** CLASS(OPERCMDS) ID(<NODE_AGENT_ID>)ACCESS(UPDATE)
   SETR RACLIST(OPERCMDS)REFRESH
   

4. Define the user ID associated with the WebSphere asynchronous administration procedure, and associate the user to the procedure using RACF commands. For example:

   ADDUSER WSADMSH DFLTGRP(<CELL_ADMIN_GROUP>)OMVS(UID(2504) HOME
   (/var/WebSphere/home/<CELL_ADMIN_GROUP> PROGRAM(/bin/sh)) NAME('WAS Asynch Admin
   Task') NOPASSWORD NOOIDCARD  
   RDEFINE STARTED <ADMIN_PROC_NAME>.*STDATA(USER(WSADMSH)GROUP
   (<CELL_ADMIN_GROUP>)TRACE(YES)) 
   SETROPTS RACLIST(STARTED) GENERIC(STARTED) REFRESH 
   

   In the previous example, the name of the WebSphere asynchronous administration task user ID is WSADMSH. This name can be customized as required. The DFLTGRP of the WebSphere asynchronous administration task user ID should be the WebSphere administrative group for the cell.

   If the system console is not configured to require a login, then even when using RACF commands anyone with access to the console can start the WebSphere asynchronous administration procedure. For more information on securing the system console by requiring a login, see Controlling MCS and SMCS Consoles.

What to do next

Create a health policy. In the administrative console, click....

Operational policies > Health policies > New

Related:

Health management

Create health policies

Configure health management

Intelligent Management: health policy administrative tasks