Log Files



This is the log file of the Jedox server. This file can grow in size relatively quickly. The detail level of logging can be set in palo.ini. The different detail levels are described below:

Detail level Description

Output of fatal errors. If this occurs, the Jedox server should be stopped (the server may stop itself) to correct the error. It is not advisable to ignore the error as it may lead to database corruption. Example: no storage space left on the disc.

Warning Output of warnings. This error should not generally lead to a corrupt DB, but it should be investigated.
Info Output of general notes concerning the mode of operation. This is the default level.
Trace & debug This output is very detailed and serves the Jedox development.

After changes in palo.ini have been made, the Jedox Server has to be restarted to make the changes effective. After stopping the Jedox Server, this log file can also be deleted or saved. The Jedox Server will create olap_server.log anew if it does not exist when the server starts.

OLAP server performance information

The OLAP Server can log certain information regarding performance and resource usage into a dedicated log backend, using the syslog protocol. The intended backend is provided by the Jedox Tomcat Process, and logged information is presented in the Jedox Web Performance Monitor. The logging is optional, is turned off by default, and can be configured in the configuration file palo.ini.


This is the log file of .Net Addin. It logs Excel Add-in Ribbon and dialog errors. This log file can be deleted or copied every time Excel is idle. Jedox Excel Add-in will create this file anew if it does not exist and if it is necessary.


This is the log file oPalo*.Xll. It logs calculation errors of Palo formulas in the cells.


This file logs errors of Jedox Office Add-in.


This file logs activities and errors of the Jedox Integrator server, and serves as a valid point of reference for server activity. You can change log parameters in the file <Jedox install path>\tomcat\webapps\etlserver\config\config.xml. 

Default settings:

<parameter name="logFileSize">50M</parameter>
<parameter name="logBackupIndex">20</parameter>

With these settings, a maximum of 20 archive logs will be held. If file size becomes larger than 50 MB, a new log file will be created and the oldest file will be deleted. Numeric suffix of all other files will be incremented by 1.

Note: the entries in the etlserver.log refer to Jedox Server time, which means that the server’s time zone is the reference point for timestamps in Jedox Web. However, the client’s time zone appears in the client’s ETL monitor, so the same job may show different timestamps to different people. This discrepancy should be taken into consideration when viewing log data and monitoring jobs.


This file logs activities and errors of JedoxSuiteCoreService (the Report Designer component of Jedox Web). You can change log parameters in the file …\core\config.xml (Windows) or …/core-Linux-i686/etc/config.xml (Linux). 


<logging level="info" ignore_repeated="true">
    <logger target="console://" />
    <logger level="info" target="file://.../Jedox Suite/log/core%Y-%m-%d.%N.log">
    <file_rotation size="200KB" day_of_week="Sunday">
    <file_archive dir=".../log/archive" max_size="1MB" min_free_space="1000MB" /></file_rotation>


<logging level="info" ignore_repeated="true">
Here you can define which log level is generally used. Available log levels are critical, error, warning, notice, info, and debug. Level defined in <logging> tag is default log level (fallback), so you can omit level definition in <logger> tag.

<logger level="info" target="file://.../Jedox Suite/log/core%Y-%m-%d.%N.log">
Here you can define which log level is used for the named individual logger and where the log message is written to. You can add the following patterns in the file name:

To add the actual







file counter /
with an optional width specification

use this pattern







%N      /         %3N


core_%N.log (result:  core_1.log, core_2.log,…)
core_%3N.log (result:  core_001.log, core_002.log,…)
core_%Y%m%d.log (result:  core_20080705.log, core_20080706.log,…)
core_%Y-%m-%d_%H-%M-%S.%N.log (result:  core_2008-07-05_13-44-23.1.log, core_2008-07-06_16-00-10.2.log,…)

<file_rotation size="200KB" day_of_week="Sunday">
Here you can set a value for when the log file should be rotated. You can define a size or a time or both.  In the last case, the rotation will be executed whichever comes first.
The following attributes are possible: size (between 1KB and 9999MB), time, day_of_week and day. All attributes are optional. Pattern for time input is defined as “hh:mm:ss”. Additionally, you can define rotation on the specified day of every week or day of each month.


<file_rotation size=”100KB”> : file will be replaced after reaching 100 KB size.
<file_rotation time=”08:05:05″ day_of_week=”Monday”> : file will be replaced every monday at 8:05:05.
<file_rotation size=”500KB” day=”1”> : file will be replaced after reaching 500KB size or on the 1-st of every month, at midnight (implicit), whichever comes first.

<file_archive dir=".../log/archive" max_size="10MB" min_free_space="5000MB" />
After being closed, the rotated files can be collected. First, a file collector must be set up by specifying the target directory where the rotated files should be collected and, optionally, size thresholds. The following attributes are possible:

  • dir (path of the target directory)
  • max_size (maximum total size of the stored files)
  • min_free_space (minimum free space on the drive)

The max_size and min_free_space parameters are optional; the corresponding threshold will not be taken into account if the parameter is not specified.

Was this post helpful?
NoYes (-2 rating, 2 votes)