Server logging modes
You can configure the BMC Remedy AR System server to log activity for the following server functions:
- BMC Remedy Distributed Server Option
- Full Text Indexing
- Plug-in server
- Server Group
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:
- BMC Remedy Mid Tier – Mid tier logging and the Configuring the Log Settings page.
- BMC Remedy Distributed Server Option – DSO logging.
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. When this occurs, the previous log file is renamed with a .bak extension (for example, ARSystemInstallDir\arserver\Db\arsql.log.bak), and a new file is created. After the initial log is created, there are always two versions of the log file (the current one and the previous one).
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 >
< 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:
- Full Text Index
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.