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


Chapter 2 Getting Started : Monitoring Events and Rulebases

Monitoring Events and Rulebases
A deployment configuration file can contain specifications for event elements and TIBCO Hawk rulebases. This section provides examples about how to configure these elements. For an introduction to monitoring events and rulebases, see the TIBCO Administrator User’s Guide.
Event Element
When defining an event in the TIBCO Administrator GUI, the Add Event panel displays the General, Alert, Email and Command sections. The General section defines how events defined in the alert, email and command sections are handled. Events are defined in the deployment configuration file in a similar way. Similar to the General section, the failureEvent element describes how an event is handled. The Alert, Email and Command sections correspond to the alertAction, emailAction and customAction elements.
Alert
The following XML fragment shows the definition of a monitoring alert section. The restart element is set to true and the failure element is set to FIRST. This means when the alert is triggered, only for the first failure occurrence, TIBCO Administrator will attempt to restart the service instance. For all subsequent failure occurrences, the service instance is not restarted. If the failure element was set to Subsequent, each time a failure occurred, the TIBCO Administrator would attempt to restart the failed service.
An alertAction is enabled and set to medium level. The alert is enabled for only for the first failure occurrence. To generate an alert for each failure occurrence, the performPolicy element must be set to Always.
The emailAction and customAction sections are not enabled.
<monitor>
   <events>
      <failureEvent>
         <restart>true</restart>
         <description>Restart on first failure</description>
         <actions>
            <alertAction>
               <performPolicy>Once</performPolicy>
               <enabled>true</enabled>
               <level>Medium</level>
               <message>Component failed!</message>
            </alertAction>
            <emailAction>
               <performPolicy>Once</performPolicy>
               <enabled>false</enabled>
            </emailAction>
            <customAction>
               <performPolicy>Once</performPolicy>
               <enabled>false</enabled>
            </customAction>
         </actions>
         <failure>FIRST</failure>
      </failureEvent>
   </events>
</monitor>
Email
The following XML fragment shows the definition for a monitoring email event. The restart element is set to true, so when an enabled action evaluates to true, the service instance is restarted. The failure element is set to ANY, which means that any failure will trigger the restart.
Only the emailAction element is enabled. The alertAction and customAction elements are disabled. The performPolicy element for email is defined as Always and the enabled element is defined as true. This means that the email alert action will be performed each time a failure event occurs for the application.
<monitor>
   <events>
      <failureEvent>
         <restart>true</restart>
         <description>Restart service instance.</description>
         <actions>
            <alertAction>
               <performPolicy>Once</performPolicy>
               <enabled>false</enabled>
               <level>Low</level>
            </alertAction>
            <emailAction>
               <performPolicy>Always</performPolicy>
               <enabled>true</enabled>
               <message>MyMessage</message>
               <to>SentTo</to>
               <cc>CCTo</cc>
               <subject>MySubject</subject>
               <sMTPServer>my.mail.server</sMTPServer>
            </emailAction>
            <customAction>
               <performPolicy>Once</performPolicy>
               <enabled>false</enabled>
            </customAction>
         </actions>
         <failure>ANY</failure>
      </failureEvent>
   </events>
</monitor>
Command
The following XML fragment shows the definition for a monitor command event.
The restart element is set to false, so the service instance is not restarted upon failure. The alertAction and emailAction elements are disabled.
The customAction element is enabled such that the command is executed only once. The command element lists the batch file to execute upon failure.
<monitor>
   <events>
      <suspendProcessEvent>
         <restart>false</restart>
         <description>Execute command upon failure.</description>
         <actions>
            <alertAction>
               <performPolicy>Once</performPolicy>
               <enabled>false</enabled>
               <level>Low</level>
            </alertAction>
            <emailAction>
               <performPolicy>Once</performPolicy>
               <enabled>false</enabled>
            </emailAction>
            <customAction>
               <performPolicy>Once</performPolicy>
               <enabled>true</enabled>
               <command>c:\commands\bin\mycommand.bat</command>
            </customAction>
         </actions>
      </suspendProcessEvent>
   </events>
</monitor>
Rulebase
In a scenario where a TIBCO Hawk rulebase file is used to monitor a TIBCO BusinessWorks process or an adapter service, when configuring deployment options using the TIBCO Administrator GUI, the rulebase file is picked up by browsing the file system or by specifying the full path to the file in the file system. When the rulebase file is loaded, path information is lost and only the file name and the contents are stored within Administrator.
If a deployment that makes use of this feature is exported into a deployment configuration file, using the AppManage -export command, the XML file has a section similar to:
<monitor>
   <rulebases>
      <rulebase>
         <uri>myrulebase.hrb</uri>
         <data>Hawk Rulebase file in Binary format</data>
      </rulebase>
   </rulebases>
</monitor>
When using this deployment configuration file to redeploy, you must change the uri to the absolute uri of the new Hawk rulebase file. For example:
<monitor>
   <rulebases>
      <rulebase>
         <uri>c:\tibco\hkrulebases\myrulebase.hrb</uri>
         <data>Hawk Rulebase file in Binary format</data>
      </rulebase>
   </rulebases>
</monitor>
Note that:
If the uri is not a valid path to a Hawk rulebase file, the binary content within the <data> tag will be used to create the Hawk rulebase file and the name given to the rulebase file will be the Filename portion of the uri.

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