tibco hawk implemenration

White Paper on TIBCO Hawk Implementation

White Paper

On

TIBCO Hawk Implementation

Author: Wipro

Creation Date: 08 17, 2009

Version: 0.1

Status: Reviewed

of 36


CHANGE RECORD

of 36

Date Author Version Change Reference

Aug 17,2009 Wipro 0.1 Initial version


CONTENTS

Change Record.........................................................................................................................................................2

1. Purpose....................................................................................................................................................... 6

2. Assumptions................................................................................................................................................ 6

3. Introduction................................................................................................................................................ 6

4. Product Versions......................................................................................................................................... 8

5. Hawk Configuration..................................................................................................................................... 8

5.1 Configure Domain Hawk Agent....................................................................................................................9

5.2 Rename Default Hawk Agent.......................................................................................................................9

5.3 Monitor And Manage EMS Server From Hawk...........................................................................................10

5.4 Monitoring Event Service from Hawk.........................................................................................................11

5.5 Restart Hawk Services...............................................................................................................................11

5.6 Configure Hawk Display For EMS transport (On Windows)........................................................................12

6. Rulebases.................................................................................................................................................. 13

6.1 Pre-requisites.............................................................................................................................................13

6.1.1 Folder Structure......................................................................................................................................13

6.1.2 Command Procedures............................................................................................................................13

6.1.3 Variables Configuration File...................................................................................................................13

6.2 Rulebase: BusinessWorks Process Engine...................................................................................................15

6.2.1 Requirements.........................................................................................................................................15

6.2.2 Implementation Details..........................................................................................................................15

6.2.3 Load The Rulebase..................................................................................................................................19

6.2.4 Migration Across Environments..............................................................................................................19

6.2.5 Template Rulebase.................................................................................................................................19

6.3 Rulebase: File Adapter................................................................................................................................20

6.3.1 Requirements.........................................................................................................................................20



of 36




6.4 Rulebase: ADB Adapter..............................................................................................................................22

6.4.1 Requirements.........................................................................................................................................22





6.5 Rulebase: EMS Server.................................................................................................................................24

6.5.1 Requirements.........................................................................................................................................24




6.6 Rulebase: EMS Queues...............................................................................................................................25

6.6.1 Requirements.........................................................................................................................................25





6.7 Rulebase: EMS Durable Topics....................................................................................................................28

6.7.1 Requirements.........................................................................................................................................28





6.8 Rulebase: Client Connections to the EMS server.........................................................................................32

6.8.1 Requirements.........................................................................................................................................32





of 36


6.9 Rulebase: Hawk Agent...............................................................................................................................33

6.9.1 Configuration on Machine B...................................................................................................................33

6.9.2 Requirements.........................................................................................................................................34





6.10 General Guidelines.....................................................................................................................................36

of 36


1. PURPOSEThis document talks about the configuration and the implementation details for monitoring and management of following TIBCO components using TIBCO Hawk.

1. BusinessWorks Process Engines

2. File Adapter

3. ADB Adapter

4. EMS server

5. EMS queues

6. EMS durable topics

7. Client connections to the EMS server

8. Hawk Agent

As the monitoring and management requirements vary from project to project, the requirements listed in this document may not hold good for every project. However, this document can be used as a reference for getting started on TIBCO Hawk implementation.

2. ASSUMPTIONSThe following assumptions were made in the writing of this document:

Reader must be very knowledgeable with TIBCO Hawk to understand the rulebase layouts.

Reader is knowledgeable with other TIBCO products

3. INTRODUCTIONTIBCO Hawk is a tool for monitoring and managing distributed applications and operating systems. Unlike other monitoring solutions, TIBCO Hawk software uses TIBCO Messaging software for communication and inherits many of its benefits. These benefits include a flexible architecture, enterprise-wide scalability, and location- transparent product components that are simple to configure. In this particular implementation, the TIBCO Enterprise Messaging Service (EMS) will be used for messaging.

TIBCO Hawk is an event-based system built around the concept of a distributed, autonomous smart agent that operates on each managed machine. The software is designed specifically for monitoring distributed systems, so there is no centralized console or frequent polling across the network. With this structure, TIBCO Hawk is able to scale and has the flexibility to allow individual managed entities to be added or modified without the need to re-configure or re-start any other parts of the system.

of 36


The work required to monitor applications is performed by TIBCO Hawk agents.

TIBCO Hawk Agent runs on each node in the TIBCO domain and monitors local conditions. Each agent uses collections of locally loaded rules organized into rulebases to apply monitoring logic. A rulebase tells an agent how to monitor particular application or system resources and what actions to take when specific conditions are detected.

The TIBCO Hawk Display application subscribes to alert messages generated by TIBCO Hawk rulebases and presents them in an organized view. Alerts are color-coded to indicate the severity of a reported problem. Clicking on a node displays the error message along with a recent history of problems on the node. TIBCO Hawk Display does not store centralized monitoring intelligence; it simply offers a view of events from the monitored systems. Adding more instances of the Display application requires no additional network overhead or configuration.

The TIBCO Administrator also subscribes to the alert messages, and will display the alerts under the individual machines in the TIBCO domain.

FIGURE 1 HAWK ARCHITECTURE DIAGRAM

of 36


4. PRODUCT VERSIONSGiven below are the TIBCO products and their versions used in this particular implementation. The TIBCO suite is installed on HP-UX B.11.23 ia64 operating system.

TIBCO BusinessWorks 5.4.2

TIBCO EMS Server 4.4.3

TIBCO File Adapter 5.5.0

TIBCO ADB Adapter 5.4.0

TIBCO Runtime Agent 5.5.3

TIBCO Hawk 4.7.0

5. HAWK CONFIGURATIONThis section talks about the configuration steps.

In general, there will be 2 Hawk agent services, one comes with TIBCO Admin domain and another one comes with standalone Hawk installation. In this particular implementation, domain Hawk agent is used for all monitoring purposes.

TIBCO Hawk Agent is an autonomous process that monitors applications and systems activity. Each administration server has a corresponding TIBCO Hawk Agent. The Hawk Agent monitors activity by processing rulebases, which hold the logic that determines how monitoring and management will take place.

A Hawk Agent runs on the machine that hosts the administration server and on each machine that is part of the administration domain.

In this implementation, EMS server is used as the messaging transport for communication across Hawk Agent, Hawk Display and Hawk Event services. The advantage in using EMS transport is that Hawk Display from any subnet can be used to monitor the agents, alerts and rulebases as long as Hawk Display is connected to the right EMS server.

EMS servers can be configured to route messages between networks where rvrd is not setup to do so. In order to do this both networks must have an EMS server running. Messages from one network are routed to the other via the EMS server instead of the rvrd

The only disadvantage is that EMS server will be single point of failure unlike Rendezvous daemon.

of 36


5.1 CONFIGURE DOMAIN HAWK AGENT

In this step, Domain Hawk agent is configured to use EMS server as its transport and also to communicate with Hawk event service.

a) Open the “<tibco_root>/tra/domain/<domain_name>/hawkagent.cfg” file in a text editor

b) Under “ems_transport” property, specify the EMS server connection details as, shown below.

-ems_transport tcp://<EMS server host>:port <user id> “#!encrypted password”

c) In order to communicate with Hawk event service, add the ami_rvd_session that matches with that of Hawk event service’s ami_rvd_session. (Steps to configure the Hawk event service with the same parameters is mentioned in a later section)

For example, -ami_rvd_session 8500 127.0.0.1 tcp:8500

d) Save the changes.

Note: The encrypted password can be generated by running the Hawk utility program tibhawkpassword located in your hawk/bin directory:

tibhawkpassword -encrypt password

where password is the current password

5.2 RENAME DEFAULT HAWK AGENT In this step, Hawk agent that comes with standalone installation is renamed so that the two Hawk agents (one that comes with standalone Hawk installation and another one that comes with TIBCO Admin domain) can be distinguished in the Hawk Display.

a) Open the “<tibco_root>/hawk/bin/hawkagent.cfg” file in a text editor

b) Change the agent name as mentioned below.

-agent_name <machine-name>_default

c) Under the ems_transport, specify the EMS server connection details



of 36


5.3 MONITOR AND MANAGE EMS SERVER FROM HAWK

To use TIBCO Hawk to manage the TIBCO Enterprise Message Service server, load the HawkController or HawkListenerclasses provided into the TIBCO Hawk agent. Once the classes are loaded, methods for managing the EMS server are available in the TIBCO Hawk display. In this implementation, the HawkController classes have been loaded.

Installing the classes is different for UNIX and Windows platforms. Given below are the steps for installing the classes in UNIX. Please refer to Hawk documentation for the procedure on Windows.

a) Locate the “tibjmsadmin.hma” file in the TIBCO EMS installation directory under the <tibco_root>/ems/samples/admin/hawk subdirectory and copy it to TIBCO TRA Hawk plugins directory.

Usually, TIBCO TRA Hawk plugins directory is located in <tibco_root>/tra/domain/<domain_name> /plugin

b) Locate tibjmsadmin.jar in the ems/clients/java subdirectory, and copy it into the TIBCO TRA Hawk plugins directory.

c) Open the “<tibco_root>/tra/domain/<domain_name>/hawkagent.cfg” file in a text editor and specify the -hma_plugin_dir option to include the directory where your TIBCO Hawk plugins are located.

-hma_plugin_dir "<tibco_root>/tra/domain/ <domain_name>/plugin"

Save changes to “hawkagent.cfg”

d) Navigate to plugins directory and open the “tibjmsadmin.hma” file in a text editor

e) Specify the TIBCO Hawk microagent class you wish to use in the <classname> element. In this implementation, com.tibco.tibjms.admin.hawk.HawkController has been used.

f) Specify the username and password and server URL to use to connect to the TIBCO EMS server in the appropriate <arg> elements For example:

<arguments> <arg>-user</arg> <arg>admin</arg> <arg>-password</arg> <arg>MyPassword</arg> <arg>-server</arg> <arg>tcp://<EMSServerHost>:<port></arg> <arg>-timeout</arg> <arg>5</arg> </arguments>

You should use specify the predefined admin user or a user that is a member of the $admin group.

of 36


Save changes to “tibjmsadmin.hma”.

Note: To use an encrypted password, specify –encryptedPassword instead of -password. As the value for -encryptedPassword, supply the output you obtain by running the Hawk utility program tibhawkpassword located in your hawk/bin directory:

tibhawkpassword -encrypt password

where password is the current password

5.4 MONITORING EVENT SERVICE FROM HAWK The TIBCO Hawk Event Service is a process that records TIBCO Hawk alerts and changes in agent status. When communication with an agent is lost, the Event Service can invoke a user-provided script. Alerts and notifications can be recorded to log files or a database.

Typically, the TIBCO Hawk Event Service is installed on a minimal number of computers in the network.

In this step, Hawk event service is configured to use EMS server as its transport and also to communicate with Hawk agent service.

a) Open the “<tibco_root>/hawk/bin/hawkevent.cfg” file in a text editor

b) Under the ems_transport, specify the EMS server connection details.


c) Also specify the TIBCO Rendezvous session used by the TIBCO Hawk event service for AMI communications.

For example,

-ami_rvd_session 8500 127.0.0.1 tcp:8500


5.5 RESTART HAWK SERVICES

Save all the above changes and restart the following services so that the changes will be effective.

a) Hawk agent service that comes with standalone installation

b) Domain Hawk agent service

c) Hawk event service

of 36


5.6 CONFIGURE HAWK DISPLAY FOR EMS TRANSPORT (ON WINDOWS)In this particular implementation, Hawk Display running on Windows is configured to use EMS transport.

Open the “Hawk Configuration” window from menu and configure the following.

a) Ensure that Hawk Domain name matches with that of domain name mentioned in the Domain Hawk agent’s “hawkagent.cfg”

b) In the Transport tab, select the Primary Transport as EMS and provide the EMS server connection details. This should be the same EMS server that was configured in Step 5.1

c) Click “Ok”

d) Click “No” on the dialogs that ask for restarting the Hawk related services.

Now open the Hawk Display from menu to verify that all the changes are done successfully.

of 36


6. RULEBASES

6.1 PRE-REQUISITES

The many new Hawk rulebases, command procedures, etc. need to be separate from the core TIBCO and Hawk products. This will allow TIBCO Hawk to be upgraded independently from the custom components and vice-versa. Given below are the pre-requisites for the rulebases.

6.1.1 FOLDER STRUCTURE

Create the following folder structure under TIBCO domain root (i.e. <tibco_root>/tra/domain/ <domain_name>)

----Accelerator

-flags (Location of .enabled and .running files)

-scripts (Location of custom command procedures)

6.1.2 COMMAND PROCEDURES

The BW and ADB Adapter rulebases use Command Procedures to perform some actions. To track the status of BW process engine or ADB adapter .enabled and .running files will be created and deleted in the “flags” folder, using these Command Procedures.

UNIX shell script files namely CreateEmptyFile.sh and RemoveFile.sh will be used for creating and deleting the appropriate files. If running on Windows the equivalent batch scripts need to be prepared. At any point of time, Hawk rulebase will identify the status of BW process engine or ADB adapter based on the availability of one or both of these files and takes the necessary action.

Copy the CreateEmptyFile.sh and RemoveFile.sh scripts to “tibco_root>/tra / domain/ <domain_name> /Accelerator/scripts” folder.

After copying the files, change the permissions of CreateEmptyFile.sh and RemoveFile.sh to 777 so that these can be invoked from the rulebases.

6.1.3 VARIABLES CONFIGURATION FILE

TIBCO Hawk has the capability to use external variables within the Hawk rulebases. There are some fields that will be used in all rulebases. Some of the fields will be common, others will not. These include certain directory locations, log file locations, and several e-mail related values.

of 36


The <tibco_root>/tra/domain/<domain_name>/Accelerator/scripts/HawkAC_variables.dat will hold all of the variables. All of the values will be configured for each machine/environment in this file. Every agent can read only one configuration file.

Standard Variables to include:

MAIL_SERVER: This is the mail server used for sending emails.

MAIL_FROM: The email address defined in this variable will be used as from address on any email sent from Hawk

MAIL_CC: Any email recipient defined in this variable will be CCed on any Hawk alert sent.

MAIL_SUBJECT: The prefix used in the subject of email is defined in this variable.

MAIL_TO: Any email recipient defined in this variable will be emailed on any email sent from Hawk.

DOMAIN_NAME: This should be set to the name of the TIBCO Administration domain

CONFIG_ROOT: This is the location of all of the scripts and config files for Hawk. The variables file should already be set to the correct value.

FLAG_ROOT: This is the location of the Hawk enable flags. The variables file should already be set to the correct value.

TRA_ROOT: This is the root location of the TIBCO domain. The variables file should already be set to the correct value.

Note: Apart from above variables, rulebase specific variables also can be added. Please keep in mind that if any changes are done in the HawkAC_variables.dat, Domain Hawk agent service need to be restarted to make the changes effective. The recommendation would be to add the variables for all rulebases at once, to avoid restarting the Hawk agent service for several times.

The HawkAC_variable.dat file need to be placed in the “<tibco_root>/ tra/domain/ <domain_name>/ Accelerator/scripts” directory

The TRA hawkagent.cfg configuration file must be modified to include the variables file. The –variables line must be uncommented, and the name and location of the variables file appended to the parameter.

-variables <tibco_root>/tra/domain/<domain_name>/Accelerator/scripts/HawkAC_variable.dat

Save the changes.

Restart Domain Hawk agent service.

of 36


6.2 RULEBASE: BUSINESSWORKS PROCESS ENGINE

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO BusinessWorks Process engines.

The naming convention followed for this kind of rulebase is “BWEngine-Deployment-Component.hrb”. Here Deployment is the Enterprise Archive name and Component is the process archive name in the BW project.

6.2.1 REQUIREMENTS

If the engine is started or stopped from the TIBCO Administrator, then Hawk rulebase should not start the engine. If the engine is stopped abruptly due to some reason, then the rulebase should attempt to start the engine for once.

At each step, appropriate alerts and/or emails should be sent from the rulebase.

6.2.2 IMPLEMENTATION DETAILS Given below are the implementation details for “CISCommon” BW process engine. The rulebase name is "BWEngine-CISCommon-CISCommonProcesses.hrb"

Given below is the sequence diagram which describes the high level implementation of this rulebase.

of 36


FIGURE 2 BW PROCESS ENGINE RULEBASE FLOW

of 36


The rules include:

Check for the .running file: This rule will test to see the “CISCommon-CISCommonProcesses.running” file exists in “flags” directory. If the file exists, then the “no_error” post condition is set. If the file does not exist, then the “error” post condition is set. The rule will check for the .running file every 2 seconds. This post condition is used later in the rulebase to help Hawk determine if the BW Process Engine has successfully started previously.

Check for the .enabled file: This rule will test to see the “CISCommon-CISCommonProcesses.enabled” file exists in “flags” directory. If the file exists, then the “enabled” post condition is set. If the file does not exist, then the “disabled” post condition is set. The rule will check for the .enabled file every 5 seconds. This post condition is used later in the rulebase to decide whether the rulebase need to take some action or not

This rule checks to see if the BW Process Engine is running, also using the TRA.getComponentStatus Hawk microagent. This test is performed every six seconds. This rule has several steps depending on if the service is running. The rule will:

of 36


o Check to see if the BW Process Engine has a state of INITIALIZING. If it does, the BW Process Engine is being started via the TIBCO Administrator. The rule will run the “CreateEmptyFile.sh” script with appropriate parameters such that “CISCommon-CISCommonProcesses.enabled” file is created and there by “enabled” post condition is set.

o Check to see if the BW Process Engine has a state of RUNNING. If it does, the BW Process Engine has successfully started. The rule will send an informational notification and email that it is running, and run the “CreateEmptyFile.sh” script with appropriate parameters such that “CISCommon-CISCommonProcesses.running” file is created and there by “no_error” post condition is set.

o Check to see if the BW Process Engine has a state of STOPPING and enabled post condition exists. This signifies that BW Process Engine is being stopped via TIBCO Administrator. The rule will run the “RemoveFile.sh” script with appropriate parameters to remove the “CISCommon-CISCommonProcesses.enabled” file to ensure that “disabled” post condition is set. This will prevent Hawk from attempting to restart the BW Process Engine.

o Check to see if the BW Process Engine has a state of STOPPED. This signifies that BW Process Engine is no longer running. It could be stopped via TIBCO Administrator or due to some error. The rule will run the “RemoveFile.sh” script with appropriate parameters to remove the “CISCommon-CISCommonProcesses.running” file to ensure that “error” post condition is set.

o Check to see if the BW Process Engine has a state of STOPPED and “enabled” post condition is set. This signifies that BW Process Engine got terminated abruptly due to some error. The rule will send a low alert stating the BW Process Engine is not running, and will attempt to start the engine. The rule will also run “RemoveFile.sh” script with appropriate parameters to remove the “CISCommon-CISCommonProcesses.running” file to ensure that “error” post

of 36


condition is set. After 90 seconds, if the BW process is not started, a high alert will be sent stating that the BW Process Engine is still down. The BW Process Engine will be disabled to prevent the rule from attempting to start it again. The rule will also run the “RemoveFile.sh” script with appropriate parameters to remove the “CISCommon-CISCommonProcesses.enabled” file to ensure that “disabled” post condition is set, preventing Hawk from attempting to restart the BW Process Engine.

o Check to see if the BW Process Engine has a state of STOPPED and “disabled” post condition is set. The rule will send a low alert that the Hawk rulebase will not attempt to start the BW Process Engine.

6.2.3 LOAD THE RULEBASE

Before sending the rulebase (from the rulebase editor) to the selected machine, please keep in mind the following items.

This rulebase need to be applied only after verifying that a BW Process Engine has been started successfully once in TIBCO Administrator.

Apply the rulebase only when the BW process engine is down. After applying the rulebase start the BW Process Engine from TIBCO Administrator.

Before redeploying a new Enterprise Archive for a BW process engine that is being monitored by this rulebase, please STOP the BW Process engine manually in TIBCO Administrator and ensure that it is not running. If the BW process engine is not stopped before redeployment, the engine will get killed and the rulebase will try to start the engine again.

6.2.4 MIGRATION ACROSS ENVIRONMENTS

Since this rulebase depends on the variables defined in “HawkAC_variables.dat”, please ensure that the values for these variables are correctly defined as per the respective environment configuration.

Same rulebase can be moved from one environment to another environment without any changes.

6.2.5 TEMPLATE RULEBASE

Given below is the template rulebase that has been implemented with the requirements mentioned in section 6.2.1

Following changes have to be done, prior to using this rulebase for a BW Process Engine.

DeploymentName need to be replaced with the EAR name defined in the BW Project

of 36


ComponentInstanceName need to be replaced with Process Archive name defined under the EAR.

AuthorName need to be replaced with the author of the rulebase

HostName(IPAddress) need to be replaced with a corresponding value

DateTime need to be replaced with the current date time

BWEngineDesc needs to be replaced with appropriate description of the BW Process Engine.

Finally, the rulebase file name need to be changed with actual values of DeploymentName and ComponentInstanceName

6.3 RULEBASE: FILE ADAPTER

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO File Adapter.

The naming convention followed for this kind of rulebase is “FileAdapter-Deployment-Component.hrb”. Here Deployment is the Enterprise Archive name and Component is the File Adapter archive name in the BW project.

6.3.1 REQUIREMENTS

If the File Adapter is started or stopped from the TIBCO Administrator, then the Hawk rulebase should send alerts and email notifications. If the File adapter is stopped abruptly due to some reason, then also the rulebase should send alerts and emails.

6.3.2 IMPLEMENTATION DETAILS

Given below are the implementation details for a Payment File Adapter. The rulebase name is "FileAdapter-Finance-FinancePaymentFileAdapter.hrb"

The rule will:

of 36


Check for the existence of the Payment File Adapter microagent. If the number of microagents becomes zero, sends a high alert along with an email mentioning that Payment File Adapter is down. If the number of the microagents becomes one, a notification and email will be sent saying that Payment File Adapter is up and running. The rule will check the microagent count for every 5 seconds.


This rulebase can be sent to the machine at any point of time. Based on the current state of the File Adapter, an alert and email will be sent.






of 36


Following changes have to be done, prior to using this rulebase for a File Adapter.


ComponentInstanceName need to be replaced with File Adapter Archive name defined under the EAR.




FileAdpaterMicroagentName property needs to be defined with appropriate value in the “HawkAC_variables.dat” file. In general as there will be more than one file adapter in the properties file, it is recommended to add a prefix to this property name.

FileAdapterDesc needs to be replaced with appropriate description of the file adapter.


6.4 RULEBASE: ADB ADAPTER This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO ADB Adapter.

The naming convention followed for this kind of rulebase is “ADBAdapter-Deployment-Component.hrb”. Here Deployment is the Enterprise Archive name and Component is the ADB Adapter archive name in the BW project.

6.4.1 REQUIREMENTS

If the ADB Adapter is started or stopped from the TIBCO Administrator, then Hawk rulebase should not start the adapter. If the ADB Adapter is stopped abruptly due to some reason, then the rulebase should attempt to start the adapter for once.

At each step, appropriate alerts and/or emails should be sent from the rulebase.


The implementation details for a LIMS ADB Adapter are similar to that of BW Process Engine defined in section 6.2.2. The rulebase name is "ADBAdapter-WaterQuality-LIMS.hrb"

of 36



Loading rules are same as that of BW Process Engine defined in section 6.2.3


Migration rules are same as that of BW Process Engine defined in section 6.2.4



Following changes have to be done, prior to using this rulebase for an ADB adapter.


ComponentInstanceName need to be replaced with ADB Adapter Archive name defined under the EAR.




ADBAdapterDesc needs to be replaced with appropriate description of the ADB adapter.


of 36


6.5 RULEBASE: EMS SERVER

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO EMS server.

The naming convention followed for this rulebase is “EMSServer-Status.hrb”.

6.5.1 REQUIREMENTS

If the EMS server is not running, rulebase should send an alert and email and try starting the EMS server. If the EMS server could not be started successfully then an appropriate alert and email should be sent.

If the EMS server is up and running, a notification and email should be sent.


Given below are the implementation details for an EMS server. The rulebase name is "EMSServer-Status.hrb"

For every 10 seconds, the rule will check whether the EMS server is running or not.

If the EMS server is not running, a low alert and email will be sent and rulebase will attempt to start the EMS server. If the EMS server is brought back successfully then notification and email will be sent. If the EMS server could not be brought back, an alert and email will be sent.


This rulebase can be sent to the machine at any point of time. Based on the current state of the EMS server, alert and email will be sent. In case the EMS server is not running, rulebase will attempt to start it.




of 36


6.6 RULEBASE: EMS QUEUES

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO EMS queues.

The naming convention followed for this rulebase is “EMSQueueTopic-Deployment.hrb”. Here Deployment is the Enterprise Archive name.

6.6.1 REQUIREMENTS

For a queue, if the pending message count exceeds the limit (even though the corresponding BW Process Engine is up and running) an alert and email should be sent. Here the limit is defined based on the message load and the monitoring interval.

At any point of time, if the pending message count exceeded the limit an alert and email should be sent. This check need to be repeated for every subsequent one hour and up to 12 hrs.


Given below are the implementation details for an EMS queue in Contact project. The rulebase name is "EMSQueueTopic-Contact.hrb"

The rule will:

of 36


Check for the .enabled file: This rule will test to see the “Contact-ContactProcess.enabled” file exists in “flags” directory. If the file exists, then the “enabled” post condition is set. If the file does not exist, then the “not_enabled” post condition is set. The rule will check for the .enabled file every 5 seconds. This post condition is used later in the rulebase to decide whether the rulebase need to take some action or not.

Check for the .running file: This rule will test to see the “Contact-ContactProcess.running” file exists in “flags” directory. If the file exists, then “running” post condition is set. If the file does not exist, then the “not_running” post condition is set. The rule will check for the .running file every 4 seconds. This post condition is used later in the rulebase.

Get the pending message count: This rule gets the queue properties for every 60 seconds. It verifies whether the pending message count is greater than 1 and BW Process Engine is running (both enabled and running post conditions exist). If this condition is satisfied then an alert and email will be sent stating that there are “n” pending messages in the queue. Once the condition is satisfied then for every subsequent one hour (and up to 12 hrs) this check will be performed and if the condition exists at that instance of time an alert and email will be sent.


This rulebase can be sent to the machine at any point of time. It will check the current state of the queue, and accordingly an alert and email will be sent.

of 36







Following changes have to be done, prior to using this rulebase for monitoring an EMS queue.

DeploymentName need to be replaced with the EAR name defined in the corresponding BW Project





QueueName property needs to be defined with appropriate value of queue name in the “HawkAC_variables.dat” file. In general as there will be more than one queue in the properties file, it is recommended to add a prefix to this property name.

ProcessName property needs to be defined with appropriate value of BW process name in the “HawkAC_variables.dat” file. In general as there will be more than one process name in the properties file, it is recommended to add a prefix to this property name.

ProjectName property needs to be defined with appropriate value of BW project name in the “HawkAC_variables.dat” file. In general as there will be more than one project name in the properties file, it is recommended to add a prefix to this property name.

MaxPendingMessages is the maximum number of messages in the queue and if the messages exceed this limit an alert and email will be sent. This needs to be replaced with appropriate number based on the requirement.

Finally, the rulebase file name need to be changed with actual value of DeploymentName

of 36


6.7 RULEBASE: EMS DURABLE TOPICS

This section will discuss on the Hawk Rulebase to monitor and manage the TIBCO EMS durable topics.

The naming convention followed for this rulebase is “EMSQueueTopic-Deployment.hrb”. Here Deployment is the Enterprise Archive name.

6.7.1 REQUIREMENTS

For a durable topic, if the pending message count exceeds the limit (even though the corresponding BW Process Engine is up and running) an alert and email should be sent. Here the limit is defined based on the message load and the monitoring interval.

At any point of time, if the pending message count exceeded the limit an alert and email should be sent. This check need to be repeated for every subsequent one hour and up to 12 hrs.

Also if the durable count for this topic does not match with the expected durable count, an alert and email should be sent. This check need to be repeated for every subsequent one hour and up to 12 hrs.


Given below are the implementation details for an EMS durable topic in WAA project. The rulebase name is "EMSQueueTopic-WAA.hrb"

The rule will:

of 36


Check for the .enabled file: This rule will test to see the “WAA-WAA.enabled” file exists in “flags” directory. If the file exists, then the “enabled” post condition is set. If the file does not exist, then the “not_enabled” post condition is set. The rule will check for the .enabled file every 5 seconds. This post condition is used later in the rulebase to decide whether the rulebase need to take some action or not.

Check for the .running file: This rule will test to see the “WAA-WAA.running” file exists in “flags” directory. If the file exists, then “running” post condition is set. If the file does not exist, then the “not_running” post condition is set. The rule will check for the .running file every 4 seconds. This post condition is used later in the rulebase.

This rule checks for the pending message count and the durable count for this topic. This test is performed every 30 seconds. The rule will:

of 36


o Get the durable count: This test verifies whether the durable count is equal to 2 or not. If the durable count is not equal to 2, an alert and email will be sent. Once the condition is satisfied then for every subsequent one hour (and up to 12 hrs) this check will be performed and if the condition exists at that instance of time an alert and email will be sent.

o Get the pending message count: This test verifies whether the pending message count is greater than 5 and the BW Process Engine is running (both enabled and running post conditions exist). If this condition is satisfied then an alert and email will be sent stating that there are “n” pending messages in the queue. Once the condition is satisfied then for every subsequent one hour (and up to 12 hrs) this check will be performed and if the condition exists at that instance of time an alert and email will be sent.


This rulebase can be sent to the machine at any point of time. It will check the current state of the topic, and accordingly an alert and email will be sent.




of 36




Following changes have to be done, prior to using this rulebase for monitoring an EMS durable topic.

DeploymentName need to be replaced with the EAR name defined in the corresponding BW Project





TopicName property needs to be defined with appropriate value of topic name in the “HawkAC_variables.dat” file. In general as there will be more than one queue in the properties file, it is recommended to add a prefix to this property name.

ProcessName property needs to be defined with appropriate value of BW process name in the “HawkAC_variables.dat” file. In general as there will be more than one process name in the properties file, it is recommended to add a prefix to this property name.

ProjectName property needs to be defined with appropriate value of BW project name in the “HawkAC_variables.dat” file. In general as there will be more than one project name in the properties file, it is recommended to add a prefix to this property name.

DurSubCount is the durable subscriber count for this topic. If the durable count doesn’t match with this number then an alert and email will be sent. This needs to be replaced with appropriate number based on the requirement.

MaxPendingMessages is the maximum number of messages in the queue and if the messages exceed this limit an alert and email will be sent. This needs to be replaced with appropriate number based on the requirement.

Finally, the rulebase file name need to be changed with actual DeploymentName

of 36


6.8 RULEBASE: CLIENT CONNECTIONS TO THE EMS SERVER

This section will discuss on the Hawk Rulebase to monitor the unauthorized client connections established to TIBCO EMS server.

The naming convention followed for this rulebase is “EMSServer-UnauthorizedConnections.hrb”.

6.8.1 REQUIREMENTS

This rulebase should monitor the connections established to the EMS server and if a connection has been established from a unknown machine (that is not part of the allowable machines), an alert and email should be sent.

The list of allowable machines should be prepared in advance as this list should be included in the rulebase.

Note: This rulebase will not prevent the connection from an unauthorized machine to the EMS server, but will generate alert and email when such connection is established.


Given below are the implementation details for monitoring the unauthorized client connections to EMS server. The rulebase name is "EMSServer-UnauthorizedConnections.hrb"

The rule will get the list of EMS server connections for every 60 seconds and verifies the host name of the machines that are connected. If there is at least one machine that is not in the list of allowable machines, then an alert and email will be sent.


This rulebase can be sent to the machine at any point of time. It will check the existing EMS server connections, and accordingly an alert and email will be sent.



Since the allowable machine names vary from one environment to another, rulebase need to be modified before deploying on each environment.

of 36




Following changes have to be done, prior to using this rulebase for monitoring unauthorized connections to EMS server.




machine1 to machine9 need to be replaced with actual machine names. Based on the requirement, the number of machines has to be changed in the rulebase.

6.9 RULEBASE: HAWK AGENT If the Hawk agent service goes down, none of the rulebases will be active and the monitoring functionality will cease. So it is essential to know the status of the Hawk agent service. This section will discuss on the Hawk Rulebase to monitor the TIBCO Hawk agent service.

The naming convention followed for this rulebase is “MonitorHawkAgent.hrb”.

Hawk agent running on machine A (having hawk domain as “domainA”) will be monitored from a rulebase that is deployed on machine B (with hawk domain as “domainB”).

6.9.1 CONFIGURATION ON MACHINE B1. In order to communicate with the Hawk agent running on machine A, there is some configuration

required to the “hawkevent.cfg” on machine B (hawkevent.cfg on machine B needs to be configured with the EMS of machine A.)

a) On machine B, open the “<tibco_root>/hawk/bin/hawkevent.cfg” file in a text editor

b) Under the ems_transport, specify the EMS server connection details.


Here the EMS server details are same as that of mentioned in section 5.4.

of 36


c) Save the changes.

d) Restart the Hawk Event service on machine B.

2. Configure the “hawkagent.cfg” (of the domain Hawk agent) on machine B to point to EMS server running on machine B.

a) Open the “<tibco_root>/tra/domain/<domain_name>/hawkagent.cfg” file in a text editor

b) Under “ems_transport” property, specify the EMS server connection details as, shown below.


Here machine B’s EMS server details need to be provided.

c) Save the changes

d) Restart the Hawk Agent service on machine B.

3. On a Windows machine, open the “Hawk Configuration” display from menu and configure the following to connect to the Hawk agent running on machine B.

a) Ensure that Hawk Domain name matches with that of domain name mentioned in the Domain Hawk agent’s “hawkagent.cfg” of machine B.

b) In the Transport tab, select the Primary Transport as EMS and provide the machine B’s EMS server connection details.

c) Click “Ok”

d) Click “No” on the dialogs that ask for restarting the Hawk related services.

Now open the “Hawk Display” from the menu and you should see the machine B’s domain Hawk agent.

6.9.2 REQUIREMENTS

If the Hawk agent running on machine A is expired or up and running, then the rulebase running on machine B should send an alert/notification and email.


Given below are the implementation details for monitoring the Hawk agent. The rulebase name is “MonitorHawkAgent.hrb”

of 36


The rule will be triggered whenever the communication with the Hawk agent running on machine A goes down or is established. In either case an alert/notification and email will be sent.

The lost communication with the Hawk agent running on machine A could be due to any of the reasons like machine A itself is down, network issues, EMS server is down or agent itself is down. So once the alert/email has been generated, analysis needs to be done to find the root cause.


This rulebase can be sent to the machine at any point of time. It will check the status of Hawk agent, and accordingly an alert and email will be sent.


Since the machine name and Hawk domain name changes from one environment to another, rulebase need to be modified before deploying on each environment.



Following changes have to be done, prior to using this rulebase for monitoring the Hawk agent service.




HawkDomainName need to be replaced with the domain name of monitored Hawk agent.

AgentBeginsWith need to be replaced with the beginning part of the monitored Hawk agent.

[email protected] and postmaster3.abc.org need to be replaced with the right email address and SMTP server.

of 36

mailto:[email protected]


6.10 GENERAL GUIDELINES

1. Since the rulebases will not be undeployed automatically while undeploynig a TIBCO component, the rulebases that are no longer required have to be undeployed manually.

2. If there is any issue with the rulebase, please check the availability of .enabled and .running files (where applicable) and accordingly create or delete these files manually to fix the problem temporarily. Rulebase need to be modified for permanent fix.

of 36

tibco hawk implemenration

Documents