Collecting data for: Tivoli System Automation for Multiplatforms

Technote (FAQ)


Question

Would you like a tool that automates the collection of troubleshooting data for TSAMP, instead of manually trying to find, format, group, and collect all the information that Support needs to remotely diagnose your problem ?

Answer

Table of contents:
General introduction to the getsadata utility
How-to instructions for using getsadata
Additional detail usually requested by IBM Support
Sending getsadata output/data to IBM Support
Downloading the getsadata package


General introduction to getsadata
The getsadata utility will gather environmental, configuration, log, and trace data specific to TSAMP (Automation component), RSCT (cluster component), and TSAMP's Base Operations Console (if installed).

It can collect system logs as well as product install and runtime logs. It can format and collect the IBM.RecoveryRM, IBM.GlbResRM, IBM.Test, and IBM.StorageRM traces. RSCT's ctsnap utility can also be run and its output collected. The getsadata utility will tar & compress all the data it collects output into a single tarball and provide final filename details and location after it has completed executing.


Instructions for using getsadata
The utility generally needs to be run on each server in the domain in order for Support to have a complete picture of what it going on. Also, maximum data collection is only possible if the domain is online. If the domain is not online, you will be prompted to help getsadata decide how to best proceed ... read the on-screen prompts provided.

Important points to note:

1. Execute 'getsadata' with root authority. Running as any other user will likely result in data Support cannot use to help you.

2. Run getsadata on all nodes in the domain where possible, but only after first running it on the node hosting the "master" automation engine (IBM.RecoveryRM), identified by using either of the following commands (executed from any node):
lssamctrl -V
lssrc -ls IBM.RecoveryRM | grep -i master

3. It is important to collect data as soon as possible after a problem is observed in order to collect all log and trace data before data is lost (First In, First Out, fixed size trace files). This doesn't necessarily apply if your environment has trace spooling enabled.

4. It is equally important to run the utility before any manual (user) recovery efforts are attempted. This will ensure an accurate snapshot of the current states which can then be correlated with the logs and traces collected.


Usage :

For maximum data collection, run the utility using the following syntax (on each server) :
./getsadata -all

For minimum data collection, so as to just take a quick snapshot of a current situation, run the utility using the following syntax :
./getsadata -quicksnap

If you want to see more detailed information about the commands being run, add the –verbose flag

If you want to use a different output directory instead of /tmp (default), add the –outdir <dir> flag, for example :
./getsadata -all –outdir /var/log

To just collect all log and trace data, then run the utility using the -logs and -traces flags as follows :
./getsadata -traces -logs -noprompt

To just collect just spooled trace data for a defined time period, use the following format :
./getsadata -spoolfrom YYYY-MM-DD[.hh[:mm]] -spoolto YYYY-MM-DD[.hh[:mm]]

To exclude a particular item from the collection, there are -skip* options available. For example, to collect all data "except" for ctsnap, run the utility using the following syntax :
./getsadata -all -skipctsnap

For more usage help, run the utility with the -h or -? flag, for example :
./getsadata -h


Results :

After running the utility on a node, the result will be a single tar file located and named like the following :
/tmp/<MMDDYY_hhmmss>-<node_name>-sa_data.tar.gz|Z

You should end up with a tar file named similar to that shown above for each of the servers where you run getsadata. Collect the tar files (one from each node) into a single directory and create a single tar file named using the PMR number so that it gets routed correctly when you FTP it to IBM, for example:
cd /tmp
tar cvf ppppp.bbb.ccc .tar *-sa_data.tar.gz



Additional detail usually requested by IBM Support
1) Provide the date and time that the problem event occurred. This is particularly important if there has been a lot of automation activity resulting from multiple testcases or multiple recreates or recovery activity.

2) Provide the name(s) of the affected resource(s). It is highly recommended that you capture the output of 'lssam top', at the time you observed the problem, as this will show Support what you observed and when (date and time is printed at the top of the output). Provide the name of the node where you ran lssam and the userid you used.

3) Provide the node name (hostname) where the problem occurred. If you intend describing events using the terms "primary" and "standby" or "active" and "backup", please let us know which is which in relation to node names, so we can effectively use the diagnostic data collected by getsadata.

4) For DB2 customers, if you intend including snippets of db2diag.log messages, please indicate which node the data is from. Also consider showing snippets from the syslog, that is, the logger messages written by the DB2 automation scripts (syslogs do show the host name, as well as useful date/timestamp information, hence are of great value to Support).



Sending getsadata output to IBM Support
At any time, you can re-run the getsadata utility with just the –ftphelp flag and it will only display instructions on how to name the file and how to FTP to IBM :
./getsadata -ftphelp

Using Binary Transfer Mode, anonymously FTP the final tar file ( ppppp.bbb.ccc .tar) to IBM:
Server: " ftp.emea.ibm.com"
Within directory: " /toibm/tivoli/"
An automatic update will be added to the PMR once the data arrives.

Alternate upload method through your browser: http://www.ecurep.ibm.com/app/upload

Please include some details about the data where appropriate, for example a timeline of events (when the problem occurred and when actions were performed, both before and after the observed problem).

Electronically opening a PMR (SR) eliminates waiting on the phone to provide general information to the HelpDesk center. And providing output data from the execution of getsadata at the time you electronically open a PMR will ensure the data is immediately available to a Support engineer, thus allowing quicker initial diagnoses.



Downloading the getsadata tarball package
IBM's recommended browser is Firefox. It is therefore recommended that you use Firefox to download the attached tar file. Chrome has also been tested with success.

WARNING: Experience has shown that Internet Explorer (IE) can corrupt the tar file during its download process, though this may depend on the version of IE being used ... sorry, no IE version details available.

Ensure you always FTP the tar package using binary mode. Un-tar on the system where it is to be used, preferably in its own sub-directory.

Click on the following icon link to download the latest version (v8.4.0) of the getsadata utility :

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Tivoli System Automation for Multiplatforms

Software version:

2.2, 2.3, 3.1, 3.2, 3.2.1, 3.2.2, 4.1

Operating system(s):

AIX, Linux, Solaris, Windows

Reference #:

1285496

Modified date:

2014-06-24

Translate my page

Machine Translation

Content navigation