Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 5 Advanced Rulebase Features : Posted Conditions

Posted Conditions
A posted condition is an internal status message, similar to an alert message. Posted conditions are the result of actions in a rule, and can pass status information to other rules in the same rulebase. Each rule uses only a single data source for input, so the posted condition serves as a link between rules with different data sources. This allows you to test for conditions in more than one managed object.
Testing for Non-Zero Values
Posted conditions have integer values assigned internally by a TIBCO Hawk agent. When a rulebase is loaded, values are set to 0 until the action is performed. Performing the action creates the posted condition and gives it a non-zero value, signifying that the condition does exist and has not yet been cleared. Although the value is internal, a test in another rule can check the posted condition for existence or non-zero values. Posted conditions that can be used in a test are listed along with other parameters in the Test Builder dialog.
For example, a rule could check CPU utilization every 60 seconds. If the CPU is greater than 80% utilized when the test is evaluated, a Post Condition action named SystemTooBusy is performed and its integer value becomes non-zero. Another rule retrieving the process table every 60 seconds with a compound test to identify the processes consuming more that 50% of CPU when total usage exceeds 80% can be written as:
((%CPU>50) AND (SystemTooBusy>0))
If this test evaluates to true, an alert message that includes the PID for the process is generated. Results from multiple data sources are required to perform this monitoring task.
Counting Results
You can also use posted conditions to count the number of results returned by the microagent method. Some microagent methods return tabular data when invoked. If the method returns a table of results, an instance of the associated test is generated for every row of the table. The actual value of a posted condition is the number of associated test instances that evaluated to true. You can use this relationship to count the number of rows in the table that match some condition. A non-zero value means that at least one row in the table matched the test condition. The value of the posted condition is the exact number of rows that matched the test condition.
For example, a software virus spawns multiple copies of a common process such as a web browser. The virus uses the SYSTEM account to accomplish this, which is not the normal account for a web browser. To check for the presence of this virus on your network you could create several tests and use a posted condition. The first rule could retrieve the process table, and use a compound test to check for more than one copy of the browser process running as SYSTEM.
If ((name=="netscape") AND (user=="SYSTEM"))
When the test evaluates to true, a posted condition named SystemBrowser is created. The second rule tests the value of the posted condition. It does not require data from a microagent, but uses a token data source: the microagent method Self:getUptime():10. This method returns the number of seconds the agent has been running every 10 seconds. The actual data retrieved from the data source is discarded, but every 10 seconds this method triggers a test for SystemBrowser>1. When the test evaluates to true, a high-level alert is generated.
 

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved