Infrastructure Tracing is an invaluable tool for determining what is going on in
a running system.
nbsp;
There are two types of tracing, high level from libInf.so and Utility tracing from libUt.so (used for stand-alone programs).
nbsp;
I will describe high level first.
nbsp;
Trace levels and masks may be changed while a system is running via the infCtl tool.
nbsp;
Trace messages may be created in 'C' or Perl code in order to track or trace a
program's execution and data flowing through it.
nbsp;
The amount of trace information collected may be dynamically adjusted.
nbsp;
Trace calls (trc) are placed in the 'C' or Perl source code when it is written.
nbsp;
Tracing is enabled by both the system layer name and a trace level.
nbsp;
The Layer name, for example "APP1", is a mask bit which is defined
in trc.h and compared on each trace call.
nbsp;
Since the masks are bits, multiple layers may be traced at the same time.
nbsp;
The trace level is an integer from 1 to 255 and is used within
the layer to determine the granularity of information to be captured.
nbsp;
The intended way to use trace level is to use 5 at the entry point of a high
level function and at it's exit point.
nbsp;
Higher trace levels should be used within the function and in low level or
utility functions.
nbsp;
In this way the higher the trace level (number) the more information is
collected.
nbsp;
This mask / level is passed to the trace call as the first variable
and constructed at compile time by adding the trace layer mask to the
trace level number (ie. TRC_APP1 + 5).
The environment vaiable "TRACECTL" either in the Unix environment or
in the confuguration file msy be used to enable tracing at program
startup. The format for TRACECTL is "TRACECTL APP1+IO,55"
which enables tracing in both the application layer and the socket IO
layer and sets the level to 55. The infrastructure control program
(infCtl) may also be used to change the trace level or mask while a
process is running.
Error messages may be placed in an error log using the trace error call
(trcErr). Errors may be passed to a remote daemon by defining a TCP
address with the logical name "errLog" within a process'
configuration file.
Since both trace and error logs use the same binary format, they must be
read / examined using the trace extract command (extr). If extr is
called with no options it will open the "trcLog" file in the
current directory. A fully qualified path/file name may be passed on
the command line. If an 'e' is found on the command line the local
file 'errLog' is opend and examined. Command line options are:
> | |
---|---|
extr | |
[e] | From current trace log |
[xxx.xxx] | From specified file |
[trcLog.2] | From old trcLog.2 file |
[-b hh:mm:ss.subsec]] | Begining time |
[-e hh:mm:ss.subsec]] | Ending time |
[-E]] | Errors only |
[-m] | Explicate Message Objects |
[-p proc1[,proc2]] | Only rcds from named process(es) |
[-s srchString[,cnt]] | Display only lines containing "srchString" in text messages. If "cnt" is present display the following "cnt" lines. |
[-t] | Truncate all STR and BIN message text and fields. |
[-u] | Unsorted display (don't sort output). |
[-v] | Verbose |
type | INT [3] |
code | INT [3] |
status | INT [0] |
reqId | INT [0] |
msgTid | INT [1] |
questor | STR [tt2@Paul] |
Data | STR [how now brindle bovine] |
myTid | INT [1] |
11:37:06.146 tt2:1 -- msgSnd: hndl: 1 11:37:06.146 tt2:1 -- msg_rcv: begin, TimOut: 10000 11:37:06.146 tt2:1 -- msg_rcv: Loop begin, myTid 1 11:37:06.146 tt2:1 -- msg_rcvL: thd 1 about to wait timO 10000 11:37:06.149 tt2 -- launchThd: seq:2 11:37:06.149 tt2 -- launchThd: pthread_create 11:37:06.149 tt2 -- launchThd: end seq:2 11:37:06.149 tt2 -- msg_rcv: begin, TimOut: 10
The utility library of the infrastructure supports not only the top infrastructure but also stand-alone processes.
It has a built-in trace facility similar to the top layer and supports utTrc(), utTrcErr(), and utTrcFatal().
Arguments for these are the same as their high-level counterparts, but their invocation does not require the layer as part of the 1st utTrc argument, only it's level.
The low level trace functions are:
utTrc( int level, char *fmt, ... ) The basic trace call which only traces if the process's trace level is equal to or smaller than this statement's level field. The format "fmt" and following elipsis ":..." operate exactly as they do in sprintf.
utTrcErr( char *fmt, ... ) Output an error to the trace log ignoring tracelevel. The format "fmt" and following elipsis ":..." operate exactly as they do in sprintf.
utTrcFatal( char *fmt, ... ) The format "fmt" and following elipsis ":..." operate exactly as they do in sprintf.
utTrcDmp( int level, uchar *loc, int len, char *fmt, ... ) If the process's trace levle is less than or equal to the "level" argument, output a hex dump of the area starting at "loc" and continuing for "len" bytes. The format "fmt" and following elipsis ":..." operate
exactly as they do in sprintf. The resulting formatted messages is placed at the beginning of hex dump.
utTrcClos() Close the trace file. In all cases above except utTrcClose, the function is a macro which calls the real function and includes the function name so that it appears in the trace log. The Trace log is in the process's current directory and is named "trc.txt". Tracing may be invoked two ways: on the command line using "-T Level" or by using environment variable "TRC_ENA=level". In both cases the level is an integer value between 1 and 255 and is compared to the level value in utTrc, and utTrcDmp, so that tracing does not occur if the process'es level is below the function call's level. Again this works just like high level tracing, the proces's level determines the amount of trace information.