Tuesday, January 5, 2010

Exploit policies to manage OMEGAMON situations

Policies extend alert command and control concepts established with OMEGAMON situations and add additional functionality to the Tivoli Enterprise Portal. While situations remain the essential starting point for alerts and automation, policies add essential function and flexibility to situation capabilities. Policies are probably one of the potentially most powerful, and yet most under utilized features of OMEGAMON and the Tivoli Enterprise Portal.

Policies are not a replacement for an automation engine, such as System Automation or AF/Operator. But they do provide a valuable extension to the command functions of situations, and enable the user to do things like issue mutiple commands, or sequences of commands based upon a situation being true. And, what is nice is this can be done using a GUI interface, and does not require coding things such as REXX code to get the job done.

One very interesting use of policies is as an overseer mechanism to manage the start/stop of situations within the Tivoli monitoring environment. Some situation alerts are sensitive to certain times of day or day of week considerations, due to operational or off-hours processing issues. In addition, some issues may be critical during prime time and less critical during off hours. You can reduce monitoring overhead and eliminate unnecessary alerts by running situations only when needed. The picture shows an example of an ‘Overseer’ policy, which manages situation start and stop. Using an overseer policy can simplify the coding and maintenance of the underlying situations, because the policy will be able to handle the time sensitivity logic.
If you want to find out more about policies, you can check out my article on policies (see the link on the right side of the blog page).


  1. ITM V6 has a new "Activity" located in the "Extensions" tab. It is called "Wait until a situation is False".
    I would add this to the policy after it starts the situation. Have it wait until situation EW_check_Prime_Time is False. This way , it will start the situation once and then wait. Without this, it will restart the situation each interval. (Interval of the situation EW_Check_Prime_time). This has two benefits. First, less overhead when you don't restart the situation every interval. Second, if the situation EW_Demo_DB2_Alert is true, restarting it would re-drive the event and make it fire True again.

  2. Paul, you bring up a good point. The example I show is admittedly a bit simplistic. I just wanted to show that you can use policies to stop/start these situations.


Note: Only a member of this blog may post a comment.