Difference between revisions of "RCUG 4 Getting Started"

From OC Systems Wiki!
Jump to: navigation, search
m
m
Line 13: Line 13:
  
  
<DIV ID="UID-04start_rc.fm-949488"></DIV>  -->
+
<DIV ID="UID-04start_rc.fm-949488"></DIV>
 
+
<DIV ID=MARKER-9-509></DIV>
<!-- <DIV ID=MARKER-9-509></DIV>  -->
 
 
== The Setup Script ==
 
== The Setup Script ==
<!-- <DIV ID=MARKER-10-510></DIV>  -->
 
  
Installation of RootCause from CD-ROM or compressed file is covered in  
+
<DIV ID=MARKER-10-510></DIV>
[[RCUG_2_Installing_RootCause|Chapter 2, &quot;Installing RootCause&quot;]].
+
Installation of RootCause from CD-ROM or compressed file is covered in [[RCUG_2_Installing_RootCause|Chapter 2, &quot;Installing RootCause&quot;]].
 
<!--  [][["rcc-5.html#MARKER-9-205">Chapter 2, &quot;Installing RootCause&quot;</DIV>.  -->
 
<!--  [][["rcc-5.html#MARKER-9-205">Chapter 2, &quot;Installing RootCause&quot;</DIV>.  -->
  
<!--  <DIV ID=MARKER-10-511></DIV>
+
<DIV ID=MARKER-10-511></DIV>
 
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.
 
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.
  
Line 29: Line 27:
  
 
For example, if you installed RootCause in directory <code>/opt/aprobe</code>, 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:
 
For example, if you installed RootCause in directory <code>/opt/aprobe</code>, 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:
 
 
<pre>
 
<pre>
 
. /opt/aprobe/setup
 
. /opt/aprobe/setup
Line 38: Line 35:
 
</pre>
 
</pre>
  
You must execute this
+
<DIV ID=MARKER-2-512></DIV>
<!-- <DIV ID=MARKER-2-512></DIV>  -->
+
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 <code>~/.profile</code> (for Korn or Bourne shells) or <code>~/.login file</code> (for C shell).  See  
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 <code>~/.profile</code> (for Korn or Bourne shells) or <code>~/.login file</code> (for C shell).  See  
+
[[RCUG_RootCause_Command_Reference#RootCause_and_Different_Shells|"RootCause and Different Shells"]] for information about other shells.
[[RCUG_RootCause_Command_Reference#RootCause_and_Different_Shells|"RootCause and Different Shells"]]
 
 
<!-- [["rcc-12.html#MARKER-9-2009">"RootCause and Different Shells"</DIV> -->
 
<!-- [["rcc-12.html#MARKER-9-2009">"RootCause and Different Shells"</DIV> -->
for information about other shells.
 
  
 
This script defines the <code>APROBE</code> environment variable and appends  
 
This script defines the <code>APROBE</code> environment variable and appends  
Line 55: Line 50:
  
 
The setup script also defines aliases that are not inherited by subsequent non-login shells you may open, such as with the <code>xterm</code> command.  To ensure that these aliases are defined (specifically <code>rootcause_on</code> and <code>rootcause_off</code>), you may add the command:
 
The setup script also defines aliases that are not inherited by subsequent non-login shells you may open, such as with the <code>xterm</code> command.  To ensure that these aliases are defined (specifically <code>rootcause_on</code> and <code>rootcause_off</code>), you may add the command:
 
 
<pre>
 
<pre>
 
. $APROBE/setup.kshrc
 
. $APROBE/setup.kshrc
Line 70: Line 64:
 
Now you're ready to run RootCause.
 
Now you're ready to run RootCause.
  
<!-- 
 
 
<DIV ID=HEADING7-17></DIV>
 
<DIV ID=HEADING7-17></DIV>
<DIV ID="UID-04start_rc.fm-949707"></DIV> -->
+
<DIV ID="UID-04start_rc.fm-949707"></DIV>
 
 
 
== The RootCause Process ==
 
== The RootCause Process ==
  

Revision as of 03:09, 5 November 2017


Next Previous Index Top

RootCause User Guide


Getting Started


rcc-7


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:

. /opt/aprobe/setup

or

source  /opt/aprobe/setup.csh

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_on and rootcause_off), you may add the command:

. $APROBE/setup.kshrc

into your ~/.kshrc file if you are using Korn shell, or the command

source $APROBE/setup.cshrc

into your ~/.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:

  1. Run your application in the normal way, but with RootCause enabled in its environment, for example:
    rootcause
    _on


    my_app_driver arg1 arg2


    rootcause
    _off

    This will record information about the application in the RootCause Log

    [["rcc-10.html#MARKER-9-963">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

    [["#MARKER-9-532">Enabling RootCause for an AIX Application

    below.

  2. Start the RootCause Console GUI with the

    rootcause open command. This will open the Workspace Browser and the Trace Display showing the contents of the

    RootCause log file.

  3. Use

    Open Associated Workspace on the application program listed in the RootCause log display, and approve the creation of the new workspace.

  4. 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.

  5. 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.
  6. 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.
  7. 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 function

      s

      in the data file(s).

    • Select a

      LOAD_SHED

      node and use Show Associated Table to view the table of all function

      s

      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 Text or XML for off-line processing
  8. 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

or

$ 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 executable 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

The

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-2017 OC Systems, Inc.

Next Previous Index Top