RCUG 4 Getting Started
RootCause User Guide
The Setup Script
Installation of RootCause from CD-ROM or compressed file is covered in Chapter 2, "Installing RootCause".
After installation, but each time before you run RootCause, you will need to execute its setup script. This will set the necessary environment variables (e.g. APROBE, PATH, etc.). This is typically done by each user's login script because it usually needs to be done only once per login session.
The RootCause installation automatically creates a setup script that must be executed before RootCause can be run. This script is located in the root of the directory where RootCause was installed.
For example, if you installed RootCause in directory
/opt/aprobe, then you would execute the appropriate one of the following scripts to set up the environment before using RootCause. The first of these scripts is for ksh or bsh users; the other is for csh users:
You must execute this setup script in your shell every time you log in or otherwise reinitialize your environment. Therefore it is a good idea to put the appropriate command above in your
~/.profile (for Korn or Bourne shells) or
~/.login file (for C shell). See
"RootCause and Different Shells" for information about other shells.
This script defines the
APROBE environment variable and appends
$APROBE/bin to your PATH environment variable. It also sets defaults for both APROBE_REGISTRY and APROBE_LOG environment variables. If the registry does not exist, the setup script will create a default one.
The setup script also defines aliases that are not inherited by subsequent non-login shells you may open, such as with the
xterm command. To ensure that these aliases are defined (specifically
rootcause_off), you may add the command:
~/.kshrc file if you are using Korn shell, or the command
~/.cshrc file if you are using C shell.
Now you're ready to run RootCause.
The RootCause Process
Using RootCause is typically an iterative process with the following pattern:
- Run your application in the normal way, but with RootCause enabled in its environment, for example:
my_app_driver arg1 arg2
This will record information about the application in the RootCause Log file. NOTE: On AIX, you must use "apaudit my_app_driver" in the above command instead of just "my_app_driver" to allow RootCause to log and trace your application. See Enabling RootCause for an AIX Application below.
- Start the RootCause Console GUI with the
rootcause opencommand. This will open the Workspace Browser and the Trace Display showing the contents of the RootCause log file.
- Use Open Associated Workspace on the application program listed in the RootCause log display, and approve the creation of the new workspace.
- Click Setup and define the probes for the application by choosing what you want to trace in the Trace Setup Dialog. Note that RootCause writes the probes to separate files, so the application itself remains totally unmodified.
- Execute the application as you normally would, but with rootcause "on", as in step 1 above. The application need not be executed from the RootCause GUI, although there is a convenience Run button to do so. This makes it very simple to use RootCause, even if the application is deeply embedded in a complex system.
- Click the Run button to bring up the index of data that was logged for the newest process in the workspace, and double-click on an item there to format the trace data collected by the probes, or you can use the Examine button to directly select the data file(s) you wish to view.
- In the Trace Display window that appears is a call tree. Here you can:
- Use the Find button to search for specific functions or events in the data.
- Select a node in the event tree and right-click to bring up the Trace Display Popup Menu, from which you can disable traces and perform other operations.
- Select a SYN_CALL_COUNTS node and use Show Associated Table to view and navigate to the functions in the data file(s).
- Select a LOAD_SHED node and use Show Associated Table to view the table of all functions for which tracing was disabled due to load shedding during the run, and disable the tracing of these during subsequent runs.
- Save the output as
XMLfor off-line processing
- When you have completed analyzing the data and modifying the trace to tune the information collected, go back to step 4 to trace parameters or add probe actions, or return to step 2 to choose another program to trace.
If you wish to run the probes on a remote computer, then there are additional steps to send a RootCause workspace to the remote computer before execution. These are discussed in detail in CHAPTER 6 - "Deploying the RootCause Workspace".
This process is explored using a concrete example in the next chapter, "RootCause Demo".
Enabling RootCause for an AIX Application
AIX provides no mechanism to cause a shared library to be automatically loaded into every application started. Therefore, the user must explicitly identify applications that are to be "intercepted" and recorded in the RootCause log, and subsequently traced using the process described in this document.
To run an executable under RootCause from the command line:
$ rootcause run my_program -opt arg2
$ rootcause on $ apaudit my_program -opt arg2 $ rootcause off
If it is not possible to directly invoke the application's executable from the command-line, you can simply rename the
to have a
.exe suffix, and replace it with a (soft-link to a) script which will invoke the real application. For example:
$ mv my_program my_program.exe $ ln -s $APROBE/bin/run_with_apaudit my_program
run_with_apaudit script simply re-invokes the program with apaudit as in the second example above.
When we use the phrase "run with rootcause on" we refer to any of the above mechanisms.
To enable automatic RootCause actions for Java applications (i.e., those normally run with the
java command), you must do this for the native
java executable. This is generally not necessary, since you can more easily change "java" to "apaudit java" at the point of invocation. However, if you want to enable RootCause in your central Java installation, you should contact OC Systems for assistance: different Java versions are configured differently.
Copyright 2006-2018 OC Systems, Inc.