Must gather for UNIX-Linux S-TAP

You can run must gather on the collector from the UI and in the CLI, and on the database by using the guard_diag script.

You can run must gather by either of these methods.
  • In the S-TAP Control page: Under the specific S-TAP®, click send command. In the S-TAP Commands window, select the command STAP logging, check Run Diagnostics, then click Apply. The logs will get uploaded to the Support Information Gathering Results page.
  • Log in to the database server. The location of the diagnostics script (guard_diag) depends on the installation method.
    • Shell: The directory you specified during the S-TAP installation. By default, /usr/local/guardium/guard_stap
    • GIM: /usr/local/guardium/modules/STAP/current/guard_diag
    • .rpm: /opt/guardium/guard_stap/guard_diag. This is hard coded, and cannot be changed.

    The script prompts for the location if the script cannot automatically determine where S-TAP is installed. The run time is a few minutes. If no output directory is specified, the script saves the generated .tar file in /tmp. When the script runs and enables logging from the GUI, the .tar file is placed in /var/tmp. The file name is derived from the server name, and the time and date it ran. It always starts with diag.ustap.

    The verbosity of the output is set by the diagnostics, and does not need modification.

By default, diagnostics are uploaded to the Support Information Gathering Results page in the collector. The upload is controlled by the guard_tap.ini parameter upload_feature. The default value is 1. For more information, see upload_feature.

The S-TAP log file records the successful transfer of a diagnostics .tar file to the appliance. It also records a failure message if the .tar file is not sent to the appliance, with debug details on the failure.

General system data collected:
  • Uname -a
  • List of kernel modules installed
  • Output for one cycle
  • Uptime
  • Processor number and type
  • Dump of most recent syslog
  • Netstat output
  • IPC list
  • Disk free statistics
  • Copy of /etc/services
  • Directory listing of /etc
  • Various platform-specific information
  • Contents of /etc/inittab
S-TAP Data collected:
  • S-TAP version
  • Contents of guard_tap.ini
  • Ls -l on the K-TAP device nodes
  • A-TAP diagnostics (output of the atap_must_gather.sh) (see S-TAP is not capturing A-TAP traffic)
  • All Exit diagnostics (for Db2, this is the output of the db2_exit_health_check.sh. See also Linux S-TAP is not capturing Db2 exit traffic.)
  • 30s trace of S-TAP
  • K-TAP statistics
  • List of all the files in the installation directory
  • Verbose debug log for K-TAP (2) and S-TAP (4)
  • Database configuration information: Either files, or output from a database command, depending on the database type. For example, Oracle: listener.ora, sqlnet.ora, and tnsnames.ora; Informix: onconfig.* and sqlhosts.*"; Sybase: interfaces and *.cfg; Db2: output of Db2 command: db2 get dbm cfg
Limitations:
  • Tusc is not installed on all HP-UX operating systems, so tracing the S-TAP PID does not work.
  • gzip isn't always installed on the system. The fallback is to compress (final extension of .tar.Z) and failing that, the .tar file is placed in the output directory.
  • Topas output on AIX is best interpreted by the terminal since it contains control codes that make it mostly unintelligible when it is opened in an editor.
  • The non-root S-TAP has a number of issues related to the diagnostics script.
  • In Linux, /var/log/messages is only readable by the root.
  • Some Solaris operating systems might not be configured correctly, which causes netstat to print an error.
  • The path for the non-root user is rather basic, and as a result, some commands might not run at all. Notably, this known issue happens on HP-UX with gzip.
  • Platform-specific requirements:
    • S-TAP: None
    • Linux: None
    • AIX: topas
    • Solaris: top, prtdiag, psrinfo
Supported platforms:
  • Linux
  • HP-UX
  • AIX
  • Solaris