- 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!
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:
- 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:
- In BO_Trace.ini...
- 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
- 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.
- Clear out old trace logs from the Logging directory
- Enable tracing.
- Start workflow (to reproduce the issue)
- Record the exact date and time of each action/click you perform.
- Copy the logs to a safe location for analysis and to ensure they are not automatically removed due to keep_num.
- Disable tracing.
- Revert changes to BO_Trace.ini, if desired.
File Extensions for log files
|_ncs.trc||trace file||Generally not useful.|
NCS traces are used for performances analysis
|_gc.log||JVM output and garbage collection data|
Generally not useful.
|.glf||Normal BI Server log file|
|.bxx||Backups generated when logs rotate||Generally 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)
- 2103024 - Master note - how to trace BI 4.x (servers and clients)
- 1526641 - How to enable tracing in SAP BusinessObjects Enterprise BI4.0
- 1670873 - How to enable logging for Life Cycle Manager (LCM) in BI4.0
- 1613472 - How to enable trace logging for BI40 Web applications
- 1936863 - How to enable detailed trace for Server Intelligence Agent
- 1804398 - How to enable traces for Translation Management Tool in BI 4.0
- 1711416 - BI 4.0: How to enable MDA tracing for OLAP-based universes
- 1934985 - How to enable IDT trace on BI 4.0
- 1691970 - How to enable tracing for Open Document in SAP BusinessObjects BI Platform 4.0
- How to generate and consume an E2E trace with BI4.x (for non-SolMan landscapes)
File format (column definitions)
Standard logs (.glf) in the SAP BusinessObjects Business Intelligence 4.x Platform contain 'columns' as described:
|Location||Almost always blank|
|Time||The time of the log entry.|
|Tzone||The time zone for the log entry|
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.|
|ProcessID||The process ID|
|ThreadID||The thread ID||The 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.|
|ThreadName||The thread name|
|Text||The actual log entry. This is very useful!|