TIBCO Hawk Rulebase Standard Guidelines

By

Tushar Jain

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 1 of 9

Version 1.0

Contents

1. Introduction ....................................................................................................3 1.1 Purpose .........................................................................................................3 1.2 Scope.............................................................................................................3 2. Hawk Overview ..............................................................................................3 2.1 Introduction to Hawk Rulebases...........................................................3 2.2 Hawk Microagents ...........................................................................................3 3. Rule-bases & TIBCO infrastructure monitoring ...................................4 3.1 Model TIBCO infrastructure monitoring .............................................4 3.2 RuleBase.......................................................................................................4 3.3 Basic Types of Rulebase Monitoring....................................................4 4. Hawk development Guidelines......................................................................5 4.1 General Naming convention...................................................................5 Clarity..............................................................................................................5 Spaces and Special Characters .........................................................................5 Capitalization...................................................................................................5 Initial Character ...............................................................................................5 4.2 TIBCO Guidelines & Naming Conventions .........................................5 4.2.1 Rulebasemap...........................................................................................5 4.2.2 Rulebase ...................................................................................................6 4.3 Rulebase configuration ............................................................................6 4.3.1 Rulebase configuration types.............................................................6 4.3.2 Manual Configuration of Hawk Rulebases......................................7 4.4 Version Control...........................................................................................7 5. Design Considerations.....................................................................................8

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 2 of 9

Version 1.0

1. Introduction
1.1 Purpose
The purpose of this document is to recommend naming standards, guidelines and organizational methods, based on standards and TIBCO Best Practices. The focus is to follow naming standards & use the best practices for the hawk rule base development in the XXXX Integration project.

1.2 Scope
The scope of this document is to cover the Define standards & guidelines to be followed for EMMA Project Organization Design considerations

2. Hawk Overview
2.1 Introduction to Hawk Rulebases
A TIBCO Hawk agent monitors managed objects by processing rulebases, which are named collections of rules that contain management logic. For general monitoring tasks, several default rulebases are installed with TIBCO Hawk software. Rules monitor parameters of an operating system, application or other managed object and perform tasks. To simplify administration, rules in a rulebase should be related. Multiple rules in the same rulebase can monitor a particular application or system function. Every rulebase contains rules which are made up of data sources, tests, and actions. Efficiently written hawk rule bases really helps to manage the highly scalable, flexible solutions with an easy automated monitoring. The guidelines for the hawk rulebase development will help to build the robust & efficient monitoring systems.

2.2 Hawk Microagents

The TIBCO Hawk agent uses processes known as microagents to collect information and carry out various tasks. These microagents are divided into specific tasks known as methods. Methods configure applications to collect information and perform tasks. Methods can be called directly or through a TIBCO Hawk rulebase.

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 3 of 9

Version 1.0

3. Rule-bases & TIBCO infrastructure monitoring

3.1 Model TIBCO infrastructure monitoring
Standards architecture of TIB-Hawk based monitoring is depicted below-

3.2 RuleBase
A rulebase is a collection of rules that you create for the agent to monitor. For example, a rulebase might monitor the health of an application and take corrective actions if they are necessary. A rulebase consists of three components: a data source (microagent method), a test (if-then), and an action (alert, notify, script or method execution).

3.3 Basic Types of Rulebase Monitoring

To monitor the TIBCO infrastructure via hawk rulesbases there are some common suggested objects/ monitoring points that must be taken care while designing/creating rulebases. 1. Process existence monitoring: determine and start one instance or n number of instances of an application. 2. Application logfile parsing: pattern match for status, warning or error messages on each new line and take actions accordingly. 3. Process resource monitoring: check for CPU usage, memory usage, file system usage, etc. with upper/lower bounds/thresholds.

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 4 of 9

Version 1.0

4. Hawk development Guidelines

4.1 General Naming convention
Clarity is the number one guideline for names, within reason. A user unfamiliar with the specifics of the implementation should be able to understand the function of any object by its name itself.

Clarity
Clarity is the number one guideline for names, within reason. A user unfamiliar with the specifics of the implementation should be able to understand the function of any object by its name, and its position in a hierarchy. To that end, acronyms should be avoided unless they are well known through the entire company. Examples of acronyms might be: DB database The exception to the above rule is when spelling out the full name would make something less clear, not more.

Spaces and Special Characters

Spaces and special characters in names is one of the oldest arguments, mostly because there are so many options. The general guidelines are Use spaces in folder names, dont use spaces in Process Design names, or process component names. If a special character is necessary, use the symbol.

Capitalization
TIBCO objects are all started with capital letters, and then capitals are used in the name as they correspond to correct English.

Initial Character
The first character of any name should be alphabetical (A-Z), not numeric.

4.2 TIBCO Guidelines & Naming Conventions

Each rule in a rulebase specifies a data source, tests to be applied to the data, and consequences. Although the rules in a single rulebase can monitor anything, we recommend that they all monitor parameters relating to a single application or system. In other words, each rulebase should be designed to monitor a particular application or system.

4.2.1

Rulebasemap

A rulebase map is a configuration object that maps rulebases to TIBCO Hawk agents on your network. It directs TIBCO Hawk agents or groups of agents on your network to load particular rulebases at startup. For example, using a

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 5 of 9

Version 1.0

rulebase map you can instruct an agent to load a rulebase designed specifically for the operating system where it runs. To efficiently manage agent configuration, an entire enterprise should use the same rulebase map. Configuration objects access the rulebase map using the same configuration source they use to access rulebases Following naming guidelines should be used for the rulebase map The format for a Rulebasemap is RBM_<BW_Project/System>_<Component> Example: RBM_APP1-APP2 <BW_Project/system> can be APP1-APP2 <Component> can be Adapter,BWEngine, Log, Database etc.

For example, App1-App2 in context to XXXX Integration project, following RulebaseMap can be created 1. RBM_ APP1-APP2_AdapterInclude all the rulebases which monitors the Adapter ( Publihser, Subscriber,RR) status. 2. RBM_ APP1-APP2_BWEngineInclude all the rulebases, which monitors the BWEngine. 3. RBM_ APP1-APP2_Log Include all the rulebases, which monitors the log files. 4. RBM_ APP1-APP2_DatabaseIncludes the rulebases, which monitors that the data is flowing from End-to-End.

4.2.2

Rulebase

A rulebase is a configuration object that provides the rules for the monitoring activities that are to be autonomously performed on an agent. The format of the Rulebase is RB_<BW_Project/System>_<component> _<Function> Following are a few examples RB_ APP1-APP2_Logfile_checkPattern RB_ APP1-APP2_ADBAdapter_checkStatus

4.3 Rulebase configuration

4.3.1
Rulebase configuration types
Rulebases used by the agent are maintained in a Rulebase object. Agent stores and retrieves the each Rulebase to and from a rulebase file. The filename of the rulebase correspond to name of the rulebase and has an extension of .hrb. If the filename of the rulebase does not correspond to the name of the rulebase, TIBCO Hawk Agents will not load the rulebase and an

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 6 of 9

Version 1.0

error is logged. When TIBCO Hawk Agents is running in auto config mode, rulebases are loaded from the autoconfig directory. When TIBCO Hawk Agents is running in repository config mode, rulebases are loaded from the specified repository

4.3.2

Manual Configuration of Hawk Rulebases

In the EMMA Project we will be using the Manual Loading of the rulebases. In Manual Configuration mode, the agent performs the following sequence of tasks to load startup rulebases: At startup, the agent searches the configuration source for schedules, then for a rulebase map. The agent searches the configuration source and loads all rulebases specified in the rulebase map. The agent searches the configuration source for any additional rulebases specified in the rulebases command line option and loads them. If these rulebases have Include lists of other rulebases, the agent searches the configuration source for included rulebases and loads them. After an agent is started in Manual Configuration mode, we can load additional rulebases by invoking the RuleBaseEngine: loadRuleBase() or RuleBaseEngine:loadRuleBaseFromFile()

Note: A file will be maintained which would contain the list of rulebases that
will be monitored. If any rulebase fails to load from the list specified an alert would be triggered.

4.4 Version Control

Perforce/VSS or any Version control software will be used to keep all the hawk rulebases, rulebasemap & scripts etc. It works as a central repository for all hawk inventories XXXX Project Folder in Perforce //XXXX /PROD /APP1_APP2 /APP3_APP1 RB_APP3_APP1_ADBAdapter_checkStatus.hrb /TEST /APP1_APP2 /APP3_APP1 RB_APP3_APP1_ADBAdapter_checkStatus.hrb

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 7 of 9

Version 1.0

Rulebases for Production Environment

All the rulebases for Production environment will be maintained in the //XXXX/PROD folder in perforce. The latest version the production rulebase will be exact copy of the production environment.
Rulebases for Test Environment

All the rulebases for Test environment will be maintained in the //XXX/TEST folder in perforce. The latest version the rulebase will be exact copy of the Test environment. Any new rule created must be first tested in the dev environment & later on baseline into the //EMMA/TEST folder on perforce.

5. Design Considerations
While creating a hawk rule base there are some important points that should be taken care. These points are based on the operation team experience in managing the NetApp TIBCO infrastructure.

1. Limit mails on Tibco duty pager

When hawk is not able to start the adapter/Process Engine due to some data error, then hawk retries infinitely, which results in multiple duty pager alerts. We can limit the pager alerts by setting max no. of retries by the hawk. We can tune hawk in such a way that after a defined number of attempts it will not retry to start and it can send an alert on duty pager for Manual intervention.

2. Notification of successful start of a process

On successful start of process/adaptor, currently hawk sends no notification. An e-mail alert can be configured after the successful start of the adapter/engine. This can be implemented using Clear Actions in the advanced tab.

3. Escalation mail to Tibco duty pager in case of failure

Hawk can be configured to send an escalation mail if it is not able to start the components after the predefined maximum number of attempts.

4. Clear condition
When the adapter terminates, the hawk detects the condition as False. After executing the predefined rules this should ideally be set to True immediately. In the current implementation, this is being cleared after 300 seconds. In a synchronous environment it is recommended to set it immediately instead of waiting for 300 seconds.

5. To monitor the high data rate log file

In the rulebase for high data rate log files monitoring, use logfile:onNewLineWithPatternFile method instead of onNewLine method. The first method will be more efficient in monitoring the high data rate log file.

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 8 of 9

Version 1.0

6. Event Service to monitor hawk agent

It is recommended that at least one Event Service per subnet must be implemented so that operation team will be notified if any of the systems go down. If the Event Service does not receive heartbeats from an Agent, then it can be configured to send an e-mail notifying the dead agent's hostname or IP address. In addition, Event Service will capture all the Hawk alerts and events into a file for audits later. This provides a backup to the use of Hawk display. We can consider the Event Service as an alternate console but without GUI.

http://architecture-soa-bpm-eai.blogspot.com/ http://oracle-fusion-middlware.blogspot.com/ http://architectureanddesignpatterns.blogspot.com/ Page 9 of 9

Version 1.0