Skip to end of metadata
Go to start of metadata


Usage

    • There are different ways of enabling logging depending on the component. See the additional resources links below.

Generally speaking, there are two key configurations to address when enabling tracing:

    • The server's own TraceLog setting, as defined within Central Management Console (CMC) > Servers > server's propreties
    • The options contained within the BO_Trace.ini file, especially append and keep_num
  • All that is necessary for a server to generate logs is to enable tracing within the CMC, but the options defined within BO_Trace.ini determine how logs are created and retained:
    • keep_num = the number of trace logs will be retained by an individual server.  Default value is 5, which on a busy server might represent 15 seconds of activity or less; therefore, it's highly recommended to boost this to a much higher value for the duration of the trace
    • append = defines if a trace log will be re-used by a server, e.g. if a Job Server is restarted it will continue to write to the previous trace log if append=true.  append=false also gives a clearer filename, which includes the process's PID. append=false is generally the preferred setting, and it needn't be changed back after tracing!
       

Enabling Logs

Within the Central Management Console you may select either a 'server' (Home-Servers) or an 'application' (Home-Applications) and specify a log level:

Example log entry:


Best Practices

  • Before collecting the logs, it's best to delete old logs, so to make it clearer which logs are relevant for your issue.
  • In general:
    1. In BO_Trace.ini...
      1. Define a keep_num value at or exceeding the number of trace logs you wish to be retained.  The default value of 5 minimizes disk cost, but on a busier server this may only capture a few seconds' worth of activity
      2. Also consider the append variable:  When set to true, existing trace logs will be re-used; when false, new trace logs will be generated for new processes, and will typically also contain the Process ID in their filenames. 
    2. Clear out old trace logs from the Logging directory
    3. Enable tracing.
    4. Start workflow (to reproduce the issue)
    5. Record the exact date and time of each action/click you perform.
    6. Copy the logs to a safe location for analysis and to ensure they are not automatically removed due to keep_num.
    7. Disable tracing.
    8. Revert changes to BO_Trace.ini, if desired.

File Extensions for log files

extensiondescriptionusefulness
_ncs.trctrace fileGenerally not useful.
NCS traces are used for performances analysis
_gc.logJVM output and garbage collection data

Generally not useful.
Only when troubleshooting a memory issues related to a Java process.

.glfNormal BI Server log file

Very useful.
These files will contain the actual activity done by the servers and will be of most use when troubleshooting.

.bxxBackups generated when logs rotateGenerally not useful.

Special Advice, Guidance & Tips by Log Name (particularly helpful)

These child pages provide advice and guidance by each Log Name:

For each 'Log Name' the following is provided:

  • Generic Search tips
  • Errors you can safely ignore (they are expected)
  • Errors you should take note of (they are not typically expected)

Additional Resources

File format (column definitions)

Standard logs (.glf) in the SAP BusinessObjects Business Intelligence 4.x Platform contain 'columns' as described:

ColumnDescriptionComments
Location Almost always blank
Guid  
TimeThe time of the log entry. 
TzoneThe time zone for the log entry 
TraceInformation, Debug 
Log  
Importance  
Severity

W for Warning, E for Error, A for Assertion

Probably very helpful. Typically errors and assertions tend to suggest a problem. However there are LOTS of errors or assertions that are managed and don't pose a problem as the software has handled them accordingly to prevent an error.
Exception  
DeviceName  
ProcessIDThe process ID 
ThreadIDThe thread IDThe thread ID can be very helpful. Once you've identified the thread (for where there was a problem), you can then filter the rest of the log on the same thread ID, to see what was going on 'before' the error. This is a common technique, as log files tend to contain log entries from all 'threads' in the process and you are probably need to look within 1 thread, not across all.
ThreadNameThe thread name 
ScopeTag  
MajorTick  
MinorTick  
MajorDepth  
MinorDepth  
RootName  
RootID  
CallerName  
CallerID  
CalleeName  
CalleeID  
ActionID  
DSRRootContextID  
DSRTransaction  
DSRConnection  
DSRCounter  
User  
ArchitectComponent  
DeveloperComponent  
Administrator  
Unit  
CSNComponent  
TextThe actual log entry. This is very useful! 
  • No labels