CallScripter allows the logging of a variety of information from the main application itself, installed components and services, and at a client-side level. This article will cover the different types of logging, and how to enable and configure them.
Article Contents
Core Application (CallScripter) Logging
CallScripter itself can store logs on the server at a chosen level of detail.
Enabling Logging
Using the defaults laid down during the installation process, CallScripter 4.5 will not log any errors. The logging service must be installed, running/active, and configured for logging to take place.
System Manager -> Service Manager -> CallScripter Logging Service.
The service must be installed and started. The ServicePort set in the service’s options needs to be a free port number on the web service. When the service is started it will automatically create a log file (named CallScripter.log) in the following location:
%CallScripter Root%\CallScripter Data\Logs\CallScripter.log
Once the logging service has been started the application will start to push information to the service. The service is then responsible for writing the information to the log file. A configuration file is available in the following location to control the level of logging that the service writes to the log file:
%CallScripter Root%\CallScripter Data\Logs\logging.config
By altering this file, the level of logging can be controlled, number of and size of backups be configured, and the log information formatted. This is explained below in the
Logging Configuration section.
Log Location
Logs are stored by default in:
%CallScripter Root%\CallScripter Data\Logs\
With the default settings, the log will automatically be broken into 1MB files, with up to 10 of these backup logs stored. When a log beyond the 10th is created, the oldest backup log is removed.
CallScripter Services & Service Manager Logging
CallScripter Services also store logs on the server at a chosen level of detail.
Enabling Logging
Each service running within CallScripter can have logging configured individually. This can be pre-configured for all services before they’re installed, or individual services once they’ve been installed.
When a service is installed by the service manager it takes a copy of the contents from two folders:
%CallScripter Root%\CallScripter Data\Service Manager\BaseFrameWorkInstall
%CallScripter Root%\CallScripter Data\Service Manager\Available Components\%Component%
where %Component% refers to the relevant subfolder for the component to be installed. It then creates a folder with a GUID inside the following location:
%CallScripter Root%\CallScripter Data\Service Manager\Components
Within each GUID folder will be a CallScripter.FrameworkService.exe.config file which sets the logging level on a per component basis which is inherited from the %CallScripter Root%\CallScripter Data\Service Manager\BaseFrameWorkInstall folder at the time of installing the component.
All Services
To configure all controls prior to their installation, only a single file needs to be altered:
%CallScripter Root%\CallScripter Data\Service Manager\BaseFrameWorkInstall\CallScripter.FrameworkService.exe.config.sample
Altering this file will set the logging state of all services installed after the change is made. Note that this doesn’t affect already installed services, and they must be edited individually.
Individual Services
To configure individual services after their installation, a single file needs to be changed in each relevant instance:
%CallScripter Root%\CallScripter Data\Service Manager\Components\%Component ID%\%Instance ID%\CallScripter.FrameworkService.exe.config
where Component ID and Instance ID are found by selecting the service in System Manager -> Service Manager, and expanding the Options area below the relevant service. The IDs are listed at the bottom of the expanded area.
The specific configuration options are explained below in the “Logging Configuration” section.
Note that the logging level should only be changed while the service is stopped, or the logging may not behaved as intended.
Log Locations
The service manager will store logs and communications pertaining to itself automatically. These logs cannot be configured in terms of level of detail, and are always enabled:
%CallScripter Root Folder%\CallScripter Data\Service Manager\log.txt
The output of the individual service’s logs can be viewed via the System Manager -> Service Manager by clicking on the “View Log” hyperlink shown at the right of each component, or found manually with the Component ID and Instance ID displayed at the bottom of the service’s Options:
%CallScripter Root%\CallScripter Data\Service Manager\Components\%Component ID%\%Instance ID%\FrameworkLog.txt
With the default settings, the log will automatically be broken into 10MB files, with up to 5 of these backup logs stored. When a log beyond the 5th is created, the oldest backup log is removed.
Client-side Telephony Logging
Each agent PC will create its own individual client log for the CallScripter CT Provider (Agent Desktop), but by default this log will be configured to only show errors that are occurring. The logging level can be set at a higher level to allow the log to capture all communication being sent to and from the client.
If there are issues with any CT provider, scripts not popping, delay on script pop, etc., then logging should be enabled, the testing or error reproduction steps followed, and the log files
sent to the CallScripter Helpdesk for analysis.
Enabling Logging
The logging configuration file is stored on the agent’s computer at this location (by default):
C:\Program Files (x86)\CallScripter\CallScripter CT Providers\CallScripter.CTI.Management.dll.config
Log Location
The generated logs are stored on the agent’s computer at this location (by default):
%localappdata%\CallScripter\CommunicationToolbar\log.txt
With the default settings, the log will automatically be broken into daily files, with a log file for each of the past 7 days. When a log beyond the 7th is created, the oldest backup log is removed.
Logging Configuration
CallScripter uses the open source Log4Net library to handle its logging. Examples of alternative logging options (file per day, to SQL database, etc.) can be found on
Log4Net's public website. The configuration for creating a new log file per day is under the
RollingFileAppender section of this website.
Additionally, there is
an SDK for detailed information on particular options or settings.
Whenever editing logging settings, it is recommended that a backup is taken of the file before editing it. This ensures that if something goes wrong the logging state can be reverted to normal simply by restoring the backup, and is a safer way to make temporary changes (for example to the logging level) than manually making and reverting changes within the file.
Logging Levels
The most common change likely to be made to logging is to alter the logging level. The level sets the minimum severity of an event required for it to be logged, running from entirely disabled to logging all events.
To change the logging level in one of the open configuration files, search within the file to find a line like this:
<level value=”ERROR”/>
The ERROR section of this string declares the minimum severity of an event for it to be logged, selected from the following potential levels (in order of comprehensiveness):
- ALL
- DEBUG
- INFO
- WARN
- ERROR
- FATAL
- OFF
Typically, the level will be set to ERROR by default, meaning that it will only report errors and fatal conditions. If set to WARN, it would report both errors and fatal conditions as with ERROR, but also report potentially harmful situations. Further explanation of the different levels can be found in the
relevant Log4Net documentation.
For most purposes, when asked to enable logging (unless specified otherwise) this means to set the level to ALL, thus harvesting all possible information to aid in troubleshooting efforts. However, do be aware that this will generate significant load on the application, and it’s encouraged that you only set the level to ALL for brief durations while actively testing a problem!
Ideally, the program is setup and ready to run through the problem that prompted the need for troubleshooting, the logging level is set to ALL for that program briefly while the problem is reproduced, and then the logging level is returned to the previous setting upon completion.