The logging feature enables you to analyze system performance and to troubleshoot issues.
You can configure logging for individual WebGate instances of the following components:
10g WebGates
11g WebGates
Custom Access Clients (Access Manager SDK)
Note:
Unless explicitly stated, all information in this section applies equally to 10g and 11g WebGates. For instance, the location of the log configuration, oblog_config_wg.xml, has changed for 11g but the content of the file and most other specifics have not.
This section discusses the following topics:
You can configure different logging levels for different functional areas of a component instance.
For example, you can capture debug data for LDAP activity while recording only error-level data for all other component activity. You can also record the time taken for each request that a component processes, and you can send different levels of log data to different destinations. For example, you can send error information to a file and all other log data to the system log.
Securing Sensitive Information: Access Manager handles sensitive information about users. On some sites, this includes user password, date of birth, a social security number, security questions and answers for lost password requests. Sensitive data on your site might include a security number or other information you want to secure. At certain logging levels, sensitive information might be captured. Today, you can filter sensitive information out of log files, as described in "Filtering Sensitive Attributes".
Configuring Logging: You configure logging by editing a configuration file that is stored with the Webgate. See "About Log Configuration File Paths and Contents".
Logging Levels: You can request logging at various levels. The highest level is Fatal and the lowest level is Trace. See "Log Levels" for details.
Logging Destinations: In the log configuration file, a parameter known as a log writer determines the destination for log output. See "About Directing Log Output to a File or the System File" for details. You create a complete definition for your log output by identifying a log writer and a log level. This complete definition is known as a log-handler. See "Parameters in the WebGate Second Compound List and Log Handlers" for details.
A logging level determines the amount of data that is written to the log data file. Each logging level is cumulative, that is, each level contains all the data generated by the higher levels.
For example, Error logs contain all the data generated by the Fatal logs, plus the events that are specific to the Error category.
Table 9-5 describes the levels. The default log level is Warning: LOGLEVEL_ WARNING.
Table 9-1 Logging Levels
| Level | Number of Events Reported | Description |
|---|---|---|
|
|
> 60 |
Records critical errors. Generally, these events can cause the component to exit. In the event of a system failure, Fatal-level messages are always flushed to the log file. |
|
|
> 960 |
Records events that may require corrective action, for example, a component is unavailable. Error logs can also be generated for transient or self-correcting problems, for example, failure to connect to another component. |
|
|
> 1200 |
Records issues that may lead to an error or require corrective action in the future. |
|
|
> 400 |
Records completed actions or the current state of a component, for example, the component is initializing. |
|
|
> 400 |
Records debugging information. Typically, the information at this level is only meaningful to a developer. |
|
|
> 100 |
Records advanced debugging information. This level augments the Debug1 log level. Typically, the information at this level is only meaningful to a developer. |
|
|
> 900 |
Records a large amount of debugging information or data pertaining to an expensive section of the code. 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. These logs can contain sensitive information. |
|
|
> 900 Access Manager API > 150 third-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. These logs can contain sensitive information. |
|
|
> 5000 |
This level includes all the events and states from all other levels. |
Compound Lists: You can collect log data from non-adjacent levels and send different levels of log data to different destinations. For example, you can send the Fatal logs to the system log, and write Error logs to a file. See "Parameters in the WebGate Second Compound List and Log Handlers" for details.
Threshold: You configure a global cutoff, or threshold, for logging on the LOG_THRESHOLD_LEVEL parameter in the log configuration file. By default, if a configured level for a log-handler exceeds the cutoff, the log data is not collected. Note that logs can fail to be written despite the configured level because the LOG_THRESHOLD_LEVEL parameter takes precedence over the level configured in the log-handler. Only the MODULE_CONFIG section of the log configuration file overrides the global threshold. See "Parameters in the WebGate Simple List and Logging Threshold" for details.
Overrides: You specify function- or module-specific overrides for the global logging threshold on the MODULE_CONFIG parameter. See "Configuring Different Threshold Levels for Different Types of Data" for details.
Note:
The Trace and Debug3 level logs can contain sensitive information. For more information about sensitive information, see "Filtering Sensitive Attributes".
Each line of the log output file follows a particular structure. A line starts with a date and time stamp, followed by the thread that is processing the request, the name of the function or module being logged, and the log level.
The following is a snapshot of the left-most columns of the log output file:
2007/06/01@00:50:56.859000 5932 2672 DB_RUNTIME DEBUG3 2007/06/01@00:50:56.859000 5932 2672 DB_RUNTIME TRACE 2007/06/01@00:50:56.859000 5932 2672 LDAP DEBUG1 2007/06/01@00:50:56.859000 5932 2672 LDAP TRACE 2007/06/01@00:50:56.859000 5932 2672 LDAP TRACE
The two columns to the right of the log level are internal code references, and can be ignored. The following is an example of these columns:
0x00000205 ldap_connection_mngr.cpp:212
To the right of the internal code reference columns, you see the log message that is associated with this log level, for example, "Function called" or "Function returned," followed by the name of the function, as illustrated in the following example:
"Function called" _CallName^ldap_init
The log message and function name can be followed by additional information, for example, the duration of the process, the address space where the function is running, or state information, as illustrated in the following examples:
"Connection health check result" Server^dlsun4072 Port^389 Server Priority^1 Connection available^true "Function entered" _TraceName^ConnectionWatcherThread::CheckPrimaries "Function exited" _TraceName^ConnectionWatcherThread::CheckPrimaries TraceDuration^0.000028 "Connection Pool Status in ValidateConnections() "NumLivePrimaryConnections^1 Maximum Connections^1 UpConnections^1 Failover Threshold^1 Max Session Time^0 SleepFor^60
To secure sensitive information and ensure that it is not included in the output of the logging operation, see "Filtering Sensitive Attributes".
See Also: