Copyright © Cloud Software Group, Inc. All Rights Reserved
Copyright © Cloud Software Group, Inc. All Rights Reserved


Appendix C Planning Your Instrumented Application : An Example of Planning AMI Methods

An Example of Planning AMI Methods
Let us suppose you have a transaction-processing application that needs to be monitored so that its message queue length doesn't grow too large. Instances of this application might make up a fault-tolerant group with primary/secondary status, which you want to autonomously monitor but also to interactively control.
Defining these needs, you could list two items:
You now create these methods:
getQueueLength, which takes no arguments and returns the queue length.
getFTStatus, which takes no arguments and returns the fault-tolerant status (primary or secondary) of the application.
makePrimary, which takes no arguments and sets the fault-tolerant status of the application instance to primary.
makeSecondary, which takes no arguments and sets the fault-tolerant status of the application instance to secondary.
Since you will be using a TIBCO Hawk agent as the manager, you build a rulebase with two rules, as follows:
The first rule has as its data source the getQueueLength method. It raises an alert if the queue length is greater than 200.
The second rule has as its data source the getFTStatus method. It sends a notification each time there is a fault-tolerant state transition.
From the TIBCO Hawk WebConsole, operators can control the fault-tolerant state of any instance of the application by invoking the makePrimary or makeSecondary methods.
Other possible AMI examples might include:
Methods that instruct applications to write their new configuration parameters to configuration files or to the Microsoft Windows registry.

Copyright © Cloud Software Group, Inc. All Rights Reserved
Copyright © Cloud Software Group, Inc. All Rights Reserved