The Resource grid object, the VM host grid object, the User grid object, and the Repository grid object each have an attribute or Fact that denotes the health of the object.
Empirically, object health is a simple Boolean value, with True indicating that the object is healthy. This value can be controlled in a number of ways. An unhealthy object is displayed in the Cloud Manager Orchestration Console with a red “plus” symbol to signal the object’s condition.
Figure A-1 Tree View of Repository Grid Objects in the “all” Group, Some Objects Unhealthy
You can define what constitutes the health or non-health of the grid object by setting this health fact. The health fact can be set or cleared in several ways:
The administrator can use tools in the Orchestration Console to explicitly set or clear the fact.
Select any grid object in the Orchestration Console, then click thetab in the Workspace view. This is the “info” attribute editor. The attributes on this page let you edit facts.
The object information panel of the page has acheck box that you can select or deselect to set the health of the object.
On the Constraint/Fact fact page of a grid object, right click the xxx.health fact name, then click to open the Edit Fact dialog box.
You can set the health of the object by selecting or deselecting the health check box. Changing the value in the Orchestration Console in this way has an immediate effect unless the value is overridden by an attached policy (this follows the normal rules of policy inheritance).
A discovery job is a job that is periodically scheduled to run on resources and to explicitly set the health fact, much like it sets other discovered facts). In this case, the discovery job performs a setFact (xxx.health) from JDL code.
This method has little practical use except for locking the value immediately to override the setting (that is, the typical policy behavior) on the grid object:
<policy> <fact name="resource.health" value="true" type="boolean" /> </policy>
Set by using a computed fact. This method can be used to monitor the health according to a computed value. One applied scenario for this method might be a computed fact that performs a statistical analysis of historical load data, perhaps provided by the Metrics facility.
Set automatically by using a health constraint. This is the most practical use and is best illustrated with examples.
Example 1: Define resources as “unhealthy” if their 10-minute load average is greater than 5.
<policy> <constraint type="health"> <lt fact="resource.metrics.loadaverage.history.10_min" value="5.0" /> </constraint> </policy>
You could attach this policy directly to the Resource grid object or to a Resource group. Attaching it to a Resource group is more practical.
Example 2: Define a user as unhealthy if he or she has no money in an account.
<policy> <constraint type="health"> <ge fact="user.account.balance" value="0" /> </constraint> </policy>
You could attach this policy directly to the User grid object, or to a User group. Attaching it to a User group is more practical.
You can aggregate (that is, group together with “and” or “or”) health constraints by using normal rules of policy aggregation.
By default, the Orchestration Server runs health constraints every 30 seconds. To alter this interval, you must contact NetIQ Support.