|
|
|
|
You can use the command-line administration program to perform the following tasks.
Change the names and locations of the log files and backup log files.
Enable central or local logging.
Enable or disable logging of audit and exception events on individual servers.
Change the maximum log file size.
Enable verbose or succinct logging.
SNAP-IX usually puts logs in two different files:
Problems (always logged) and exceptions (if logged) are normally logged to the /var/opt/sna/sna.err file.
Audits (if logged) are normally written to the /var/opt/sna/sna.aud file.
You can change the names and locations of these files using the command-line administration program in the following way:
Use the snaadmin set_log_file command to change the names of log files.
Use the snaadmin query_log_file command to check the current file name.
Refer to SNAP-IX Administration Command Reference for more information about issuing these commands.
You may find it easier to have all messages (error and audit) logged
to the same file, to make it easier to see how they relate to each other.
To do this, issue two snaadmin set_log_file commands,
one with the log_file_type parameter set to
For example, to record error log and audit log messages in a file named sna.log, specify the following commands:
snaadmin set_log_file, log_file_type = ERROR, file_name = sna.log snaadmin set_log_file, log_file_type = AUDIT, file_name = sna.log
Audit and error log files are ASCII text files. Use a standard Solaris text editor such as vi to view them.
In a client-server system, SNAP-IX sends all log messages to files on the master server by default (central logging). However, you can log messages for each server to files on that server (local logging).
If a server cannot locate the domain configuration file when it starts up (for example, because no master or backup server is active), it cannot determine whether to log centrally or locally and which server is the central logger. In this case, the server logs messages locally. When it later establishes contact with the master server and determines that central logging is in use, it sends any further messages to the central logger and stops local logging.
You specify whether to log centrally or locally by using the set_central_logging command. To check the name of the server that is currently defined as the central logger (to which all log messages are sent) or to check whether central logging is currently enabled, use the query_central_logger and query_central_logging administration commands.
For more information about these administration commands, refer to the SNAP-IX Administration Command Reference.
Problem messages are always logged and cannot be disabled, but you can specify whether to log exception and audit messages. The initial default is to log exception messages but not audit messages. You can specify global settings for logging exception and audit messages on all servers by using the snaadmin set_global_log_type command. If necessary, you can override these settings for a particular server by using the snaadmin set_log_type command.
To determine what logging options are in effect issue the following:
Use snaadmin query_global_log_type to check which categories of messages are recorded on servers that use the global settings.
Use snaadmin query_log_type to check which categories of messages are being recorded on a particular server.
For more information about these administration commands, refer to the SNAP-IX Administration Command Reference.
SNAP-IX enables you to prevent log files from becoming too large and consuming disk resources. The snaadmin set_log_file administration command lets you specify the maximum size of a log file and the name of a backup file for each type of log information (audit or error). The default maximum file size is 1,000,000 bytes.
When a log file reaches the specified size, SNAP-IX renames the file to the name of the backup file (overwriting any existing backup log file) and then clears the log file. This means that the maximum amount of log information stored at any one time is twice the specified maximum file size (or four times the maximum file size if you are logging audit and error information to separate files).
You may need to increase the size of the log files to allow for the volume of log information (if your system is large enough). In particular, consider increasing the log file size to allow for the following:
Large numbers of clients or users (because a single communications link failure can result in large numbers of logs on the server relating to session failures).
Activation of audit logging as well as exception logging.
Use of central logging instead of local logging.
Use of verbose logging instead of succinct logging. For more information, see Verbose Logging Message Format.
The snaadmin set_log_file administration command also enables you to clear the current contents of the log file at any time (with or without copying the information to the backup file).
For more information, refer to the SNAP-IX Administration Command Reference.
You control the amount of detail recorded in logs by choosing one of the following logging formats:
Each message contains the message number, originating component, type of message, text of the message, the cause of the condition leading to the message, and any recommended action.
Each message contains only an abbreviated version of the header information (message number, originating component, and message type) and the text of the message. You can use the snahelp command-line utility to obtain the cause and action information for a particular message number (see Using snahelp for Succinct Logging Messages).
The default is succinct logging. You can specify verbose logging for audit messages, for error messages (problem and exception), or for both message types by using the set_global_log_type commandor snaadmin set_log_type command. If you are using central logging, the choice of succinct or verbose logging is determined by the settings on the server acting as the central logger, so all messages of the same type (audit or error) are written to the file in the same format.
When using succinct logging, a few messages from the 3270 emulation program, RJE workstation program, and API components may still be written to the log file in verbose format. This generally occurs when SNAP-IX is terminating or experiencing certain error conditions; in these cases, the component cannot obtain information about the node's configuration and cannot determine the log format to use.
The following example shows a typical log message in verbose logging format. The text following the example explains the items in the message.
----------------------- 13:55:16 EDT 15 May 1997 ----------------------- CFG_DAEM Message 4097 - 132, Subcode: 1 - 1 Log category: PROBLEM Cause Type: External System: sna18 Process ID: 17908 (snacfgdae) The initially active port could not be started when starting the node. Port name = SDLCP0 Cause: The config daemon could not start the port while loading the node's configuration. The node will be started, but the port will not be started. Action: Check for other logs which indicate why the port failed to start. Check that the DLC has been started.
Verbose logging messages contain the following information:
The time and date the message was generated. If you are using central logging, the timestamp for each message is taken from the system clock on the computer where the message was generated. If the system clocks on different computers are not synchronized (because of clock inaccuracies or time zone differences), the messages in the central log file may appear out of sequence because they are added to the file in order of arrival at the central logger and not in order of their timestamps.
If your system includes Windows clients and you are using central logging,
ensure that the
The SNAP-IX component (such as local node, link driver, or APPC library) that logged the message.
An identifier for the message. This identifier consists of two numbers.
A unique identifier that indicates the point within SNAP-IX at which the message was logged. This subcode is used only by SNAP-IX support personnel.
The event category of the log message. Possible values are Problem, Exception, or Audit.
The cause of the message. Possible values are:
Internal error in a SNAP-IX component. Report errors of this type to SNAP-IX support personnel.
An internal limiting value (for example, entries in a fixed-size table) in the SNAP-IX software. There are very few instances when this type of log occurs.
A cause external to SNAP-IX (such as a problem with communication link hardware) or in non-SNAP-IX software (such as communication link drivers).
Resource shortage (for example, insufficient memory on the Solaris computer).
User error (for example, invalid parameters supplied on the command line to a SNAP-IX program).
SNA protocol violation by a remote system, or interoperability problem with another SNA implementation.
Error in the SNAP-IX configuration, or mismatch between the SNAP-IX configuration and the remote system.
A normal event, reported for information only.
The name of the computer where the condition that caused the message was detected.
The Solaris process ID (from the computer whose system name is shown) and the executable name of the process that logged the message. The process ID is shown only for the 3270 emulation program, RJE workstation program, and API components. For a message logged by a Windows client, this parameter identifies the Windows task handle of the process.
Text describing the condition being logged. This field may include a number of variable parameters relating to this particular occurrence of the message. For example, a message reporting startup of an APPC session may include the names of the local and partner LUs and the mode they are using for this session.
This field can contain the return code from an operating system call. For a message logged by the Solaris computer, it may be shown either as a symbolic name or as a numeric value. Check the numeric values in the /usr/include/sys/errno.h file on the computer where the error occurred to find the corresponding symbolic name. The symbolic names are listed in your operating system documentation.
For a message logged by a Windows client, refer to your Windows documentation for explanations of these return codes.
Additional information about the cause of the condition being logged. This field may not be included if the message text contains all the required information. This field is generally not used when the cause type is Internal.
Recommended action as a result of the message. For audit messages, which provide accounting and progress information instead of reporting error conditions, this field is not included because no action is required.
The following shows the succinct logging format:
13:55:16 EDT 15 May 1997 4097-132 (1-1) P sna18 PID 17908 (snacfgdae) The initially active port could not be started when starting the node. Port name = SDLCP0
The first line contains all of the following fields except the message text, which appears on the second line:
The time and date the message was logged.
An identifier for the message. This identifier consists of two numbers separated by a hyphen (-).
A unique identifier that indicates the point within SNAP-IX at which the message was logged, shown in parentheses after the message number. This subcode is used only by SNAP-IX support personnel.
The category of the log message, shown as a single character:
P (problem)
E (exception)
A (audit)
The name of the computer where the condition that caused the message was detected.
The Solaris process ID (preceded by the characters PID) and executable name of the process that logged the message. The process ID is shown only for the 3270 emulation program, RJE workstation program, and API components. For a message logged by a Windows client, this parameter identifies the Windows task handle of the process.
Text describing the condition being logged. This field may include a number of variable parameters relating to this particular occurrence of the message. For example, a message reporting startup of an APPC session may include the names of the local and partner LUs and the mode they are using for this session.
This field can contain the return code from an operating system call. For a message logged by the Solaris computer, it may be shown either as a symbolic name or as a numeric value. Check the numeric values in the /usr/include/sys/errno.h file on the computer where the error occurred to find the corresponding symbolic name. The symbolic names are listed in your operating system documentation.
For a message logged by a Windows client, refer to your Windows documentation for explanations of these return codes.
The succinct logging format does not show cause and action information. However, you can use the snahelp utility to obtain details about the cause and action for a particular message number by typing the following command at the Solaris command prompt:
snahelp message_number
The message_number is returned by SNAP-IX in the header information for the message and consists of two numbers separated by a hyphen (-).
The utility returns the name of the component that logged the message and the information from the Message number, Cause type, Message cause, and Message action fields as shown for verbose logging.
For example, to obtain further information about the succinct log message shown in Succinct Logging Message Format (with component ID and message number 4097 - 132), type the following command:
snahelp 4097-132
The output from snahelp is:
CFG_DAEM Message: 4097 - 132, Cause Type: External Cause: The config daemon could not start the port while loading the node's configuration. The node will be started, but the port will not be started. Action: Check for other logs which indicate why the port failed to start. Check that the DLC has been started.
|
|
|
 |
|