Manage the Server Logs

Log Files

About the Server Log Files

The server log files are the most important diagnostic tool of the Acrolinx Platform. The log files contain a record of all steps of the startup process, all events during runtime, or the stop of each server on the current computer. Examining the log files is the best way to find any errors that occur during the server start process, server runtime, or the server stop process.

Types of Log Files

Acrolinx generates the following types of log files:

TypeDescriptionFile name
The core server log fileThis log file contains a record of all steps of the startup process and all events during runtime of the core server that is installed on the current computer.coreserver.log
The language server log filesThese log files contain all steps of the startup process and all events during runtime of all language servers that are installed on the current computer.

<LANGUAGE_SERVER_ID>.log


<LANGUAGE_SERVER_ID> is the abbreviation ls- concatenated with the number of the language server.

The term contribution log fileThis log file contains information about the template loading process for the term contribution and "add comment" pages. If you’ve customized these templates, any issues with your customizations are logged in this file.term_contribution.log
The license audit logThis log file contains an audit trail for all server activity that involves licensing.license.log
The terminology transfer log fileThis log file contains a record of events from all terminology import and export tasks.terminology_transfer.log
The term search log fileThis log file contains a record of the terms that users searched for in the Acrolinx Term Browser or the Terminology Manager.termsearch.log
The file-specific import log filesA log file is generated for each file that is imported in the Terminology Manager or Reuse modules. These file-specific log files contain a summary of import events for the file. Users can also open these log files from the Dashboard after an import has completed.
The web request log fileThis log file contains all the web requests that Acrolinx processes.request-yyyy_mm_dd.log
The security log file

This log file contains security relevant log messages for the core server. Unlike most other log files, it's stored in a separate directory by default: <INSTALL_DIR>\server\secure . We strongly recommend that administrators restrict read and write access to this directory.

audit.log

Log File Locations

The file-specific import logs are stored in the following directories:

  • Reuse import log files: <INSTALL_DIR>\server\www\output\reuseImportLogs
  • Term import log files: <INSTALL_DIR>\server\www\output\termImportLogs

The security log file is stored in the following directory: <INSTALL_DIR>\server\secure

All other log files are stored in the following directory: <INSTALL_DIR>\server\logs

If you delete the logs directory, the server can’t create new core server and language server log files, and a backup log file wrapper.log is written to the bin directory instead. To avoid this issue, delete only the contents of the logs directory or recreate the logs directory after you’ve deleted it.

Default Logging Behavior

The Acrolinx Platform and the wrapper add new log entries at the end of the log files. By default, the maximum file size for a log file is set at 20 MB. If any log file reaches this size, a new log file is created. The old log file is stored and overwrites an older backup copy.

The files wrapper.logging.conf and log4j.<SERVER_TYPE>.xml control the logging behavior of the core or language servers of the Acrolinx Platform.

Request Logging

The server writes a web server request log file with the format request-yyyy_mm_dd.log. This log file is rotated daily, all files older than 5 days are deleted.

By default, the coreserver.properties file contains the following property for request logging:

http.logging.filename=../logs/request-yyyy_mm_dd.log 
You can configure the location of the request logs, but keep in mind that if you don't save them in the Acrolinx logs directory, then log or support package downloads from the Acrolinx Dashboard won't contain the request logs.

You can adjust the timestamp expression 'yyyy_mm_dd' at the end of the filename. For example, change the timestamp expression to 'yyyy_mm' to rotate the request log monthly.

Configure how long the request logs are kept with the following property in the coreserver.properties:

http.logging.retaindays=5

Finally, to turn off request logging, configure the property in the  coreserver.properties like this:

http.logging.filename=


If you want to configure request logging for the language servers, then add the property to the language server's properties file. For example, to turn on request logging for language server 01:

  1. Open the ls-01.properties file.
  2. Add the following property:

    http.logging.filename=request-ls01-yyyy_mm_dd.log

Logging Levels

The Acrolinx log files contain entries that are prioritized into several logging levels. You can use the logging levels to find issues that require the most attention.

The following logging levels are used in the Acrolinx log files:

Logging LevelDescription
FatalFatal issues have the highest priority and cause the server to shut down immediately. You should address fatal issues as soon as they occur.
ErrorErrors indicate that a component of a particular module isn’t functioning correctly and that the module will produce unreliable results.
WarningWarnings indicate that non-critical components such as help files aren’t functioning correctly or couldn't be found.
InfoInfo entries describe the steps of the startup process and all events during runtime of the core server.
DebugDebug entries aren’t included in the log files by default. Debug entries provide information that can be useful for developers when troubleshooting a particular support issue.

Configuring the Logging Level

You can change the logging level to generate more detailed logs, which can assist in troubleshooting support issues.

To change the default logging level to debug, follow these steps:

  1. Open your overlay of the following file: <SERVER_TYPE>.log4j.xml

    For example, to edit the logging level for the core server, open your overlay of the file coreserver.log4j.xml.

    If you haven’t yet created an overlay of this file, create a new version of the file at the following location:

    %ACROLINX_CONFIGURATION_ROOT%\server\bin\

    Don’t edit the installed version of the file. Instead, always edit your overlay in the configuration directory

  2. Save your changes and restart the core server.

Configuring the Range of the Logging History

You can extend the range of your logging history by updating the maximum size of specific log files and the number of old backup copies to be kept.

To update the maximum size of specific log files or the number of backup copies of old log files, follow these steps:

  1. Open your overlay of the following file: wrapper.logging.conf

    If you haven’t yet created an overlay of this file, create a new version of the file at the following location:

    %ACROLINX_CONFIGURATION_ROOT%\server\bin\

    Don’t edit the installed version of the file. Instead, always edit your overlay in the configuration directory.

  2. Edit the following properties:

    wrapper.logfile.maxsize=<SIZE_IN_MB> 
    wrapper.logfile.maxfiles=<NUMBER_OF_FILES>

    For example, to configure a maximum log file size of 50MB and a limit of 3 backup copies of old log files, update the properties as follows:

    wrapper.logfile.maxsize=50m 
    wrapper.logfile.maxfiles=3
    The log files increase in size at a faster rate as the number of connected integrations increases.
  3. Save your changes and restart the core server.

    The changes affect logging for the core server and the language servers.

Security Logs

The security log file audit.log contains security relevant log messages for the core server. It's a structured log containing JSON objects, and contains logs for the following events:

  • user creation
  • user deletion
  • password change
  • role change
  • sign-in
  • sign-out

audit.log is stored in a separate directory by default: <INSTALL_DIR>\server\secure. We strongly recommend that administrators restrict read and write access to this directory, since audit.log could contain sensitive information.

You can change where audit.log is stored by editing coreserver.log4j.xml. For this reason, we also recommend that administrators restrict at least write access to coreserver.log4j.xml. Otherwise, someone could bypass any restrictions you've set up on <INSTALL_DIR>\server\secure.

You can never access the security logs from the Dashboard. The security logs are only accessible via the file system.

Accessing Log Files from the Dashboard

You can access and download most of the log files directly from the Dashboard. Users who can’t access the log file directories on the server computer can access the log files from the Dashboard instead. The Logs section offers two options:

  • View the most recent log entries directly in the Dashboard. You can select the desired log file and the number of lines to display (Maintenance Logs > View Recent Entries).

    To focus only on warnings and errors that were logged in each log file, select Show warnings and errors only.

  • Download all log files combined in a single ZIP file. You can create a ZIP file that contains all log files and download it via the displayed link (Maintenance > LogsDownload Full Package).

Users need a role with the appropriate privilege Download and view logs to use this feature.

You might not be able to access all language server log files if you’ve renamed the display name of your language servers.

To ensure that the log files from renamed language servers are available from the Dashboard, open the file  ls-<NUMBER>.wrapper in the bin directory, and ensure that the language server name in the parameter  wrapper.logfile is the same as the name in the parameter wrapper.app.parameter.1.

Example
wrapper.app.parameter.1=ls-05

wrapper.logfile=../logs/ls-05.log

You can never access the security logs from the Dashboard. The security logs are only accessible via the file system.