The Support Authority: Collecting diagnostic information using the IBM Support Assistant

Learn about the functions in the IBM® Support Assistant designed for collecting diagnostic information, how to install and configure them, and how to use them in practice. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Don Bourne (dbourne@ca.ibm.com), WebSphere Serviceability Architect, IBM

Don Bourne is a WebSphere Serviceability Architect at the IBM Toronto Lab. Don joined IBM in 1996 and has been specializing in the area of serviceability since joining the WebSphere Application Server team in 2003. Currently, Don is working with the IBM Support Assistant team architecting future solutions to help users resolve problems quickly.



Mihaela Herescu (olteamh@us.ibm.com), IBM Support Assistant Development, IBM Austin Lab

Mihaela Herescu is currently one of the principal designers on the IBM Support Assistant team. In her present job, she is responsible for tasks from design to development to test, and all other aspects of getting the IBM Support Assistant tool to the market. Since she joined IBM in 2001 she has worked with J2EE and Eclipse technologies, being involved in WebSphere Application Server customer support and tool development.



Jim McVea (jimmcvea@us.ibm.com), Technical Architect, IBM Support Assistant, IBM Japan

Jim McVea is a technical architect for the IBM Support Assistant project. He joined IBM in 1998 as a Support Analyst and has worked on various support and serviceability initiatives within IBM through the years. Jim's focus continues to be identifying ways to improve the IBM Support Assistant application and analyzing areas to simplify self-help.



Adeel Omer (aomer@us.ibm.com), IBM Support Assistant Marketing and Deployment, EMC

Adeel Omer has had various IBM Support Assistant development roles for over three years and, until recently, was the IBM Support Assistant Marketing Manager. Prior to working with ISA, Adeel was involved with customer support in the WebSphere Early Programs team, providing support for the WebSphere family of products. Adeel now works for the IBM Rational Architecture Management Go-to-market team.



Daniel Julin (dpj@us.ibm.com), Senior Technical Staff Member, EMC

Daniel Julin has 20 years of experience developing and troubleshooting complex online systems. As technical area lead for the WebSphere Serviceability Team, he currently focuses on helping the team define and implement a collection of tools and techniques to assist in problem determination for WebSphere Application Server and to maximize the efficiency of IBM support. He also occasionally assists directly in various critical customer support situations.


developerWorks Contributing author
        level

03 September 2008

Also available in Chinese

In each column, The Support Authority discusses resources, tools, and other elements of IBM Technical Support that are available for WebSphere products, plus techniques and new ideas that can further enhance your IBM support experience.

This just in...

As always, we begin with some new items of interest for the WebSphere® community at large:

  • Several new product add-ons have been released for IBM Support Assistant Version 4, including one with content for Lotus® Notes Version 8, and another to help answer questions and troubleshoot problems with IBM Support Assistant itself. In general, product add-ons extend the function of IBM Support Assistant with information sources and data collection scripts associated with a particular IBM product. Hundreds of different product add-ons are available for a wide variety of products across all IBM Software brands.

  • Work continues on new and existing tools in IBM Support Assistant Version 4. This month’s releases:

    • IBM Trace and Request Analyzer for WebSphere Application Server, which was introduced in the previous Support Authority column, is now in IBM Support Assistant, in addition to the already-available download in alphaWorks.
    • An update to the IBM Monitoring and Diagnostic Tools for Java™ - Garbage Collection and Memory Visualizer.
    • An update to the IBM Thread and Monitor Dump Analyzer. Version 2.8 includes missing pictures in the readme/help files.
    • An update to the IBM Pattern Modeling and Analysis Tool for Java Garbage Collector. Version 2.6 fixes defects in the Java 6 garbage collection trace parser.

    The last two tools in the list above are examples of tools that we originally released and supported through alphaWorks, then released in IBM Support Assistant as well. In the future, expect to see a closer coordination between upgrades of tools in alphaWorks and IBM Support Assistant, and more frequent upgrades.

  • Several new and interesting installments of the WebSphere Support Technical Exchange series are scheduled for September. Of particular note:

    • Several presentations on Specialized Data Collectors in IBM Support Assistant for WebSphere Application Server and WebSphere MQ (which might be particularly relevant as a complement to the main topic in this article).
    • A new "Open Mic" session on WebSphere performance.
    • A presentation on tuning the WebSphere JVM.

    Check the WSTE Web site regularly for other sessions.

  • The IBM Support Web site for WebSphere offers a collection of maintenance download wizards to help you identify and download maintenance packages for various versions of WebSphere Application Server and other products. See the wizard for WebSphere Application Server V6.1 for an example.

  • Take advantage of the WebSphere Application Server forums and the forums for other WebSphere products on IBM developerWorks. These forums are a great place to ask questions and get answers from the broad community of WebSphere experts.

  • Finally, a reminder that WebSphere Application Server V5.1 is slated to reach the end of its normal period of support at the end of September 2008. If you have not already done so, make plans to migrate to a newer version (see this Migration planning for WebSphere Application Server document for assistance), or contact your IBM Support representative.

Continue to monitor the various support-related Web sites, as well as this column, for news about other tools as we encounter them.

And now, on to our main topic...


What is data collection, and why automate it?

A previous installment of this column introduced IBM Support Assistant Version 4.0, which provides a complete platform from which you can perform many problem determination tasks, such as:

  • Search and browse support information for many IBM products.
  • Obtain step-by-step guidance for common problem determination tasks.
  • Collect diagnostic information.
  • Run tools to analyze the diagnostic information.
  • Open PMRs with IBM Support.

All these functions are tightly integrated within the IBM Support Assistant, providing a powerful range of capabilities for both self-help situations, and for times when you need to collaborate with IBM Support. (See the IBM Support Assistant features page for a complete list of features.) This article focuses specifically on the functions designed for collecting diagnostic information, examines the various alternative methods provided, explains how to install and configure them, and also how to use them in practice.

Automated data collection is one of the most valuable troubleshooting features provided with the IBM Support Assistant. Data collection is the process whereby diagnostic information is gathered from an application or system to help identify the source of a certain behavior or issue.

The IBM Support Assistant Collect Data feature uses symptom-specific scripts to automate the cumbersome and repetitive tasks involved in data collection, such as gathering error messages in logs, setting traces, and so on, or gathering any javacores or heap dumps for analysis using various tools. Many data collection scripts automate the MustGather documents that already exist for gathering problem-analysis data. After the a script runs, the gathered information is packaged so that you can easily analyze it yourself, send it to IBM to be analyzed, or process it with tooling that can generate reports and recommendations on how to fix the problem.

Here are a few of the many benefits of automated data collections:

  • Customization: Automated data collector scripts can be specific to products and symptoms; targeted data collections gather just the right amount of information specific to the problem at hand so it's easy to transfer and analyze.
  • Efficiency: It is much faster to invoke the automated data collector than to ask a human operator to follow a few dozen steps in a troubleshooting document. There is less time spent between a support analyst and the system operator regarding questions on the various steps.
  • Repeatability: Automated data collections can be repeated over and over with similar inputs without fear of human error. This also leads to fewer "repeat collections," as results from a trusted collection script will produce the same information every time.
  • Simplicity: Automated data collections require lesser knowledge of the system and can be executed by operators unfamiliar with the working nature of the software product.
  • Privacy: Some user information, such as passwords and keystores, is automatically masked and hidden by the automated data collector scripts. This promotes better customer privacy for sensitive information.

Data collection options

IBM software is used in a multitude of processing environments; a development machine, such as a notebook or desktop computer, has different applications and user access restrictions versus a server running a different set of enterprise applications. To cater to these different scenarios, the IBM Support Assistant provides different mechanisms for running data collection:

  • Standalone workbench

    The IBM Support Assistant Workbench can be installed on a Windows® or Linux® desktop system so you can collect data from the local system. The workbench-based collection has a nice graphical interface that provides an intuitive organization of collection scripts and easy analysis of collected data. This is a logical choice for collecting data from desktop applications, such as IBM Rational® Software Architect.

  • Workbench with agents

    Using the same workbench described above, in conjunction with IBM Support Assistant agents installed on remote systems, you can collect data via the workbench's interface while running the actual collection on another system. This is a logical choice for collecting data from application middleware, such as IBM WebSphere® Application Server.

  • Portable collector

    A portable collector can be generated from the workbench for use on another system. The portable collector is a lightweight application that provides a text-based interface for running collector scripts for a specific product. It also provides a silent execution mode when run with a response file. This is a logical choice for collecting data from application middleware in cases where you do not have agents set up.

Figure 1 illustrates these different collection options.

Figure 1. IBM Support Assistant data collection options
Figure 1. IBM Support Assistant data collection options

Choosing the right IBM Support Assistant data collection method for your environment will be based on factors such as your level of pre-planning, how many systems will be serviced, target platform for data collection, whether they are connected, the authority required to install, the authority required to run, and so on. Table 1 summarizes these factors.

Table 1. Selecting data collection method
FactorsStandalone workbenchWorkbench with agentsPortable collector
Performs data collection on:System where the workbench is installed System where workbench or agent is installedSystem where portable collector is installed
Authority required to installAny system userWorkbench installs as any user agent requires root/adminNo install, only need to extract ZIP file
Authority required to runAny system userLocal: Any system user
Remote (agent): root/admin
Any user
Requires JRE on systemNoNoYes
User interfaceGraphical UIGraphical UIText-console UI
Silent executionNoNoYes (with response file)
Platform supportWindows, LinuxAgent: Windows, Linux, AIX, SolarisAny platform where a 1.4.2 JRE or higher is installed
Disk space footprintApprox. 100MB for workbenchApprox. 100 MB for workbench,
Approx. 350 MB for each agent
Approx. 10 MB

The role of product add-ons in customizing data collections

Product add-ons provide a way to extend the IBM Support Assistant with product-specific capabilities. Product add-ons contain the actual data collection scripts you will run, which have been created specifically for the needs of each product. Any number of product add-ons can be added to your workbench to prepare for performing product-specific data collections on the machine the workbench is installed on, or to generate specialized portable collectors. Similarly, product add-ons can also be added to your agents to prepare them for performing product-specific data collections remotely initiated from a workbench.

Product add-ons are installed and updated through the IBM Support Assistant Workbench Updater. Look for updates periodically as new versions of add-ons may become available.


Collection using the standalone workbench or workbench with agents

This section describes the process by which you can perform data collection using the IBM Support Assistant Workbench. Using the workbench, you can collect data either from the machine the workbench is installed on, or from machines on which IBM Support Assistant agents are installed.

Getting started using standalone workbench

On supported Windows and Linux systems where you have the IBM Support Assistant Workbench installed, you can perform data collection locally. The workbench must first be customized by adding the product add-ons for the products from which you wish to collect data. Deploying the product add-ons to the workbench can be done from the workbench itself using the Update => Find new ... => Product Add-ons menu option.

Getting started using workbench with agents

Tech Preview: Launchpad Installer

As an alternative to the standard agent installation package, you can now take advantage of a next generation "launchpad" installation that makes it easier to set up IBM Support Assistant Agent and Agent Manager. The IBM Support Assistant Launchpad Installer is a Tech Preview that is available for Linux and Windows platforms, and is currently available in English only. Download the Launchpad Installer from the IBM Support Assistant download page.

The IBM Support Assistant provides remote troubleshooting capabilities (including remote data collection) by way of IBM Support Assistant agents, which you can install on the systems you wish to manage. These agents must be registered with an IBM Support Assistant agent manager, which serves as a directory of the agents, and provides other services to help provide secure communication between IBM Support Assistant Workbenches and IBM Support Assistant agents in your distributed environment. To access the agents registered with a particular agent manager, each IBM Support Assistant Workbench must be registered with the same agent manager.

In environments where you want to perform data collection remotely, you must set up an IBM Support Assistant agent manager and your agents on the systems from which you wish to collect data. A typical IBM Support Assistant deployment in a customer environment is shown in Figure 2.

Figure 2. Typical deployment of workbenches, agent manager, and agents
Figure 2. Typical deployment of Workbenches, agent manager, and agents

As displayed, there is one agent manager in the environment, which needs to be set up before any agents are installed. The agent manager must be present, as it provides services to secure communication between the IBM Support Assistant Workbenches and IBM Support Assistant agents. It also ensures that the workbenches know where to find the agents. Depicted in Figure 2 are multiple remote agents. Each system on which you wish to perform remote data collection will require an IBM Support Assistant agent. These agents provide a remote endpoint with which the workbenches communicate to access the data collection services.

After the agent manager and agents are set up, you can register your IBM Support Assistant Workbenches to enable them to access your remote systems. During the installation of the agent manager, you will have created two unique usernames for use with IBM Support Assistant, ISAAdmin and ISAUser. The ISAAdmin username should be registered and used by workbench users that intend to administer which data collections are available to run on the remote systems. Workbenches registered using the ISAUser username can only execute data collections on agents that administrators (ISAAdmin users) have set up for them. (See the documentation included with the IBM Support Assistant Workbench for information on how to register your agent manager with a workbench.) Workbench registration is handled via the workbench’s Agent Access properties panel (Figure 3).

Figure 3. ISA Workbench Agent Access registration panel
Figure 3. ISA Workbench Agent Access registration panel

Similar to the way product add-ons can enable the workbench to perform local product-specific data collections, by adding product add-ons to your agents you will be able to perform product-specific data collections on the machines your agents are installed on.

Deploying product add-ons to the agents is a two-step process, as shown in Figure 4:

  1. Download the desired product add-ons from IBM into a local repository within the workbench.
  2. Transfer the desired product add-ons onto the agents.

As mentioned earlier, only workbenches registered with the ISAAdmin username can be used to set up product add-ons on agents, whereas the process of running data collections can be done from any workbench registered with the ISAUser or ISAAdmin username.

Figure 4. Two-step process for deploying product add-ons to agents
Figure 4. Two-step process for deploying product add-ons to agents

For more information on how to set up the agent manager and agents, register the workbench with an agent manager, or add product add-ons to your workbench and agents, see the documentation included as part of the IBM Support Assistant agent installation package and workbench.

Collecting data with the workbench

Data collection can be performed from your workbench once you have completed the steps above to set up your environment. Start by navigating to the Analyze Problem activity panel either via the Launch Activity button, or the Analyze Problem link on the workbench welcome page (Figure 5).

Figure 5. Data collection is in the Analyze Problem activity
Figure 5. Data collection is in the Analyze Problem activity

On the Analyze Problem activity screen, select the Collect Data tab to see the Collect Data panel (Figure 6).

Figure 6. Collect Data panel
Figure 6. Collect Data panel

From here, you specify what data you want to collect and how:

  1. To begin, you can select a case (Label 1 in Figure 6). The case specified in this area will be where any data collection output will be stored. Cases are meant to be areas where users store information about a particular problem they are trying to diagnose, much like a detective's case file. By clicking on the Select button, you can either select an existing case, or create a new one.

  2. Next, you will select the system (2) from which you wish to collect data. If you have not set up data collection from agents, you will automatically be collecting from your local system (My Computer). If you do have data collection set up from agents, you will see your local system plus the list of all IBM Support Assistant agents connected to the agent manager with which your workbench is registered. You will be prompted to provide credentials for any remote system you attempt to access; in this case, you must provide a valid user ID and password for a root user (for Linux and UNIX® systems) or administrative user (for Windows systems) account.

  3. The product/problem area (3) will update itself automatically to display the collections available on the specified system, based on the list of product add-ons installed on the workbench (for My Computer) or the selected agent. Once you have made your selection, you can click the Add button to add the selected collection to the collector queue (4). You can repeat this step as often as you wish to set up the data collections you need. Items can be removed from the collection queue by selecting the unwanted collection in the collection queue and clicking the Remove button.

  4. Finally, once you have added all desired data collections to the collector queue, press the Collect All button to run the collections. Collections run one at a time, starting with the first one in the queue. As each collection runs, you will see status information about the collection in the Collector Status area (5). At the same time, you will notice a new tab display, called Current Status. If you select this tab, you will see the details of what is running for the current collection.

Many collections require user input. For example, many of the WebSphere Application Server collections require the application server root directory to be provided. Whenever input is required, the data collection will pause and a dialog box with the appropriate request is displayed (Figure 7). If at any time you wish to cancel the data collection in progress, simply click Cancel.

Figure 7. User prompt during data collection
Figure 7. User prompt during data collection

Some of the files that the portable collector gathers might contain passwords and other sensitive information. Typically, IBM Support needs these files in order to diagnose a problem, but not the sensitive information contained in the files. Where possible, the collection scripts detect and hide passwords in all of the files included in the collection ZIP file. Also, a few files that contain other types of sensitive data are removed from the collection file entirely.

As collections finish, they are copied into the case you specified. To view the collected data, select the link provided in the Collector Status area (Label 5 in Figure 6), which will open up your system's file browser to the directory in which the collected data was stored.

Troubleshooting during a collection

Data collection problems:

  • For problems encountered before a data collection begins (for example, trouble connecting to an agent), check the IBM Support Assistant log and trace files for information. Navigate to Help => Support => View Log or Help => Support => View Trace menu options.
  • For problems encountered while a data collection is running, check the Current Status tab to see what the script was doing and any problems it might have encountered.
  • If you need to report a problem to IBM Support about the workbench itself, you can run the General Collection (part of the IBM Support Assistant 4.0 product add-on) on the workbench system to collect key information necessary for the IBM Support Assistant team to diagnose.

Determining agent manager status:

If a problem seems to be occurring with the agent manager, try these tips:

  • From a command prompt, run netstat -a. A list of current TCP/IP connections will be displayed. In the list, you should see the ports 9511, 9512, and 9513, and they should all be listening.
  • A verification utility is provided to check agent manager status and health. Run this command check for the text "Health Check Passed," which indicates that the agent manager is successfully running:

    [AgentMgr install root]/toolkit/bin/HealthCheck(.sh) -host <hostname> -RegistrationPW <AgentRegistratonPassword>

  • If the agent manager is running, you should be able to access its information panel from a browser. Open a browser to either of these URLs:
    • http://{AgentManagerHost or IP}:9513/AgentMgr/Info
    • https://{AgentManagerHost or IP}:9511/AgentMgr/Info

Determining agent status:

  • Run netstat -a should show the port 9510 to be listening. Ports 9514 and 9515 should also be open locally for the non-stop service used for localhost communication.
  • Run this command and confirm that the bundles listed below appear in the state shown (but not necessarily in the same order):

    [Agent install root]/ep/runtime/agent/agentCli(.sh) bundleAdmin bundles

    com.ibm.esupport.autopd.core                Active
    com.ibm.esupport.filexfer.casimpl.ca.core   Active
    com.ibm.esupport.filexfer.casimpl.core      Resolved
    com.ibm.esupport.client.product.System      Resolved
    com.ibm.esupport.inventory.service          Active
    com.ibm.esupport.inventory.interface        Active
    com.ibm.esupport.product.core               Resolved
    com.ibm.esupport.sec.core                   Resolved
    com.ibm.esupport.sec.os.core                Active
    	(This one defaults to Active but should function if just resolved.)

Collection using a portable collector

This section describes the IBM Support Assistant data collection option using the portable collector and how it can be used to collect data from systems where the IBM Support Assistant Workbench or agents cannot be installed.

The concept of a portable collector relates to exporting all of the files necessary to run a particular collection and running it in text-only console mode on a system other than the one from which it was exported. Portable collectors are generated from the IBM Support Assistant Workbench, and are clones of the IBM Support Assistant Workbench packaged data collector so that you can transport it to another machine and run it there from the command line. Since portable collectors run in text mode only, this makes them ideal for running remotely on a system that can only be accessed through a telnet session or a low-speed network connection. The portable collector simply unzips onto the problem machine and then it is ready to run. A portable collector is much smaller in size than the IBM Support Assistant application, and does not require the failing machine to have a network connection to run.

A portable collector might be a good choice for automating data collections when the problem machine runs an operating system that is not supported by the IBM Support Assistant Workbench or agent. A portable collector is also a good option when the failing system does not allow for remote root access, or if you are not likely to collect data from the failing system in the future, in which case you want a tool that is current, but that can be easily installed and removed from the failing system once data collection is done.

A typical deployment scenario for the portable collector is to install the IBM Support Assistant Workbench on one or more desktop systems in your environment, install the product add-ons you are interested in, and then generate portable collectors for specific products and run them on remote systems when a problem occurs.

How to generate portable collectors

A prerequisite for generating a portable collector is to have the IBM Support Assistant Workbench installed, after which you can generate portable collectors for the IBM products for which you have add-ons installed. To begin, navigate to the Analyze Problem activity via either the Launch Activity button, or the Analyze Activity link on the workbench welcome page (Figure 5).

On the Analyze Problem activity panel, select the Collect Data tab to display the Collect Data panel (Figure 6). Click the Create Portable Collector button (Figure 8).

Figure 8. Create portable collector
Figure 8. Create portable collector

You will be prompted to select a product, output directory, and file name. The System Collector is selected as product by default, but you can choose any of the products that you installed as add-ons from the drop-down menu. Consider the sample portable collector deployment shown in Figure 1, where the WebSphere Application Server V6.1 add-on has been installed in the workbench. In this case, you would select WebSphere Application Server 6.1 as a product. Also be sure to provide a valid output directory and output file name, since both are required. Click OK, and the portable collector is generated in the output directory as a .zip file with the name that you selected for the output file name.

Be sure to generate a new version of the portable collector when updates for the product add-ons are available on the workbench. In this way, the portable collector will have the most recent version of the scripts that drive the collection.

Running the portable collector

To set up and run the portable collector on the system from which you want to collect data:

  1. Transfer the portable collector file to the target system. You can use FTP or any other file transfer utility that is supported between the IBM Support Assistant Workbench and the target system.
  2. Connect to the target machine on which you want to do the collection. For example, you can use telnet.
  3. Set up the JAVA_HOME variable. The portable collector requires a JRE to be installed on the system from which you want to collect data. For the tool to work properly, the JAVA_HOME environment variable must be set to JRE Version 1.4.2 or greater. For example, on a Windows platform, if you have JRE 1.4.2 installed at c:\jre1.4.2, you would set JAVA_HOME using this command:

    SET JAVA_HOME=c:\jre1.4.2

    (Do not use quotes in the value of the SET command, even if your value has white space characters.) On a Linux, AIX®, Solaris™, or iSeries® platform, if you have the JRE installed in /opt/jre142, you would set JAVA_HOME using this:

    export JAVA_HOME=/opt/jre142

    Notice that the portable collector requires JRE Version 1.4.2 or later installed on your system. The Microsoft® JVM/JDK is not supported.
  4. Extract the portable collector archive file into a directory on the destination system.
  5. Check the execute permissions from the directory where you extracted the portable collector file. When running the portable collector on UNIX, iSeries, or zSeries®, make sure that all the shell scripts have execute permission. To give the file execute permission, use this command:

    chmod -R 755 `find . -name '*.sh'`

    You are now ready to run the portable collector and collect problem data from the failing system.
  6. Run the portable collector. Invoke the appropriate launch script from a command line. For a Windows system, these launch scripts are batch files. For other environments, they are shell scripts. Depending on the environment, start the data collection by running one of the following launch scripts from a command line:
    1. Windows: run startcollector.bat
    2. UNIX: run ./startcollector.sh
    3. iSeries: run ./startcollector_iseries.sh
    4. zSeries: run ./startcollector_zseries.sh

Once the collection is started, you will be asked to provide input to several questions, such as the name of the data collection ZIP file, and other product specific information.

For the WebSphere Application Server security problem example that was mentioned previously, you have to enter the WebSphere Application Server root directory, the Admin user name and password, other information about how the problem can be recreated, and so on (Figure 9).

Figure 9. Portable collector input prompts
Figure 9. Portable collector input prompts

Since the portable collector runs in a text mode, there are no selection lists or entry fields for user input. Instead, available choices are presented as numbered lists and you enter the number of your selection followed by the Enter key. Input fields are transformed into prompts, at which time you enter your response and press Enter. If necessary, you can stop the collector tool by typing quit.

When the data collection is complete, the output is another ZIP file that can be manually transferred to IBM Support or back to the machine on which IBM Support Assistant Workbench is installed. On the workbench, the output ZIP file can be examined locally, and then sent to IBM Support for analysis, the same as with other collections performed in the IBM Support Assistant Workbench. Depending on the product for which it was generated, the portable collector can handle the details of the FTP transfer from the failing system to IBM. You will need to provide a PMR number so that the collected problem data can be associated with it. Figure 10 shows the FTP options available at the end of the WebSphere Application Server Security collection script.

Figure 10. Portable collector FTP prompt
Figure 10. Portable collector FTP prompt

Silent collection

Most data collector scripts in the IBM Support Assistant are interactive in nature and require responses to critical questions. These questions are asked during the data collection process with user prompts. For example, a WebSphere Application Server script might ask you which profile or node to collect data from. However, there are situations where this might not be useful:

  • You want to run the same data collection multiple times and providing the same answer on multiple executions is cumbersome.
  • You want to run the data collector without human interaction so that it can be kicked off automatically and completed without any operators.

In those cases, the "silent” data collection capability of the portable collector is extremely useful. To achieve this, you first create a "response file" that contains the answers to all the questions for a certain run through the data collector. The next time the same data collection needs to be executed, you simply provide the response file when starting the portable collector and the answers that were previously provided will be used to answer all the questions. Response files can be tweaked and modified to vary the answers to perform different data collections too.

To create a response file, you simply invoke the portable collector with the -record option, followed by the name of the response file, For example, in a Linux environment, you would run:

./startcollector.sh –record  was61-response.txt

When running in this mode, you will be taken to an ordinary interactive session, where you supply the responses to the script's prompts. In addition to influencing the current collection, however, your responses are also saved in the file that you named. Once the interactive session has completed, you can use this response file to execute the same script in the future without the need for explicit user input.

For example, to run the portable collector in silent mode in a UNIX environment using the response file that you recorded, run:

./startcollector.sh  was61-response.txt

Figure 11 shows a sample input script file. The first line specifies the collection ZIP file name for the collection. The next "1" indicates that this file should be used for this script execution. The sequence of numbers following it navigates down through the menu tree, to reach the point where it can invoke the WebSphere Application Server security collection script. Next are the input fields where you supply the WebSphere Application Server installation directory. The final numbers and text represent your responses to various dialogues within the WebSphere Application Server Security collection script.

Figure 11. Sample response file
Figure 11. Sample response file

The response file is a plain text file, so you can edit it to change the user's responses as needed. For example, if you want to run the portable collector on a different system than the one on which the response file was recorded, you might need to adjust some of the values in the response file. Assuming the WebSphere Application Server security problem mentioned before, you might need to update the response file with the WebSphere Application Server installation directory, administrator user name, and password for the new system.

When using response files, remember that sensitive information, such as user names and passwords, might be stored in these files, so it is important that you manage these files in a manner that prevents unauthorized access to sensitive information. Also, not all data collections are suitable for the silent collection option. Some data collections always require some interaction with the user. For example, you might be asked to reproduce the problem during the data collection so the appropriate log and trace files are collected. In this case, silent collection is not capable to record and reproduce this step.


Summary

Now that you've learned about using IBM Support Assistant's data collection feature and how you can use it to automate the process of collecting problem determination artifacts, you're ready to actually do something with it. When you build a data collection, what you've built is just an archive file that can be opened with most data compression utilities. You can browse the contents yourself to look at log files, configuration files, and so on, if you are doing some self-help analysis. If you are working on a problem with an IBM Support Analyst, you can get the information to them by attaching the archive file to your Electronic Service Request, e-mailing it, or sending it via FTP to IBM. The transport mechanism might vary from one situation to the next, but the important point is that you've automated the steps to pull together the correct information for further analysis.

We hope that this article provided you with a good introduction to the capabilities of the data collection functions provided by IBM Support Assistant, as well as the various alternative modes of operation available to suit different environments. The IBM Support Assistant Team welcomes your feedback, which you can send by using the Submit Feedback option from the Help menu in the IBM Support Assistant Workbench itself.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=335089
ArticleTitle=The Support Authority: Collecting diagnostic information using the IBM Support Assistant
publish-date=09032008