|
|
|
|
|
|
Monitoring Log Files
To help you identify error conditions quickly and accurately, the BEA WebLogic Enterprise and BEA Tuxedo systems provide you with two log files:
These two logs are maintained and updated constantly while your application is running.
This topic includes the following sections:
What is the ULOG?
The user log (ULOG) is a central event logger. All messages generated by the BEA WebLogic Enterprise or BEA Tuxedo system-error messages, warning messages, information messages, and debugging messages-can be written to this log. Application clients and servers can also write to the user log.
A new ULOG is created every day and there can be a different log on each machine. When a remote file system is being used, however, a ULOG can be shared across machines.
The ULOG also contains messages generated by the tlisten process. The tlisten process provides remote service connections for other machines. Each machine, including the master machine, should have a tlisten process running on it.
In previous BEA Tuxedo releases, tlisten had its own log file. Now, all messages from the tlisten are written in a ULOG format.
Note: It is possible that the tlisten might have its own ULOG file that is different from the application's ULOG file. This is because the tlisten process starts before any application is started. Therefore, tlisten writes the ULOG in the current directory where it was started, or in the directory in the ULOGPFX environment variable, if one was defined. The application's ULOG file is usually present in the $APPDIR directory.
Purpose
The purpose of the ULOG is to give you, the administrator, a record of the events on your system from which you can determine the cause of most BEA WebLogic Enterprise or BEA Tuxedo system and application failures.
How Is the ULOG created?
The ULOG is created by the BEA WebLogic Enterprise or BEA Tuxedo system whenever one of the following events occurs:
With the exception of the RMI trace and JDBC log information, all messages generated by the BEA WebLogic Enterprise or BEA Tuxedo system are written to this log by default.
For a discussion of these attributes, see "Configuring Servers" .
How Is the ULOG Used?
You can view the ULOG, an ASCII file, with any text editor.
When a message is written to the ULOG through the tperrno global variable, application clients and servers are notified, as follows:
A ULOG message consists of two parts: a tag and text. Each part consists of three strings, as shown in the following table.
|
This Part . . . |
Consists of . . . |
|---|---|
|
tag |
A 6-digit string (hhmmss) representing the time of day (in terms of hour, minute, and second). |
|
Name of the machine (as returned, on UNIX systems, by the uname -n command). |
|
|
Name and identifier of the process that is logging the message. |
|
|
text |
Message catalog name |
|
Message number |
|
|
System message |
Consider the following example of a user log message.
121449.gumby!simpserv.27190: LIBTUX_CAT:262: std main starting
From the message tag we learn:
From the message text we learn:
For more information about a message, note its catalog name and catalog number. With this information you can look up the message in the System Messages and BEA Tuxedo System Message Manual, which provide complete descriptions of all system messages.
Location
By default, the user log is called ULOG.mmddyy (where mmddyy represents the date in terms of month, day, and year) and it is created in the $APPDIR directory.
You can place this file in any location, however, by setting the ULOGPFX parameter in the MACHINES section.
What Is the Transaction Log (TLOG)?
The transaction log (TLOG) keeps track of global transactions during the commit phase. A global transaction is recorded in the TLOG only when it is in the process of being committed. The TLOG is used to record the reply from the global transaction participants at the end of the first phase of a two-phase-commit protocol. The TLOG records the decision about whether a global transaction should be committed or rolled back.
We recommend that you create a TLOG on each machine that participates in global transactions.
How Is the TLOG Created?
For instructions on creating a TLOG, see the section "Creating a Transaction Log (TLOG)" .
How Is the TLOG Used?
The TLOG file is used only by the Transaction Manager Server (TMS) that coordinates global transactions. It is not read by the administrator.
Location
The location and size of the TLOG are specified by four parameters that you set in the MACHINES section of the UBBCONFIG file: TLOGDEVICE, LOGOFFSET, TLOGNAME, and TLOGSIZE. (For descriptions of these parameters and instructions for assigning values to them, see "Creating a Transaction Log (TLOG)" .)
Creating and Maintaining Logs
The ULOG is generated by various BEA WebLogic Enterprise or BEA Tuxedo system processes; you do not need to create it. The TLOG, however, is not produced automatically; you must create it.
This section provides instructions for:
How to Assign a Location for the ULOG
To override the default location for your ULOG file, specify the desired location as the value of the ULOGPFX parameter in the MACHINES section of the UBBCONFIG file. (By default, the value of ULOGPFX is $APPDIR/ULOG.) The value you assign becomes the first part of the ULOG filename.
Listing 16-1 shows how you can override the default setting.
Listing 16-1 Overriding Default Settings in the MACHINES Section of Your UBBCONFIG File
MACHINES
gumby LMID=SITE1
TUXDIR="/usr/tuxedo"
APPDIR="/home/apps"
TUXCONFIG="/home/apps/tuxconfig"
ULOGPFX="/home/apps/logs/ULOG"
...
The following ULOG was created for SITE1 on 04/13/98.
/home/apps/logs/ULOG.041398
Creating a Transaction Log (TLOG)
To create a TLOG, you must complete the following procedure:
This section provides instructions for each step.
Step 1: Assign Values to MACHINES Section Parameters
Your first step is to assign values to four parameters in the MACHINES section of the UBBCONFIG file: TLOGDEVICE, TLOGNAME, TLOGOFFSET, and TLOGSIZE.
Note: Technically, there is no reason that TLOGDEVICE cannot be a separate VTOC file, but there are two reasons why it is not recommended: the TLOG is generally too small to justify devoting a raw disk segment to it, and creating TLOGDEVICE as a UNIX file leads to expensive delays when synchronous writes to the TLOG are required.
The TLOG is stored as a BEA WebLogic Enterprise or a BEA Tuxedo system VTOC table on the device named in this parameter. If the TLOGDEVICE parameter is not specified, there is no default; the BEA WebLogic Enterprise or BEA Tuxedo system assumes that no TLOG exists for the machine. If no TLOG exists for a given machine, the associated LMID cannot be used by server groups that participate in distributed transactions.
After TUXCONFIG has been created via tmloadcf, you must create a device list entry for the TLOG on each machine for which TLOGDEVICE is specified. This is done using the tmadmin crdl command. The BBL creates the log automatically the first time the system is booted.
Listing 16-2 shows an example of the use of transaction log parameters.
Listing 16-2 Sample Transaction Log Parameters for a Specified Machine
MACHINES
gumby LMID=SITE1
...
TLOGDEVICE="/home/apps/logs/TLOG"
TLOGNAME=TLOG
TLOGOFFSET=0
TLOGSIZE=100
...
Step 2: Create a UDL Entry
Next, create an entry in the Universal Device List (UDL) for the TLOGDEVICE on each machine that requires a TLOG. You can perform this step either before or after TUXCONFIG has been loaded, but you must do it before the system is booted.
To create an entry in the UDL for the TLOG device, complete the following procedure.
tmadmin -c
You do not have to create TLOGs on any machine other than the master machine. The BEA WebLogic Enterprise or BEA Tuxedo system creates TLOGs on nonmaster machines (as long as a UDL exists on those machines) when the application is booted.
crdl -z config -b blocks
Note: If the TLOGDEVICE is mirrored between two machines, step 3 is not required on the paired machine.
During the boot process, the Bulletin Board Listener (BBL) initializes and opens the TLOG.
Step 3 (optional): Allocate Space for a New Device on an Existing System
In step 2 you created a new BEA WebLogic Enterprise or BEA Tuxedo file system that can be used to hold the TLOG. Sometimes, however, it is necessary to add new devices or space to an existing configuration or to check space usage. You can perform these tasks by running the command:
tmadmin -c
(You can run this command whether or not the system is booted.)
It is possible that the UDL exists on config but does not have sufficient space for the log. To allocate space on a new device to an existing BEA Tuxedo file system, enter:
crdl -z config -b blocks new_device
where new_device specifies the full path name for the new device where space is to be allocated. This creates a new entry on the UDL and the space is available for any tables that are created on config. (For example, this procedure can be used for the TUXCONFIG file when there is not enough space for a modified configuration, for allocating a new TLOG, or for increasing the size of the TLOG by deleting an old log and then creating a larger one.) If you are running several commands using the current configuration, it is possible to set the default configuration by entering the default command (d), as follows:
d -z config
If you run this command, you will not need to enter the -z option after each command.
Under rare circumstances, a device does not start at offset 0. This might happen if space has been allocated on a device (less than the entire device) to a BEA Tuxedo file system, and more space on the same device is available to be allocated. In this case, you can allocate the second entry by entering the following command:
crdl -z config -b blocks -o new_device_offset new_device
Here, new_device_offset specifies the offset of the new space being allocated on the device. (Note that the option is a lowercase o.) In this case, since the first entry on the UDL is allocated at offset 0, TLOGOFFSET and/or TUXOFFSET are set to 0, instead of to the offset of the new device. (The BEA WebLogic Enterprise or BEA Tuxedo system needs to find the UDL, from which it can determine the offset of other available space.)
A second (and rarer) reason that a device does not start at offset 0 is that a single raw device is shared. This happens, for example, if a UNIX file system is followed by a BEA Tuxedo file system on the same device. (This situation is risky because the raw device must be writable by the BEA WebLogic Enterprise or BEA Tuxedo system administrator and it is possible to overwrite the UNIX file system.) If the first entry on the UDL does not start at offset 0 (as in this example), the device offset must be specified everywhere that the device is referenced. To allocate the entry, enter the following command:
crdl -z config -b blocks -o offset -O offset new_device
Here, offset is the offset of the space to be allocated for the BEA Tuxedo file system (UDL and tables). Note that the -o (lowercase o) specifies the offset of the UDL and -O (uppercase O) specifies the offset of the new device space being allocated, which in this case are the same. Any devices that are created subsequently on this configuration must use both the -o option with the offset of the first entry, and the -O option with the offset of the new entry. (The offset may be 0 if a new device is being specified.) Since the first entry on the UDL is not allocated at offset 0, TLOGOFFSET and/or TUXOFFSET must be set to the offset of the first entry. This is the only case in which TLOGOFFSET and TUXOFFSET must be set in the UBBCONFIG file, and the TUXOFFSET environment variable must be set when all BEA Tuxedo application and administrative processes are being run.
To list the current UDL, enter:
lidl -z config
where config was created using the above procedures. If the first entry was created with an offset other than 0, -o offset must be specified in addition to the configuration device. In verbose mode, this command lists not only the space initially allocated for each device entry, but also the amount of free space.
It is also possible to generate a list of the tables on the configuration by entering the following command:
livtoc -z config
Here config was creating using the above procedures. If the first entry was created with an offset other than 0, -o offset must be specified in addition to the configuration device. This command lists the table name, device number, offset within the device, and number of pages for each table. The first two tables are always VTOC and UDL. TUXCONFIG table names are of the form _secname_SECT, where secname is the name of a section in the UBBCONFIG file. The TLOG table name is based on the TLOG parameter in the UBBCONFIG file, and defaults to TLOG. In the rare case in which two applications share a single BEA Tuxedo file system for the TLOGDEVICE, the TLOG parameter must be different for each application.
Note: A BEA Tuxedo system file system is a file that is managed by BEA Tuxedo, which may be located on a raw disk or in an operating system file system. A BEA Tuxedo system file system contains one TUXCONFIG file and one or more TLOG files.
Because the table names for the TUXCONFIG file are fixed, it is not possible for two applications to share the same BEA Tuxedo file system for the TUXCONFIG file.
Step 4: Create the Log
To create the log, complete the following steps:
tmadmin -c
crlog [-m machine]
where the value of machine is the LMID of a machine, as specified in TUXCONFIG.
Note: The -m option is shown as optional because it can be specified with the default (d) command of tmadmin. If you have not specified a machine with the d command, however, the -m option is required on the crlog command line.
Maintaining a TLOG
There are few tasks needed to maintain a transaction log (TLOG). Two of them are as follows:
inlog [-yes] [-m machine]
The value of machine is the LMID of a machine, as specified in TUXCONFIG.
Be careful when using this command: it will reinitialize the log even if there are outstanding transactions. The result could be inconsistent TLOGs, possibly causing transactions to abort.
dslog [-yes] [-m machine]
The value of machine is the LMID of a machine, as specified in TUXCONFIG.
If the application is not active or if there are transactions still outstanding in the log, an error will be returned.
Note: The -yes and -m options are shown as optional because they can be specified with the default (d) command. If you have not specified a machine with the d command, however, the -m option is required on the inlog and dslog command lines.
Using Logs to Detect Failures
The BEA Tuxedo log files can help you detect failures in both your application and your system. This section provides instructions for analyzing the data in the logs.
Analyzing the User Log (ULOG)
Note: Although application administrators are responsible for analyzing user logs, application programmers may also consult the logs.
It is not unusual for multiple messages to be placed in the user log for a given problem. In general, the earlier messages will better reflect the exact nature of the problem.
Listing 16-3 shows how the LIBTUX_CAT message 358 identifies the exact nature of the problem, namely, that there are not enough UNIX system semaphores to boot the application.
Listing 16-3 Sample ULOG Messages
151550.gumby!BBL.28041: LIBTUX_CAT:262: std main starting
151550.gumby!BBL.28041: LIBTUX_CAT:358: reached UNIX limit on semaphore ids
151550.gumby!BBL.28041: LIBTUX_CAT:248: fatal: system init function ...
151550.gumby!BBL.28040: CMDTUX_CAT:825: Process BBL at SITE1 failed ...
151550.gumby!BBL.28040: WARNING: No BBL available on site SITE1.
Will not attempt to boot server processes on that site.
See the System Messages for complete descriptions of user log messages and recommendations for any actions that should be taken to resolve the problems indicated.
Analyzing tlisten Messages
Keep the following guidelines in mind as you check the tlisten messages in your ULOG:
To find out whether one of these errors has occurred, check the ULOG file.
Note: Application administrators are responsible for analyzing the tlisten messages in the ULOG, but programmers may also find it useful to check these messages.
The CMDTUX catalog in the BEA Tuxedo System Message Manual contains the following information about tlisten messages:
Consider the following example of a tlisten message in ULOG.
042398; 27909;CMDTUX_CAT: 615 INFO: Terminating tlisten process
This message was recorded on April 23, 1998. Its purpose is simply to provide information: the tlisten process is being terminated. No action is required.
Note: This message can be found in the CMDTUX catalog of the BEA Tuxedo System Message Manual.
Analyzing a Transaction Log (TLOG)
The TLOG is a binary file that contains only messages about global transactions that are in the process of being committed. You should never need to examine this file.
If you do need to view the TLOG, you must first convert it to ASCII format so that it is readable. The BEA Tuxedo system provides two tmadmin commands for this purpose:
[ -g groupname ] filename
The dumptlog and loadtlog commands are also useful when you need to move the TLOG between machines as part of a server group migration or machine migration.
For more information about these tmadmin commands, see tmadmin(1) in the BEA Tuxedo Reference.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|