This documentation supports the 20.02 version of Remedy Action Request (AR) System.

To view an earlier version, select the version from the Product version menu.

Server logging modes

You can configure the BMC Remedy AR System server to log activity for the following server functions:

  • Alert
  • Archive
  • API
  • Escalations
  • Filters
  • Full Text Indexing
  • Server Group
  • SQL
  • Thread
  • User

To turn on any of these logging modes and to configure related logging options, such as the name and location of the log file, use the Remedy Management Console. To learn more about Remedy Management Console, see Managing the server group logs.

 You can activate and deactivate the various logging modes at any time while the program is running.

For more information about logging BMC Remedy Mid Tier and BMC Remedy Distributed Server Option servers, see:

After a log is activated, logging starts immediately. By default, each log file is restarted when you restart the BMC Remedy AR System server process or when you reactivate logging after it has been deactivated. 


The server must be running to generate output to the log files. If there is no logging output to one of these log files, review the arerror.log file to determine whether the server process itself has terminated.

Appending to an existing log file

To append to an existing log file, change the Log File Creation option in the logging tab to Append To Existing. If you select this option, data will be appended to the same log file each time logging is turned on or off, including when you restart the server. A backup of the log file is not created when the append option is selected. The log file grows to the maximum size configured, at which time the newest entries will overwrite the oldest entries.

Using the same log file for different log types

You can configure different types of logging to report to the same log file, providing a sequence of BMC Remedy AR System events. To do so, enter the same path and log file name for the logs you want to combine.


Do not combine the plug-in server, or distributed server log with other logs. If you do, the plug-in server, or distributed server information can be randomly interspersed in the log, and is therefore confusing to read.

This approach can be useful when tracing a transaction that might generate several types of log output. For example, an API log and SQL log that write to the same file provide a chronological list of SQL events that are triggered by specific API calls.


Combining different types of log output in the same log file can have an adverse effect on performance, because logging threads might have to wait for access to the log file.

Each log file entry begins with one of the tags in the following table. When a log file contains output from multiple traces, the tag identifies the action associated with the entry.

Log file tags


Type of log entry

< ALRT >


< API >

API function call

< DSO >


< ESCL >


< FLTR >


< SQL >

SQL command

< THRD >


< USER >

Login and logout

Creating per-thread log files

To decrease the impact to AR System performance when logging is enabled, you can create per-thread log files. (Select the Log Per Thread check box on the Log Files tab of the AR System Administration: Server Information form.)

You can create the following types of per-thread logs:

  • Alert
  • API
  • Escalation
  • Filter
  • Full Text Index
  • SQL
  • User
    The BMC Remedy Distributed Server Option (DSO), thread, plug-in server, and server group logs do not support per-thread logs.
    On per-thread logs, the thread ID is inserted into the log file name (for example, arapi-1444.log, arapi-1716.log, and arapi-1720.log for the API log).


    Thread IDs can be re-used from one running of the server to another, and different thread types can be assigned the same thread ID after the server is restarted. For example, during one run of the server, the file arapi-1142.log might contain log output for the Fast thread, but the same file name could be used to log the Admin thread after the server is restarted. Make sure you use the correct thread log for the current run of the server. To monitor which thread types are assigned to which thread ID, have thread logging turned on when the server starts.

Was this page helpful? Yes No Submitting... Thank you