IBM Support

How to collect a good slon trace for Guardium support to diagnose missing Login Info issues

Question & Answer


Question

What are the steps to make sure you are collecting a good slon and STAP debug traces to diagnose issues in InfoSphere Guardium related to missing information from the Login Packet such as missing DB Username, Source Program or Database Name?

Cause

A "good" slon trace and matching STAP debug trace are relevant pieces of diagnostic information for Guardium Support to investigate issues related to missing information from Login Packets, such as missing DB Username, Database Name, Source Program.
Sometimes a delay in obtaining a "good" trace translates in delay in resolving the problem.
This document explains how to make sure you collect a "good" slon and STAP debug traces with information needed to diagnose this type of problems.

Answer

You need to collect 2 traces:

    • STAP debug trace on the Database Server where the Guardium STAP is installed
    • slon trace on the collector

Refer to the following Technotes in the Related URL section for details on collecting each of these traces:

    • For details on how to collect an STAP debug trace, refer to Technote "Collecting the STAP debug trace". Follow instructions in the "STAP diag from GUI" tab
    • For details on how to collect a slon trace on the collector side, refer to Technote "Collecting a slon trace".

Before you start:
    1. Both traces must be running at the same time
    2. You must generate a "fresh/new" database session/connection that recreates the issue while both traces are still running. Login packets are only sent when db connection is first opened. So, it is crucial that a New connection is established so we can capture the moment when the Login Packet is sent.
    3. These traces are timed so, make sure you provide enough time for the duration of the trace, to allow you open the fresh/new session from a client and recreate the problem
    4. Add "Session Start", "Client Port", "Server Port" to your existing report (or create a new report containing at least these fields). Keep refreshing your report shortly after you recreate the issue with the new connection until you see the new session with the problem you are trying to recreate.
    5. Make sure you indeed recreated the issue with a NEW Session. For example, if the issue you are trying to recreate is missing DB UserName, make sure a NEW Session was started while the traces were running and that this session actually missed the DB Username. A good method to make sure the session started while the traces were running is to look at "Session Start" and make sure the traces were still running at that time on both, collector (slon trace) and STAP (STAP debug trace).
    6. Do not close the session too soon, leave it open for at least 5 minutes. Sessions that are too short may not allow enough time for the sniffer to analyze the Login Packets.

      When sessions are too short, login packets may be missed because the session is already gone by the time the sniffer is going to analyze the login packet and may miss to make the correlation with the correct session (expected behavior). Leaving the session open (ie. not closing the connection) will not harm what we need to test. however , closing it too soon, may have undesired effects. So, leave it open to be on the safe side.
    7. Send the following details corresponding to your test:
      • Report showing session with missing fields.
      • Explicitly indicate which was the session in this report, that was collected while the slon and STAP traces were being collected.
      • Application name you used to generate the session, database name, DB User you connected as, type of connection ( TCP or local?), sql statement, if any, you ran in this session (if relevant for the issue you are trying to recreate).
    8. After completing the test, collect:
      • Resulting STAP debug trace file on the Database Serverr (check Collecting the STAP debug trace in the Related URL Section below for details)
      • Resulting slon trace on the Guardium collector (check Collecting a slon trace in the Related URL Section below for details)
      • Current sniffer must gather from the collector (cli command: support must_gather sniffer_issues)
      • Current STAP must gather from the STAP on the Database Server (check Collecting data for Guardium STAP technote in the Related URL Section below for details)
      • Notes:

        - Use tab "Unix Diag" for Unix STAP, or "Windows diag" for Windows STAP.

        - Do not download the guard_diag or diag.bat scripts from the Technote, if your STAP version is v8.2 or later. Use the script already installed in the STP installation directory as it is up to date for your current version. The scripts attached to the Technote are only intended for older versions of STAP (like v8.01) when the guard_diag and diag.bat scripts were not shipped with the product.

[{"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"--","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"8.0.1;8.1;8.2;9.0;9.1","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
16 June 2018

UID

swg21673042