| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.0.1) Part Number B25343-01 |
|
|
View PDF |
| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.0.1) Part Number B25343-01 |
|
|
View PDF |
This chapter focuses on logging. It includes following topics:
The logging feature enables you to collect a wide range of program execution data so that you can troubleshoot system performance issues and diagnose component health problems.
Logging stands as just one of several features for collecting and presenting Oracle Access Manager-related information. For an overview of other reporting features, including system event auditing, Identity and Access System diagnostics, and SNMP monitoring, see "Reporting".
You can control logging activity for components by specifying log output for individual Access Servers, Identity Servers, Policy Managers, WebPasses, WebGates, custom AccessGates, and custom plug-ins.
The parameters that control logging activity reside in configuration files stored with each component. You customize log output for each component by manually editing the associated configuration file. For Identity Servers only, you have the option to set certain log parameters through the Identity System Console.
You can send the log data generated by a specific component to either of the following destinations, or neither, or both:
A log file stored in the directory tree under the root installation directory of the component generating the data.
The system file of the machine hosting the component logging data. (When more than one component resides on the same host, all components can send data to the system log file on that machine.)
For convenience, the many thousands of program events and states reportable through logging are classified within an eight-level, pyramidal hierarchy. At the highest level, the Fatal category includes about 60 catastrophic events that usually force a component to exit. At the bottom of the pyramid, the Trace level reports about 900 Oracle Access Manager API and 150 third-party API calls and their outcomes. In most cases, these Trace level messages are meaningful only to developers and plug-in programmers.
The logging feature can collect logging data at one or more levels of detail. Since each level is activated individually, you can collect data from non-adjacent levels.
The following table lists the eight hierarchical levels that the LOG_THRESHOLD_LEVEL parameter uses to establish the levels to activate for logging. See Table 10-4 for details.
The ninth entry in this table, LOGLEVEL_ALL, encompasses all eight levels in the hierarchy.
| Level | Number of Events Reported | Description |
|---|---|---|
|
|
> 60 |
Critical errors are reported at this level. Generally, these events are serious enough to cause the component to exit. |
|
|
> 960 |
Events that may require corrective action are written to the log file. For example, an error-level entry is generated when the component is unavailable. An error log entry may also be generated for transient or self-correcting problems, such as failure to connect to another component. |
|
|
> 1200 |
Issues that may lead to an error or require corrective action at some point in the future are written to the log file. |
|
|
> 400 |
Successfully completed actions or the current state of a component (if the component is initializing, for instance) are written to the log file. |
|
|
> 400 |
Basic debugging information is written to the log file. Typically, the information at this log level is only meaningful to a developer. |
|
|
> 100 |
Advanced (or rarely needed) debugging information is written to the log file. This log level augments the information provided in the Debug1 log level. Typically, the information at this log level is only meaningful to a developer. |
|
|
> 900 |
A large amount of debugging information (or data pertaining to an expensive section of the code) is written to the log file. This level is useful for debugging a tight loop or a performance-sensitive function. Typically, the information at this log level is only meaningful to a developer. |
|
|
> 900 Oracle Access Manager API; > 150 3rd-party API |
This log level is used to trace code path execution or to capture performance metrics. This information is captured at the entry and exit points for each component function. Typically, the information at this log level is only meaningful to a developer. |
|
LOGLEVEL_ ALL |
> 5000 |
This amalgamated level includes all the events and states from all eight levels. Note: Even if you specify |
The parameters that control log output reside in XML-based log files that you can edit with any plain-text editor. Changes that you make to these files are effectively immediately.
When you install a component, a default log configuration file is placed in the following location:
Component_install_dir\identity|access\oblix\config
where Component_install_dir is the directory where you are installing the component.
When you install more than one instance of a given component (such as multiple Identity Servers, for example), a logging configuration file is installed for each instance.
|
Important: To ensure that components can find the log configuration file, do not change the default path. |
Be aware that a log configuration file is distinct from a log data file. For details on log data files, see Table 10-6.
The following table lists the names of the log configuration files for each type of component. To ensure that components can find this file, do not change the default name.
Table 10-2 Log Configuration File Names for Components
| Component | Logging Configuration FIle Name |
|---|---|
|
Access Server |
|
|
Identity Server |
|
|
Policy Manager |
|
|
WebGate |
|
|
WebPass |
|
|
Access Manager SDK (custom AccessGate) |
|
The parameters set in the log configuration file associated with a given component determine the type of information that is logged for that component, the destination to which the data gets sent, and in certain cases, the size of the write buffer used for the log and the manner in which the target log file is rotated, among other specifics.
For all components, you edit the XML statements in the log configuration file with a plain text editor. For Identity Servers only, you can modify configuration parameters in the log file through the Identity System console, providing that the AUTOSYNC parameter in the configuration file has previously been set to the default value True. See "Configuring Logs in the Identity System Console" for details.
As installed, each log configuration file contains extensive embedded comments that explain the parameters you set to control log output. Comments, which can span one or multiple lines, begin with a left angle-bracket, an exclamation point, and two dashes, followed by two blank spaces ("<!-- "). They end with two spaces followed by two dashes, an exclamation point, and a closing angle-bracket (" --!>").
When you use the Identity System Console to modify the log parameters for a component, then commit those changes, the configuration file associated with that component is recorded to disk without the embedded comments. The presence or absence of these comments does not affect logging in any way; they are included solely to guide manual editing of the log configuration file.
In any case, you can view the original comments by opening the read-only duplicate of the original logging configuration file, which is named "oblog_config_original.xml" and located in the following directory:
Identity_Server_install_dir/oblix/config
Where IdentityServer_install_dir is the root installation folder for your Identity Server.
The following listing presents a typical log configuration file with comments embedded. For an example of a log file without embedded comments, see Example 10-7.
Example 10-1 The Default Log Configuration File (with Embedded Comments)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!--============================================================ -->
<!--============================================================ -->
<!--NetPoint Logging Configuration File -->
<!---->
<!--Changes to this file to take effect upon saving the file. -->
<!---->
<!---->
<!--============================================================ -->
<!--============================================================ -->
<!--Set the Log Threshold -->
<!---->
<!--The log Threshold determines the amount of information to log. -->
<!--Selecting a lower level of logging includes the information -->
<!--logged at the higher levels. For example, LOGLEVEL_ERROR -->
<!--includes the information collected at LOGLEVEL_FATAL. -->
<!---->
<!--Choices are: -->
<!--LOGLEVEL_FATAL - serious error, possibly a program halt. -->
<!--LOGLEVEL_ERROR - a transient or self-correcting problem. -->
<!--LOGLEVEL_WARNING - a problem that does not cause an error. -->
<!--LOGLEVEL_INFO - reports the current state of the component. -->
<!--LOGLEVEL_DEBUG1 - basic debugging information. -->
<!--LOGLEVEL_DEBUG2 - advanced debugging information. -->
<!--LOGLEVEL_DEBUG3 - logs performance-sensitive code. -->
<!--LOGLEVEL_TRACE - used when you need to trace the code path -->
<!--execution or capture metrics. Includes all previous levels. -->
<!---->
<!--If you do not specify a threshold, the default is WARNING. -->
<!---->
<!--In addition to specifying a threshold, you need to specify -->
<!--if changes that you make to the logging configuration in -->
<!--the GUI overwrite the settings in this file. The -->
<!--AutoSync parameter accomplishes this. This parameter takes a -->
<!--value of True or False. If set to True, changes made in the -->
<!--GUI overwrite changes in this config file. If False, changes -->
<!--made in the GUI are only in effect until the server is -->
<!--stopped or restarted. The default is True. -->
<!---->
<!---->
<CompoundList xmlns="http://www.oblix.com" ListName="logframework.xml.staging">
<SimpleList>
<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_WARNING" />
<NameValPair ParamName="AUTOSYNC" Value="True" />
</SimpleList>
<!---->
<!---->
<!--============================================================ -->
<!--============================================================ -->
<!--Configure the Log Level -->
<!---->
<!---->
<!--To configure a log level, you specify a name for the -->
<!--configuration (for instance, MyErrorLog1) and -->
<!--the log level that you are configuring. You can create -->
<!--more than one configuration per log level if you want -->
<!--to output to more than one destination. You can output to -->
<!--the system log or to a file, as specified on -->
<!--the LOG_WRITER parameter. The value for the LOG_WRITER -->
<!--parameter may only be SysLogWriter, FileLogWriter or -->
<!--MPFileLogWriter. The MPFileLogWriter is a multi-process safe -->
<!--FileLogWriter. It should be used to log in webcomponents i.e -->
<!--WebGate, Policy Manager and WebPass loaded on multiprocess -->
<!--webservers like Apache and IPlanet(Unix) -->
<!---->
<!--If you do not specify an output destination, the default is -->
<!--SysLogWriter. -->
<!---->
<!--If outputting to a file, you also specify a file name and -->
<!--other parameters. Default parameter values are: -->
<!--FILE_NAME: <installdir>/oblix/log/oblog.log -->
<!--BUFFER_SIZE: 32767 (number of bytes) -->
<!--MAX_ROTATION_SIZE: 5242880 (bytes, equivalent to 5MB) -->
<!--MAX_ROTATION_TIME: 86400 (seconds, equivalent to one day) -->
<!---->
<!--Configuring the log level does not ensure that the data is -->
<!--actually collected. Data collection for a log is -->
<!--determined by the LOG_THRESHOLD_LEVEL parameter, above, -->
<!--and the LOG_STATUS parameter in the log configuration. -->
<!---->
<!--If you do not provide a LOG_STATUS, the default for -->
<!--LOGLEVEL_FATAL, LOGLEVEL_ERROR, and LOGLEVEL_WARNING, -->
<!--is On. -->
<!---->
<!--This file contains several sample configurations that are -->
<!--enclosed in comments. To use them, remove the comments. -->
<!---->
<CompoundList xmlns="http://www.oblix.com" ListName="LOG_CONFIG">
<!--Write all FATAL logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogFatal2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<!--Write all ERROR logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogError2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ERROR" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<!--Write all WARNING logs to the system logger. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogWarning2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_WARNING" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<!--Write all logs to the Oblix log file. -->
<ValNameList xmlns="http://www.oblix.com" ListName="LogAll2File">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ALL" />
<NameValPair ParamName="LOG_WRITER" Value="FileLogWriter" />
<NameValPair ParamName="FILE_NAME" Value="oblog.log" />
<!--Buffer up to 64 KB (expressed in bytes) of log entries before flushing to the file. -->
<NameValPair ParamName="BUFFER_SIZE" Value="65535" />
<!--Rotate the log file once it exceeds 50 MB (expressed in bytes). -->
<NameValPair ParamName="MAX_ROTATION_SIZE" Value="52428800" />
<!--Rotate the log file after 24 hours (expressed in seconds). -->
<NameValPair ParamName="MAX_ROTATION_TIME" Value="86400" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
</CompoundList>
</CompoundList>
In addition to controlling the content of component-specific logs (in other words, the levels of logging that are reported), you can send the output collected at any log level to the log "writer" of your choice. For instance, you can direct catastrophic errors to the system log, but send trace-level debugging information to a disk file of your choice.
You determine where log data gets sent by setting the value of the LOG_WRITER parameter in a log-handler definition in the log configuration file.
Each of the three log writers supplied formats log data into an appropriate format and directs the output to a specific destination such as a system log or a data file. These log writers are described in Table 10-3.
Table 10-3 Log Writers
| Writer | Description |
|---|---|
|
SysLogWriter |
This writer records data to the system log file for the machine that hosts the component being logged. For Windows machines, this is the application log file, which you can view by navigating to: My Computer, Manage, Event Viewer, Application. For Unix platforms, the name and location of the system log file can vary according to the machine and the preferences of the system administrator. Consult the administrator of the machine for the file location. Typically, the system log file contains event information recorded by Oracle Access Manager and by other applications and the host operating system as well. By default, the logging configuration file specifies that Fatal, Error, and Warning messages be sent to the system file. |
|
FileLogWriter |
This writer is recommended when you want a disk file to record log data for an Access Server, Identity Server, or other single-process application. This writer enables you to specify the size of the buffer used for writing the file, the size at which the file is rotated, and the interval at which the file is rotated, regardless of size. FileLogWriter opens the log file and holds it open for disk writes until the approximate file size limit or file rotation interval has been reached; therefore, it is unsuitable for situations in which more than one process needs to write to the same log file. For logging in multi-process situations, see MPFileLogWriter in this table. |
|
MPFileLogWriter |
This writer resembles the FileLogWriter, except it opens and closes the log file each time it writes data to the file. This enables multiple processes to write to the file in turn. However, this practice can slow performance substantially. Therefore, Oracle recommends using MPFileLogWriter only when FileLogWriter fails to record logging data from some of the processes associated with a multi-process application such as an AccessGate installed on a multi-process Web server (such as Apache) or the Linux or Solaris versions of the iPlanet Web server. |
The log configuration file conforms to a standard format, which is parsed during component start-up and at other key points. Although you can edit parameters and add or subtract certain sections known as log-handler definitions, you should not change the underlying format of the log configuration file, or else the configuration parameters may become unparsable.
Example 10-2 lists the elements in a log configuration file with examples included as well. (The positions of elided content are indicated by ellipses.) For a listing of the default log configuration file, see Example 10-1 or Example 10-7.
Example 10-2 Log Configuration File Structure (with Sample Content)
An XML file header that declares the relevant XML version, which is always 1.0, and the encoding format, which is always ISO-8559-1. Note that this header statement differs from the other XML statements in this file in that it begins with "<?" and ends with "?>"
<?xml version="1.0" encoding="ISO-8859-1" ?>
A compound list that contains:
<CompoundList...>...</CompoundList>
The relevant XML name space for the log configuration file (within the opening tag)
xmlns="http://www.example.com"
The name of the compound list (within the opening tag)
ListName="logframework.xml.staging"
A simple list that contains:
<SimpleList>...</SimpleList>
A name/value pair for the LOG_LEVEL_THRESHOLD parameter:
<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_WARNING" />
Another name/value pair for the AUTOSYNC parameter:
<NameValPair ParamName="AUTOSYNC" Value="True" />
One or more compound lists, which, at this particular level, are known as log-handler definitions. Each contains:
<CompoundList...>...</CompoundList>
The relevant XML name space (within the opening tag)
xmlns="http://www.example.com"
The name of the compound list (within the opening tag)
ListName="LOG_CONFIG"
And one or more value/name lists, each of which contains:
<ValNameList...>...</ValNameList>
The relevant XML name space (within the opening tag)
xmlns="http://www.example.com"
The name of the value/name list (within the opening tag)
ValNameList ListName="LogFatal2Sys"
The following three mandatory name/value pairs:
The LOG_LEVEL parameter
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL" />
The LOG_WRITER parameter
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
The LOG_STATUS parameter
<NameValPair ParamName="LOG_STATUS" Value="On" />
And none, some, or all of the following four name/value pairs, which are relevant only if you specified FileLogWriter or MPFileLogWriter for the LOG_WRITER parameter.:
The FILE_NAME parameter
<NameValPair ParamName="FILE_NAME" Value="oblog.log" />
The BUFFER_SIZE parameter
<NameValPair ParamName="BUFFER_SIZE" Value="65535" />
The MAX_ROTATION_SIZE parameter
<NameValPair ParamName="MAX_ROTATION_SIZE" Value="52428800" />
The MAX_ROTATION_TIME parameter
<NameValPair ParamName="MAX_ROTATION_TIME" Value="86400" />
The XML tag language employs a tree-like structure with lists of elements corresponding to the leaves on a branch.
Within a given list, parallel elements can be presented in any order as long as the elements themselves remain intact and entirely within the tags that originally bracketed them. For example, the name/value lists in Example 10-3 and Example 10-4 are equivalent:
Example 10-3 Name/Value List
<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys"> <NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ERROR" /> <NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" /> <NameValPair ParamName="LOG_STATUS" Value="On" /> </ValNameList>
Example 10-4 Name/Value List
<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys"><NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" /><NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ERROR" /><NameValPair ParamName="LOG_STATUS" Value="On" /></ValNameList>
Similarly, within a given tag, the attributes (except for the tag name, which must always be the first element within the tag brackets) can be reordered, as long as they remain intact and within the tag elements that originally bracketed them. The opening tags for a name-value list in Example 10-5 and Example 10-6 are equivalent:
Up to four interconnected factors determine whether logging is active for a given component at a given log level. These factors are listed in the following table:
Table 10-4 Factors that Determine Whether Logging Is Active
| Factor | Importance | Description |
|---|---|---|
|
Primary |
This parameter provides a convenient means to limit log output through a single setting. It takes precedence over all other settings by setting an absolute threshold within the log level hierarchy described in Table 10-1. For levels that are more fine-grained than the threshold level, no logging takes place, regardless of the other settings. For Identity Servers only, see "Configuring Logs in the Identity System Console" for details on the relationship between configuration file and GUI-based settings. |
|
|
Secondary |
This parameter toggles logging on or off, providing it does not get overridden by the log threshold level. See the previous row for details. |
|
|
Secondary |
When this parameter is set to True, changes that you make to logging parameters in the Identity System Console take effect immediately without a server restart and the changes are saved to the configuration file. When |
|
|
The physical position of a log handler |
Secondary |
A single log-configuration file can contain as many as three log-handler definitions for a single log level. Three different log handlers are required if you wish to send output to each of the three log writers.
When the LOG_STATUS settings in these log handlers conflict, the setting in the log-handler definition closest to the physical end of the log configuration file is read last. Therefore, it takes precedence over the LOG_STATUS settings in all previous log-handler definitions for the same log level.
The state of the LOG_STATUS parameter in the "last read" log-handler definition for a given level takes effect for all the log-handler definitions for that level. For example, you can set LOG_STATUS to Off for the first two log handlers that aim at a certain level, yet logging can still occur for all three handlers, because LOG_STATUS happens to be On for the third and final log handler in the configuration file.
As previously mentioned, the LOG_STATUS settings at any given level become moot if that level is more fine-grained than the current LOG_THRESHOLD_LEVEL. In such a case, neither conflicting settings among the log handlers, nor the order in which the log handlers appear is of consequence, because logging cannot be activated at this level.
A watcher thread picks up changes to the log file every minute (60 seconds) and ensures that changes take effect. It is unnecessary to restart the server.
|
Note: For Identity Servers, edits made through the Identity System Console are written to oblog_config.xml only if the AutoSync parameter in this file is set to True. If this parameter is set to False, the old configuration file settings take effect after the server is restarted. |
At minimum, each log-handler definition sets five parameters, as listed in Table 10-5.
Table 10-5 Mandatory Log Configuration File Parameters
| Parameter | Comment |
|---|---|
|
This specifies the relevant XML namespace for the current list and is identical for all log-handler definitions in a given logging configuration file. Example:
|
|
|
These names are required for all the lists in the logging configuration file. Wherever possible, preserve the default list names. When creating a new log-handler definition, try to select a name for the associated name/value list that easily distinguishes the entry from all other entries in the logging configuration file. Examples: WarningsAndAboveToSyslog sends Fatal, Error, and Warning messages to the system log file. WarningsOnlyToFileLog128KBuffer sends messages from just the Warning level to a 128KB buffer, and hence to a disk file. TraceOnlyToMPRotateDaily sends messages from just the Trace level to the multi-process file writer, which opens and closes the file each time it writes to disk. This file is replaced with a fresh (empty) file every day, regardless of the size of the file at the time of replacement. |
|
|
This specifies one of the nine available log level settings. See Table 10-1. The default logging configuration file activates logging for three levels: Fatal, Error, and Warning. Output is sent to both the system log and the log data file for the component doing the logging. |
|
|
This specifies which log writer handles output for a given log-handler definition. See Table 10-3 for a list of the supported choices. |
|
|
This parameter turns the log handler on or off, as explained in the next section. |
If you specify FileLogWriter or MPFileLogWriter as for the LOG_WRITER parameter, the four parameters detailed in the following table become relevant. The first becomes mandatory, while the other three are optional.
Table 10-6 Log Data File Configuration Parameters
| Parameter | Description | Default |
|---|---|---|
|
Used only for the FileLogWriter or MPFileLogWriter. It represents the name (and location) of the file to which logging information is written. You can prepend an absolute path to the file name so as to store it somewhere other than the default location, which is:
where If you do not specify a file name, the default applies. When you create more than one log-handler definition that sends output either to FileLogWriter or MPFileLogWriter, make sure that you specify different file names in each case so that multiple handlers do not attempt to write to the same file. This caution does not apply to log handlers accessing the SysLogWriter. |
oblog.log |
|
|
This parameter represents the size of the buffer used to store logged data being written to the log file. If you set the buffer value to 0, no buffering is performed. (This ability to turn off buffering can be useful when a system failure occurs). In the event of a system failure, Fatal-level messages are always flushed to the log file. If you do not specify the buffer size, the default applies. |
65535 (64KB) |
|
|
When the log file reaches this size (in bytes), the file is renamed and a new file is created with the file name originally used by the just-renamed file. For example "oblog.log" becomes "oblog.log 1081303126." The number represents the time when the file was created. If you do not specify this parameter, the default is used. |
52428800 (512KB) |
|
|
The time interval, in seconds, when the log file is renamed, whether or not it has reached the maximum rotation size. If the maximum log file size is not reach between two time-triggered file rotations, the numbers appended to the log files created differ by the number of seconds in the rotation interval. For example, "oblog.log. 1081389526" and "oblog.log. 1081303126"differ by 84.600, which is the number of seconds in 24 hours, the rotation interval set in the logging configuration file. If you do not specify this parameter, the default is used. |
86400 (1 day, in seconds) |
The default log configuration file installed with each component activates only the highest three levels (Fatal, Error, and Warning) in the hierarchy of logged events.
Also by default, all log output is directed to the system log.
On Windows machines, you can view the system log for the machine hosting the component you are logging by navigating to: My Computer, Manage, Event Viewer, Application. System event entries for the components being logged are interspersed among the system events reported for the operating system and non-Oracle Access Manager applications.
For the Solaris and Linux environments, the location of the system log is recorded in a system configuration file whose particulars can vary from machine to machine. For the name and location of this system file, consult the owner of the machine hosting the component whose system log you wish to examine.
The following listing presents the content of the default log-configuration file installed with each component. The embedded comments, which have no effect on the actual function of the file, have been removed in order to expose the underlying structure of the file:
Example 10-7 The Default Log Configuration File (without embedded comments)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<CompoundList xmlns="http://www.example.com ListName="logframework.xml.staging">
<SimpleList>
<NameValPair ParamName="LOG_THRESHOLD_LEVEL" Value="LOGLEVEL_WARNING" />
<NameValPair ParamName="AUTOSYNC" Value="True" />
</SimpleList>
<CompoundList xmlns="http://www.example.com" ListName="LOG_CONFIG">
<ValNameList xmlns="http://www.example.com" ListName="LogFatal2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_FATAL" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<ValNameList xmlns="http://www.example.com" ListName="LogError2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ERROR" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<ValNameList xmlns="http://www.example.com" ListName="LogWarning2Sys">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_WARNING" />
<NameValPair ParamName="LOG_WRITER" Value="SysLogWriter" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
<ValNameList xmlns="http://www.example.com" ListName="LogAll2File">
<NameValPair ParamName="LOG_LEVEL" Value="LOGLEVEL_ALL" />
<NameValPair ParamName="LOG_WRITER" Value="FileLogWriter" />
<NameValPair ParamName="FILE_NAME" Value="oblog.log" />
<NameValPair ParamName="BUFFER_SIZE" Value="65535" />
<NameValPair ParamName="MAX_ROTATION_SIZE" Value="52428800" />
<NameValPair ParamName="MAX_ROTATION_TIME" Value="86400" />
<NameValPair ParamName="LOG_STATUS" Value="On" />
</ValNameList>
</CompoundList>
</CompoundList>
The default log configuration file follows the abstract structure presented in "Log Configuration File Structure"
The simple list near the top of the file sets LOG_THRESHOLD_LEVEL to the Warning level. Since the threshold parameter takes precedence over all others, none of the levels that are more fine-grained than Warning are logged, regardless of the settings in the rest of this file.
The simple list also sets the AUTOOSYNC parameter to True. This setting enables you to save the configuration values you set in the Identity System console to this configuration file so that they persist after you restart the Identity Server. Although the AUTOSYNC setting appears in the default configuration files for all of the components, it is relevant only for Identity Servers.
The nested compound list contains four log-handler definitions. The first, named LogFatal2Sys, sets the LOG_LEVEL affected by this definition to Fatal and sets LOG_STATUS to On. As previously noted, the threshold level for this configuration file is Warning, which is more fine-grained than Fatal, so this definition is not overridden. The log output goes to the system log, because this is what the definition specifies through the LOG_WRITER parameter.
The LogError2Sys log-handler definition sends Error level messages to the system log. Error is located prior to the current threshold level (Warning), so this definition is in effect.
The LogWarning2Sys definition sends Warning level output to the system log. Like the two previous log-handler definitions, it is not overridden by the current LOG_THRESHOLD_LEVEL parameter.
LogAll2File, the final log-handler definition, appears to send output from all eight log levels to a disk file named oblog.log. However, LOG_THRESHOLD_LEVEL, which is currently set to Warning, takes precedence, so only the output from the Fatal, Error, and Warning levels gets recorded in the log file.
Since output from LogAll2File goes to the FileLogWriter, the parameters governing file name, buffer size, rotation size, and rotation interval all take effect.
In sum, the default configuration file sends Fatal, Error, and Warning messages to both the system log and a default log data file named oblog.log.
For Identity Servers only, you can modify certain log settings through the Identity System Console. Alternatively, you can edit the log configuration file manually.
To view or modify log-handler definitions
From the Identity System landing page, click the Identity System Console link.
If you are already logged in, click the Identity System Console tab.
From the Identity System Console, click the System Configuration sub-tab, then click the Identity Servers link in the left navigation pane.
The List of All Identity Servers page appears.
Click the link for the Identity Server whose activity you want to log.
The Details for Identity Server page appears with a list of log-handler definitions at the bottom of the page.
Examine the Log Threshold setting above the Log Handler Definitions table. This represents the current LOG_THRESHOLD_LEVEL.
If you want to change this setting, click Modify at the bottom of the page and proceed to "To modify the log threshold from the Identity System Console". Otherwise, continue to the next step.
In the table of log-handler definitions, click the link for the log handler you wish to examine or change.
The Modify the Log Handler Definition page appears. From this page, you can specify values as described in Table 10-5. If you specify File in the Output To field, you must complete the fields described in Table 10-6.
You can change the defaults for the log file name, log file maximum size, log file rotation interval, and log buffer maximum size, as listed in Table 10-6.
Click Save.
To modify the log threshold from the Identity System Console
From the Identity System Console, click the System Configuration sub-tab, then click Identity Servers in the left navigation pane.
Click the name of the Identity Server whose settings you want to examine.
Click Modify at the bottom of the Details of the Identity Server page.
Use the list to set the Log Threshold Level to the value you want.
Click Save.
The change takes effect immediately. If AUTOSYNC is True in the log configuration file, the change is written to the log configuration file so that the change persists after you restart the server.
To add or delete a log-handler definition
From the Identity System Console, click the System Configuration sub-tab, then click the Identity Server link in the left navigation pane.
Click the name of the Identity Server to which you wish to add a log-handler definition.
Click Modify at the bottom of the page.
The Modify Identity Server page appears.
Under Log Handlers Definition, complete the appropriate action:
To delete a log output configuration, check the box next to the appropriate link, then click Delete.
To add a log writer, click Add.
If you click Add, the Add a New Log Writer page appears.
Supply a name and a log level for the new log writer.
Verify that the log level is the same as or higher than the current log threshold level, as described in "To view or modify log-handler definitions".
If the new log level is lower than the current threshold level, set the threshold level to the new log level or lower, as detailed in "To modify the log threshold from the Identity System Console".
If you choose to output to a file rather than the system log, you must supply a file name and path, as described in Table 10-6.
Click Save.
