This article describes how to configure logging for the swDBServer and TcpSubServer server application exec.
- swDBServer Logging
- TcpSubServer Logging
- Maintaining Log Files
- Sending a Copy to Systemite Support
- Maintaining Log Files
Note: The logging for the TcpSubServer is configured using a different file. In addition, there is an option to generate a DLQ file containing call measurements. |
Prerequisites
- A server installation directory containing all required files to run the server.
- We recommend that the log file be generated on a separate disk from the database, e.g.,
C:\SystemWeaver\Logs - location of the log files
D:\SystemWeaver\Database - location of the database file - Sufficient disk space must be available for storing the file
- A standard procedure for handling old log files
swDBServer Logging
A swServer.props file is needed and should be placed in the same directory as the server application files. SystemWeaver always provides an example swServer.props file in the Configuration files directory in upgrade packages. It is named swServer.props.example. Simply remove the .example suffix to use. Or, copy the following content (provided with typical values) into a text editor to create a swServer.props file.
swServer.props
# Set internal debugging # log4d.debug=TRUE log4d.rootCategory=INFO,Fil1 #log4d.rootCategory=DEBUG,Fil1 # Global disable level # log4d.disable=INFO # Override global disable level # log4d.disableOverride=TRUE # Set category factory # log4d.categoryFactory=TLogDefaultCategoryFactory # Set root priority # log4d.rootCategory=WARN,ODS # Establish category hierarchy #log4d.category.myapp=INHERITED,Mem1 #log4d.category.myapp.more=DEBUG,Mem2 #log4d.category.myapp.other=INFO,Mem3,#Email #log4d.category.alt=ERROR,Mem4,Fil1 # Myapp.other category doesn't log to its parents #log4d.additive.myapp.other=FALSE # Create root appender #log4d.appender.ODS=TLogODSAppender #log4d.appender.ODS.layout=TLogSimpleLayout # Create a file appender log4d.appender.Fil1=TFastLogFileAppender log4d.appender.Fil1.append=TRUE log4d.appender.Fil1.fileName=C:\SystemWeaver\Logs\swServerMonitorService.log log4d.appender.Fil1.errorHandler=TLogOnlyOnceErrorHandler log4d.appender.Fil1.layout=TLogPatternLayout log4d.appender.Fil1.layout.pattern=%d [%t] %-5p %-6c %x - %m%n log4d.appender.Fil1.layout.dateFormat=yyyy-mm-dd hh:mm:ss,zzz
Configuring the swDBServer Log
- Save the swServer.props file in the Server directory so that it is in the same location as the server application.
- Open the file in a text editor.
- Select which type of logging - INFO or DEBUG - to set for Log4d.rootCategory= and make one of them active.
- The INFO level designates informational messages that highlight the progress of the application at coarse-grained level. (default)
- The DEBUG Level designates fine-grained informational events that are most useful to debug an application. We recommend this level.
Note: When DEBUG level is used, be aware that the size of the file can become quite large.
- Set whether or not the log file should be cleared (=false) after restart of the server application or if logging should append on the log4d.appender.Fil1.append= line. The default of append is recommended.
- Define the file path and name of the log file on the log4d.appender.Fil1.fileName= line.

- Save your changes.
TcpSubServer Logging
Systemite.SystemWeaver.TcpSubServer.exe.nlog is needed and should be placed in the same directory as the server application files. SystemWeaver always provides an example Systemite.SystemWeaver.TcpSubServer.exe.nlog file in the Configuration files directory in an upgrade package which is compatible with that release. It is named Systemite.SystemWeaver.TcpSubServer.exe.nlog.example. Simply remove the .example suffix to use. Or, copy the following content into a text editor if you are running release Bö (R50) or later.
Systemite.SystemWeaver.TcpSubServer.exe.nlog
<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
throwExceptions="false">
<variable name="appName" value="YourAppName" />
<targets async="true">
<target xsi:type="File"
name="default"
layout="${longdate} [${threadid}] - ${level:uppercase=true} ${message}${onexception:${newline}EXCEPTION\: ${exception:format=ToString}}"
fileName="D:\SystemWeaver\Logs\TcpSubServer.log"
keepFileOpen="false"
/>
<target xsi:type="EventLog"
name="eventlog"
source="${appName}"
layout="${message}${newline}${exception:format=ToString}"/>
<!--target name="statisticsLogFileAsync"
xsi:type="AsyncWrapper"
overflowAction="Grow"
queueLimit="10000"
batchSize="100"
timeToSleepBetweenBatches="50">
<target xsi:type="File"
name="statisticsLogFile"
fileName="D:\SystemWeaver\Logs\Statistics.log">
<layout xsi:type="JsonLayout">
<attribute name="time" layout="${longdate}" />
<attribute name='seqId' layout='${event-properties:seqId}' />
<attribute name='sessionId' layout='${event-properties:sessionId}' />
<attribute name='ip' layout='${event-properties:ip}' />
<attribute name='userId' layout='${event-properties:userId}' />
<attribute name='username' layout='${event-properties:loggedInUsername}' />
<attribute name='email' layout='${event-properties:email}' />
<attribute name='clientName' layout='${event-properties:clientName}' />
<attribute name='event' encode='false'>
<layout type='JsonLayout' renderEmptyObject="false">
<attribute name='type' layout='${event-properties:event.eventType}' />
<attribute name='serverVersion' layout='${event-properties:event.serverVersion}' />
<attribute name='count' layout='${event-properties:event.count}' />
<attribute name='message' layout='${event-properties:event.message}' />
<attribute name='licenseId' layout='${event-properties:event.licenseId}' />
<attribute name='licenseCount' layout='${event-properties:event.licenseCount}' />
<attribute name='viewerLicenseCount' layout='${event-properties:event.viewerLicenseCount}' />
</layout>
</attribute>
<attribute name='call' encode='false'>
<layout type='JsonLayout' renderEmptyObject="false">
<attribute name='type' layout='${event-properties:call.callType}' />
<attribute name='id' layout='${event-properties:call.handle}' />
<attribute name='username' layout='${event-properties:call.username}' />
<attribute name='name' layout='${event-properties:call.name}' />
<attribute name='sid' layout='${event-properties:call.sid}' />
<attribute name='owner' layout='${event-properties:call.owner}' />
<attribute name='issueType' layout='${event-properties:call.issueType}' />
<attribute name='project' layout='${event-properties:call.project}' />
<attribute name='isActive' layout='${event-properties:call.isActive}' />
</layout>
</attribute>
<attribute name='action' encode='false'>
<layout type='JsonLayout' renderEmptyObject="false">
<attribute name='type' layout='${event-properties:action.actionType}' />
</layout>
</attribute>
</layout>
</target>
</target-->
</targets>
<rules>
<logger name="*" writeTo="default" minlevel="Info" />
<logger name="*" writeTo="eventlog" minlevel="Error" />
<!--logger name="StatisticsLogger" minlevel="Info" writeTo="statisticsLogFileAsync" /-->
</rules>
</nlog>Configuring the TcpSubServer Log
This log file contains client/application information for connects, disconnects, etc. We strongly recommend that this logging is turned on.
- Save the file as Systemite.SystemWeaver.TcpSubServer.exe.nlog.
- Open the file and update the fileName= line to indicate the TCPSubServer.log file name and the correct path to where you want the log to be placed. Naming it TCPSubServer.log will differentiate it from the swServer.log and ensure two separate log files should you have them generating in the same location.
- Save your changes.

Configuring the Statistics Log
The configuration file offers an optional, separate logging of certain user operations and usage statistics.
- To enable, remove the comment markers from the target named "statisticsLogFileAsync".

- Update the fileName= line in the target to indicate the desired file name and the correct path to where you want the log to be placed. The default filename is Statistics.Log, but you can change it to another that is unique in your target directory.

- Also, remove the comment markers from the rule for logger for "statisticsLogFileAsync" at the bottom of the file.

The output is JSON formatted and can easily be read, analyzed and visualized using an external tool.
Note: We recommend that you do not make changes to any of the settings in the top section of the target.
|
Starting the Logging
If the main server is running while you complete the configuration, it must be stopped and then restarted for the logging to begin successfully.
The swServer.log for the swDBServer will generate auto automatically once you start and/or restart the main server. This is also the case for the TcpSubServer.log. The Statistic log will generate upon the first login to the server.
For a brief explanation of the content of the log files, see Overview of Server Log Files.
Note: If a server application GUI (swTestServer) is open while you complete the configuration, it must be first closed and then reopened prior to the start/restart for the logging to begin successfully. |
Maintaining Log Files
If the decision is made to generate these log files, we recommend having a standard procedure in place to manage them, e.g., archive, delete, or move old files, monitor disk space, etc. The TcpSubServer files can become quite large especially if the server is not restarted in a very long time. If the size becomes an issue, you can move or delete a TcpSubServer file. However, if the file you wish to move or delete is the one currently being written to by the server, you must first stop the server before moving or deleting it. When you restart the server, a new file will generate. If there are multiple TcpSubServer files saved, you can always delete older versions at any time.
Splitting the TcpSubServer Logs
The TcpSubServer logs are built on NLog. There are many NLog config options (https://nlog-project.org/config/). Below is an example of dividing the TcpSubServer log file(s) into smaller volumes, i.e., a new log file each day, using shortdate.
Instead of:
fileName="D:/SystemWeaver/Logs/Statistics.log"
Use:
fileName="D:/SystemWeaver/Logs/Statistics_${shortdate}.log"
Sending a Copy to SystemWeaver Support
Th log files can be useful for troubleshooting purposes. If SystemWeaver requests files for troubleshooting purposes, make a copy of the file that includes the time period in question, compress it, and upload the copy to SystemiteNAS.
Maintaining Log Files
If the decision is made to generate log files, there should be a standard procedure in place to manage them, e.g., archive, delete, or move old files, monitor disk space, etc. If the file you want to move or delete the one currently being written to by the server, you must first stop the server before moving or deleting it. When you restart the server, a new file will generate.
