Define a situation that checks for a missing process on Windows:

Transcription

1 Creating a policy with SNMP activity Version 2 November 11, 2009 This document shows how to create a policy that waits on a situation and then sends an SNMP event to another server when the situation fires. It assumes a general familiarity with ITM and the Portal Client. Define a situation that checks for a missing process on Windows: The formula is:

2 Now create a policy that emits an SNMP alert when the situation is true. Click on the workflow editor icon

3 Click on the New Policy Icon and give it a name Click OK

4 The empty policy looks like this: Click on Wait Until a Situation is True. Drag the pointer into the Policy view. In the situation selection: Select the needed situation, IBM_missing_notepad in this case, and click OK

5 The policy editor now looks like this: Click on the Extensions tab, click on the Wait until a situation is False, click in the compose area, select the same situation. The screen now looks like this:

6 Click on the Emitter Activities tab Click on the SNMP Event

7 Drag pointer it into the policy editor area and click to release. Next, there is a configuration dialog:

8 Select the target with ASFS in the name. Other targets can be used, ASFS has minimal resource usage. The UA environment variable KUMA_STARTUP_DP will need to include asfs.

9

10 Click on Attributes and select attributes to send with the SNMP event Click OK. Click TrapDestination to set the name or ip address of the server receiving the SNMP event. I suggest using or localhost as the first attempt since you don t actually need a SNMP receiver to do the testing. The default port sending number is 162. If you need to specify another port append it with square brackets [163]. You can specify multiple targets separated by commas.

11 Set the Severity and Category as desired.

12 When complete, click on OK. Click on the Connector Click once on the Wait for Situation icon and next on the SNMP event icon,

13 Select Situation is True Click on the connector again. Then click on Wait until Situation True and then on wait until Situation False. Again select Situation is true case. Here is what the end result looks like:

14 The policy is complete. The policy can be revised later at any time, e,g, a double-click on the SNMP event and making any needed changes or revisions. For first testing, set Auto Start off. For production leave it turned on In the policy action line, click on Distributed. A policy must include on the same server(s) that the situation is distributed to.

15 Click OK. Policy editor window

16 Click on Apply and then OK. Note that the distribution used by the workflow must include the distributions in the situation. Situations are usually not started when used by a policy. When a situation is used by the Evaluate Situation activity, that situation must be started once. Note that the pattern above is required to avoid extra SNMP events. When a situation is used by a policy, the samples are gathered at each evaluation. If you did not have the wait for situation false activity, there would be a new SNMP each sampling interval. If the event was not sampled, i.e. a pure event, then the Wait for Situation False must not be used. The pure events never trigger the False condition during processing. Make sure the situation is not running. Right click on the Wait for Situation True activity and select Edit Situation.

17 Right click on missing_notepad and select Stop Situation and then OK Click on the Workflow icon

18 Click on the IBM_notepad_policy Edit Workflow Click on the first action icon at top Start Policy Answer the question of which TEMS to use

19 Click on Start Navigate to the node involved, Windows OS in this case Right click on the node name [Windows OS] and select Manage Policies, you will see a summary of all policies that are running:

20 When the condition comes true, you will see results in the Trace log. You see this via the Manage Tivoli Enterprise Monitoring Services application. Right click on the Universal Agent line, select Advanced and the View trace log

21 Select the most recent and click OK Scroll to the end and you will see like this (Wednesday, November 11, 2009, 3:42:03 PM- {1B38}kumpemit.c,158,"KUMP_EmitSNMPtrap") Note: Using policy-defined severity value when emitting traps (Wednesday, November 11, 2009, 3:42:03 PM- {1B38}kumpemit.c,667,"KUMP_EmitSNMPtrap") SNMP trap emitted to destination(s): Finally, add the KUMA_DCH_TRAPEMIT=Y To the kumenv file, recycled UA and drill down to the ACTION workspace. You can see in the Report view information about the outgoing

22 This will help you get started using policies for SNMP emission. They are required for the SNMP emitter process and have many other useful capabilities.