Windows: S-TAP load balancing models and configuration guidelines

Understand the S-TAP load balancing models, and choose the one appropriate to your setup

Each load balancing model is described here, along with its specific parameter requirements.

Note: This topic describes S-TAP load balancing, and not Enterprise Load Balancing.


S-TAP® sends traffic to one collector (primary) and fails over to the secondary as needed. The S-TAP agents are configured with a primary and at least one secondary collector IP. If the S-TAP agent cannot send the traffic to the primary collector for various reasons, the S-TAP agent automatically fails over to the secondary. It continues to send data to the secondary host until either the secondary host system becomes unavailable, the primary host becomes available again, or until the S-TAP is restarted (at which point it attempts to connect to its primary host first). If the secondary host system becomes unavailable, it fails over to another secondary if there is one defined. In the second case S-TAP fails over from the secondary Guardium® host back to the Primary Guardium host. It's recommend setting up a primary and up to two secondary collectors. You can either define one collector as a standby failover collector only, or a few failover collectors. When using one standby failover, one collector is usually sufficient for 4-5 collectors. When using a few failover collectors, each one should run at a maximum 50% capacity, so that there are always resources for additional load. Choose the setup that works best with your architecture, database, and data center layout. If the primary becomes available, the S-TAP fails back from the secondary Guardium host back to the Primary Guardium host.

The S-TAP restarts each time configuration changes are applied from the active host.

In the S-TAP Control window, Details section: set Load Balancing to 0; In the Guardium Hosts section: add at least one secondary Guardium Host.

Additional failover configuration should be left at the default values, except by advanced users.

Before designating a Guardium system as a secondary host for an S-TAP, verify these items.
  • The Guardium system must have connectivity to the database server where S-TAP is installed. When multiple Guardium systems are used, they are often attached to disjointed branches of the network.
  • The Guardium system must not have a security policy that will ignore session data from the database server where S-TAP is installed. In many cases, a Guardium security policy is built to focus on a narrow subset of the observable database traffic, ignoring all other sessions. Either make sure that the secondary host will not ignore session data from S-TAP or modify the security policy on the Guardium system as necessary.

Load balancing

This configuration balances traffic from one database onto multiple collectors. This option might be good when you must monitor all traffic (comprehensive monitoring) of an active database. (Note that for outliers detection, the collectors need to be under the same aggregator and central manager in order for the aggregator to process all related data.) When the generated traffic is large and you need to house the data online on a collector for an extended period, this method might be your best choice because it performs session-based load balancing across multiple collectors. An S-TAP can be configured in this manner with up to 10 collectors.

In the S-TAP Control window, Details section: set Load Balancing to 1 for load balancing.


With Grid, the S-TAP communicates to the collector through a load balancer, such as f5 and Cisco. The S-TAP agent is configured to send traffic to the load balancer. The load balancer forwards the S-TAP traffic to one of the collectors in the pool of collectors. You also can configure failover between load balancers for continuous monitoring if the load balancer should fail.

The persistence of S-TAP is configured by the failover parameters:
  • TAP_MIN_TIME_BEFOREFAILOVER: The time interval, in minutes, after which the S-TAP switches to secondary Guardium system if: it cannot connect to its primary Guardium system; it can connect to its primary Guardium system but cannot write to its buffer. Default is 5.
  • TAP_MIN_HEARTBEAT_INTERVAL: Maximum time the S-TAP attempts to write to the primary Guardium system buffer before attempting to write to the secondary Guardium buffer. Default is 30 sec, meaning it tries to write at least 5*60/30 times before failover.

S-TAPs in the F5 environment upload their log files and results of running diagnostics (all files from ..\Logs folder except for memory dumps) to the active collector and central manager (if exists) to the location ./var/IBM/Guardium/log/stap_diagnostic/

In the S-TAP Control window, Details section: set Load Balancing to 3 for the grid model.

In addition, set:
  • All can control=1
  • Guardium Host=<the IP of the Virtual IP of the balancer, to which all S-TAP database clients point to>


In redundancy, the S-TAP communicates its entire payload to multiple collectors. The S-TAP is configured with more than one collector (often only two) and communicates the identical content to both. This option provides full redundancy of the same logged data across multiple collectors. It can also be used for logging data and alert on activity at different levels of granularity.

In the S-TAP Control window, Details section: set Load Balancing to 2 for redundancy.