Db2 S-TAP Connected but No Audit Data Behind a Load Balancer
A Db2 LUW 11.5 database runs on three Linux hosts behind a load balancer. The team deploys S-TAP 11.2 to all three hosts with GIM. The collector shows each S-TAP as Connected and the data source DB2_PROD as green. The network team confirms TCP 50000 from the application to the database and TCP 8443 from each host to the collector. A test query from the application appears in the database log, but the Guardium report Access to DB2_PROD returns zero rows. The S-TAP log shows that the K-TAP module is loaded, but the inspection engine list is empty. The previous S-TAP profile was copied from a web server template. The application uses a virtual IP that is handled by the load balancer, and the S-TAP is installed on the database hosts, not the load balancer. Identify the likely cause and the checks needed before changing the collector.
1. What is the most likely reason no audit data is captured, and why is the load balancer not the right S-TAP location?
Read the worked answer
The S-TAP is connected but has no inspection engine for the Db2 listener, so it is not capturing port 50000. The copied web-server template likely left the inspection engine list empty. The load balancer is not the right place for the S-TAP: the S-TAP must run on the database host to see the server-side session with the real database IP, and the data source must match what the S-TAP sees. Register the real Db2 hosts (or the supported cluster/VIP pattern), add a Db2 inspection engine on port 50000, and then test with a simple query. Do not change the collector or data source first; the S-TAP evidence points to the host inspection layer.
2. Outline the verification sequence across S-TAP, network, data source, and report. What should be checked at each layer?
Read the worked answer
Sequence: (1) S-TAP/GIM: confirm K-TAP loaded, S-TAP process running, inspection engine list contains Db2/50000, and sniffer counters increase. (2) Host network: tcpdump or equivalent on the Db2 host shows the test connection on 50000; confirm 8443 outbound to the collector. (3) Data source: host/IP/port matches the real Db2 listener, not only the VIP; test connection from Guardium. (4) Report: remove filters, check time zone and report period, and search by the test user. Capture each result so you can prove which layer changed.
3. How should the data source be defined if applications connect through the VIP and sessions are distributed across the three hosts?
Read the worked answer
Define the data source using the supported cluster/VIP configuration or one data source per real host, and ensure each host's S-TAP inspects 50000. Avoid installing S-TAP on the load balancer; it would not reliably see the database server-side session and adds a failure domain. Validate failover by forcing a session to each node and confirming the same test query appears.