Updated: October 16, 2020 3:27pm

Log Files

Prism maintains various log files that can assist with monitoring and troubleshooting. Log files tend to be found in various locations; therefore the Prism Tech Toolkit includes a Log Viewer tool that makes it easy to navigate and view log files.
The following table lists the primary log files found in Prism:

Log File Location Description
License Server …\ProgramData\RetailPro\Server\Logs Log files related to the Prism License Server.
Prism BackOffice …\ProgramData\RetailPro\Server\Logs Log files related to the Prism Backoffice service (primarily used for Store Operations tasks).
Prism Common …\ProgramData\RetailPro\Server\Logs Log files for the Prism Common service, which facilitates tasks common to multiple areas.
Prism DRS …\ProgramData\RetailPro\Server\Logs Log files related to Prism DRS, used during data replication.
PrismMQ Producer …\ProgramData\RetailPro\Server\Logs Log files related to PrismMQ Producer messaging service (used during replication).
PrismMQ …\ProgramData\RetailPro\Server\Logs Log files related to PrismMQ messaging service (used during replication).
PrismPOSV1 …\ProgramData\RetailPro\Server\Logs  Log files related to the Prism POSV1 services (primarily used for POS tasks).
Prism Resiliency …\ProgramData\RetailPro\Server\Logs Log files related to the Prism Resiliency Server.
Prism Scheduling …\ProgramData\RetailPro\Server\Logs Log files related to the Prism Scheduling service.
Prism Web Module …\ProgramData\RetailPro\Server\Logs Log files related to the Prism Web Module.
OPOSCsdDraw …\ProgramData\RetailPro\HardwareServices\Logs Log files related to OPOS cash drawers.
OPOSLineDsp …\ProgramData\RetailPro\HardwareServices\Logs Log files related to OPOS line displays.
PIAPI …\ProgramData\RetailPro\HardwareServices\Logs Log files related to physical inventory.
PrismProxy …\ProgramData\RetailPro\HardwareServices\Logs Logs activity when a user starts a session in the Prism Proxy.
TechToolkit …\ProgramData\RetailPro\TechToolkit\Logs Logs activity when a user starts a session in the Prism Tech Toolkit.
Installer programs C:\Users\sysadmin\Documents.

A separate log file is created for each Prism component installed.
The default location for the log files is C:\Users\sysadmin\Documents and it can be modified at run time within the Autorun.exe modal.

  • Win32PrismServerInstaller.exe_[timestamp]_PrismLogs.log
  • Win32PrismProxyInstaller.exe_[timestamp]_PrismLogs.log
  • Win32PrismDRS.exe_Scripts_[timestamp]_PrismLogs.log
  • RILOraInstaller.exe_[timestamp]_PrismLogs.log
  • RILMgmtInstaller.exe_[timestamp]_PrismLogs.log

Global Logging Settings (PrismLogging.ini)
A single configuration file, prismlogging.ini, has configuration settings that enable you to customize and fine-tune the logging process. This file is created in C:\ProgramData\RetailPro\Server\conf during Prism installation, version 1.14.7 or later. Any existing LOG sections in a services' config INI's are ignored. The installer does not remove these deprecated LOG settings but they will be removed when the INI files are updated after installation.
PrismLogging.ini has a [global] section containing all log keys. These are used by all services and apps using the Logger unless a different setting has been entered in the file for the service.
The section name for an app or service in the PrismLogging.ini is the base file name of the binary that is using the Logger. So, if a log setting in the service's section differs from the global setting, the service will use the specific setting entered for the service.
When first installed, PrismLogging.ini will have only a [global] section with default log settings. The global values can be edited, or specific service settings can be added & edited, manually or by using Web TTK. PrismLogging.ini has a [global] section containing all log keys. These are used by all services and apps using the Logger unless a different setting has been entered in the file for the service. When first installed, PrismLogging.ini will have only the [global] section with default log settings. Beneath the global section are sections for each individual service. You can configure settings for individual services that will override the global settings. This file is created in …\ProgramData\RetailPro\Server\Conf.
If a user changes the PrismLogging.ini or a service .ini file, the changes are loaded dynamically. There is no need to restart the service. This applies to all Prism services. Note: The PrismLicenseService and PrismResiliencyService only dynamically re-load log settings, not other settings.

Field Description
LOGLEVEL

None = 0    No log entries will be written to the log. The log file will not exist
Minimal = 1    Logs only Error
Normal = 2    Logs Error, Warn
Verbose = 3    Logs Error, Warn, Info, Flow, Entry, Exit
Debug =4    Logs Error, Warn, Info, Flow, Entry, Exit, Debug
Default = 2

RETAINXLOGS

Retain a service's log files for number of logs counting from the current log.
When the service is started and once per day thereafter, a cleanup task runs and removes log files as needed, based on the RetainXLogs setting.
A new log file is created when the current file reaches its Max Entry Length (Default = 100,000 lines or approximately 25MB).
RetainXLogs is set to "9" by default. By default, to make way for the tenth log, the cleanup task will clear the first log.
The cleanup task clears logs in the following folders:
ProgramData\RetailPro\Server\Logs folder
ProgramData\RetailPro\Tech Toolkit\Logs
ProgramData\
Examples:
RetainXLogs=0: All the service's logs will be cleared when the cleanup task is run.
RetainXLogs=1: The current log files are kept.
RetainXLogs=7: The last 7 logs are kept.
RetainXLogs can be viewed and edited either manually in a service's config / INI file or in TechToolKit's ServiceManager.
If a service is running when a change is made, the change will take effect when the service is restarted.

BUFFERSIZE

The number of log lines to hold in memory before flushing the buffer.
0 or 1 - write each line to the log immediately
N (N>1) - retain N log lines in memory, write them either when more than N lines are accumulated or after 10 seconds has passed since last write to disk, whichever happens first.
Default = 100

LOGPAYLOADS Default = True
FORCELOGINFO ForceLogInfo, when true, means log calls with Info Log Entry Type will be logged regardless of the log level.
Default = False
DEBUGSTACKTRACEACTIVE False - When exception is detected only write the error message
True - When exception is detected write the error message and a stack trace
Default = False
MAXLINESPERLOG The MaxLinesPerLog number rotates the service's log files when it reaches above number of lines. MaxLinesPerLog applies only if log file is segmented, which is the default. "Segmented" means a new log file gets created if MaxLinesPerLog has been reached or the date changes. Otherwise same log file is written to.
Default = 100000 lines.
MAXENTRYLENGTH Number of lines after which the current log file will be closed and new file will be created for continued logging. Note: It is not recommended to set max lines per log to less than 100 or 1000 lines - doing so will cause log files to rotate too quickly.
Default = 100000 lines.
LOGFILEDIR The LogFileDir enables the logger to write to an alternate log folder. Normally the LOGFILEDIR key should be blank which means the default server\logs folder will be used.  The intent is that this should only be updated by TTK webclient. However manual edit is possible and will work.
Logging to the new folder will take effect when the service or app is restarted.
If the alternate logs folder does not exist when entered, the Tech Toolkit API will create it. The Tech Toolkit API validates the LOGFILEDIR can be written to and raises an exception to the webclient's PUT request if the folder is not writable. The path must be the full path with no references to environment variables. If the api can't create the directory or can't write to it or if the path is otherwise invalid, the default Prism Logs folder will be used.
Setting this key in a service's section is ignored.

Limiting Log File Size
You can limit the size of log files so that they don't grow to the point where they affect performance by editing the MaxLinesPerLog (Max Entry Length) setting. By default, the MaxLinesPerLog is 100,000.

Updating PrismLogging.ini with Prism Web TechtoolKit
Updates to the settings for a service are made in ServiceManager. The LOG settings are displayed grouped with the service's other INI settings, even though the LOG settings are maintained not in the service's INI but in a separate PrismLogging.ini. This grouping provides consistency with past UI displays and for ease of use - rather than separating LOG settings in a separate web form.
When a change is made to a service's log setting, if that change is different than the existing global setting, Web TTK will create a section for the service in PrismLogging.ini if it does not exist, and write the Key / Value pair to the section.
If the change being made is the same as the existing global setting, the Key / Value pair in the service's section will be removed since the global value will automatically apply without a setting for the service. This is to prevent duplicative clutter in PrimsLogging.ini which would result in a full set of logging keys for numerous services and apps. Not only would this be unnecessary, it makes it difficult to examine the file to analyze or debug possible logging issues, as well requiring more time for services to load and read settings.
As such, in general, PrismLogging.ini will only contain the global settings and services' exceptions to them when using Web TTK for updates. There are some instances where there could be some duplication of a service setting with the global value.

Updates to Global Log Settings
Global settings can be viewed and edited in ServiceManager in the "Prism Stack" section.
Changes to global settings only update the global settings and do not overwrite an existing setting for any service.  At this time there is no feature to set all services to the same log setting using a 'global update' process. The global setting will apply to any service or app that does not have the same setting specified in its section.
Changing a global setting to the same value as may be specified for a service will not remove the service's Key / Value pair as would a similar update to the service's setting.

Example PrismLogging.ini with Comments
[Global]

LOGLEVEL=2
RetainXLogs=9
ForceLogInfo, when true, means log calls with ltInfo LogEntryType will be logged regardless of the log level.
FORCELOGINFO=false

DebugStackTraceActive=False

BufferSize refers to how many log lines to hold in memory before "flushing" to disk.
BUFFERSIZE=100

100000 here equates to 100k size limit for the 'message'. Anything beyond 100k slows the logger exponentially. But message 100k or less, minimal impact.
MAXENTRYLENGTH=100000

 MaxLinesPerLog applies only if log file is segmented, which is the default. "Segmented" means a new log file gets created if MaxLinesPerLog has been reached or the date changes. Otherwise same log file is written to.
MAXLINESPERLOG=100000

Default is True. Any service that consumes HTTP requests will log request and response payloads when this setting is true. Requires llVerbose or llDebug loglevel.
  rem As implemented, the addition of this setting only affects PrismCommon, PrismBackOffice, PrismTechToolKit, PrismScheduling and DRS.  POSV1Service already
implements logging of payloads which cannot be turned off. This can be turned off when/if not needed for individual services. For some services such as PrismScheduling and PrismTechToolKit logging payloads has less value than PrismBackoffice or Common.
LOGPAYLOADS=True

LogTiming, when true will record CPU time with every log write. Requires llVerbose log level
LOGTIMING=false

LOGFILEDIR=
The LogFileDir provides the ability to have the logger write to an alternate log folder.
 Normally the LOGFILEDIR key should be blank which means the default server\logs folder will be used. The intent is that this should only be updated by TTK webclient. However manual edit is possible and will work. Logging to the new folder will take effect when the service or app is restarted.
 If the alternate logs folder does not exist when entered, the api will create it. The TTK api validates it can be written to and raises exception to the webclient's PUT request if not writable. Other causes for rejection: root directories and the RetailPro AppDatata folder which contains the conf, logs, webclient folders. At this time, the alternate path must be the full path with no references to Environment variables. If the change is made in the INI manually, if the api can't create or can't write or is otherwise invalid, the default Prism Logs folder will be used. Setting this key in a service's section is ignored.
LOGFILEDIR=

Service-specific settings
A service or app can override a global setting by creating its own section in this file. This section or a setting in the section can be made at any time and the service will load it even when running. The section name must be the base name of the executable, case-insensitive, not the app's base INI filename. A change to a service's log setting in webclient that is different than the global setting will automatically create a section for the service if it does not exist and will add the key/value pair. If the change is the same as the global setting, the service's current key will be removed if it exists.

[PrismMQ]
FORCELOGINFO=True
RetainXLogs=12

[PrismCommon]
LOGLEVEL=3
RetainXLogs=15

[PrismScheduling]
LOGPAYLOADS=False

Log Files for Installer Programs
A separate log file is created for each Prism component installed.
The default location for the log files is C:\Users\sysadmin\Documents.

  • Win32PrismServerInstaller.exe_[timestamp]_PrismLogs.log
  • Win32PrismProxyInstaller.exe_[timestamp]_PrismLogs.log
  • Win32PrismDRS.exe_Scripts_[timestamp]_PrismLogs.log
  • RILOraInstaller.exe_[timestamp]_PrismLogs.log
  • RILMgmtInstaller.exe_[timestamp]_PrismLogs.log

Viewing Log Files
The easiest way to view log files is using the Prism Technician's Toolkit. To launch the toolkit point your web browser to hostname/TTK and log in.
Click the Logs tab on the top menu. If prompted to log in, enter your credentials again.
Alternatively, you can navigate to the location of the desired log file and view the file using a text editor like Notepad++.

Log Entry Types

Type Description
Error Used to log errors and error related information. Developers should be using Error in TRY>EXCEPT blocks.
Warn Used to log warnings or irregular flow control
Info Used to log information NOT related to other entry types.
Developers should use this to log additional information. This should be used the least of all logging methods.
Flow Used to log flow control markers in the code execution. Developers should use this to track the flow of code execution through blocks of code that are NOT the normal path. This should not be used to track every If/Case/Repeat/Do operation. Care should be used inside of high performance loops to not bog down the execution. Instead log before and after and use Debug for the inside of the loop.
Entry Used to track the entry point in a method. Developers should use this as the first line in each method
Exit Used to track the exit point of a method
Debug Used to log developer debug information.
Developers can add these to provide additional debug information at runtime. These should be removed once a problem has been debugged

Log Levels
The following logging levels are supported.

Log Level Description
0 None. No log entries will be written to the log. The log file will not exist
1 Minimal. Logs only events at the Error level.
2 Normal. Logs events at the Error and Warning levels.
3 Verbose. Logs events at the Error, Warning, Info, Flow, Entry and Exit levels.
4 Debug. Logs events at the Error, Warning, Info, Flow, Entry, Exit and Debug levels.

Tracking Requests in Retail Pro Prism Log Files
To locate and track requests in the Prism log files can be a little difficult if the log level is set to "3" (most verbose) and there are overlapping requests.
To find the information you are looking for in an efficient manner, use the following two tips:

  • Use the Auth-Session ID to identify requests related to the same security session
  • Gather the log lines for a request so that you can see all the log entries from the beginning of the request to the end.

1. Identify requests related to the same security session (requests from the same workstation and the same logged-in user). To follow the stream of requests for the same session, search for the session token. It is logged as a long string of characters and digits in the Auth-Session line. Examples:

POSV1:
2020.11.13.01.00.44.339 [3728] Information ------
Auth-Session: 204AC3855B7D498FB7933187BCA992C1
BackOffice:
2020.11.13.04.00.55.249 [5412] Information ------
Auth-Session: 204AC3855B7D498FB7933187BCA992C1
Common:
2020.11.13.01.00.44.323 [1196] Information ------
Auth-Session: 204AC3855B7D498FB7933187BCA992C1

2. Gather log lines for one request from beginning to end. This is very important for multiple requests logging in parallel. In this case you need to find the beginning of the request and use the thread ID to track the log lines generated by that specific consumer while it was processing that specific request. The Thread ID is the number denoted inside square brackets. In this example, the thread ID is 6004

2020.11.08.16.00.12.767 [6004] >> Entry >>
TPOSV1RequestMessageConsumer.ProcessMessage
2020.11.08.16.00.12.767 [6004] Information
********************Message Received********************
2020.11.08.16.00.12.767 [6004] Information ------
Namespace: PrismPOSV1
2020.11.08.16.00.12.767 [6004] Information ------
Host: akvms-v7-1.retailpro.com
2020.11.08.16.00.12.768 [6004] Information ------
URL: /v1/rest/document/542457610000194794?cols=tenders,tender.tender_type,sid,...
2020.11.08.16.00.12.768 [6004] Information ------
ContentType: text/json
2020.11.08.16.00.12.768 [6004] Information ------
Accept: application/json, text/plain, version=2
2020.11.08.16.00.12.768 [6004] Information ------
Method: GET
2020.11.08.16.00.12.768 [6004] Information ------
CorrelationID: {FE3455B7-7848-4C2A-94D9-8F7879653975}
2020.11.08.16.00.12.768 [6004] Information ------
Auth-Session: 36E790446F314B9BB7F9BC0CE47FE5D6
2020.11.08.16.00.12.768 [6004] Information
********************************************************
2020.11.08.16.00.12.769 [6004] >> Entry >>
DISPATCHREST ...
2020.11.08.16.00.13.015 [6004] << Exit << DISPATCHREST
2020.11.08.16.00.13.015 [6004] >> Entry >>
TPrismMessaging.SendReplyMessage
2020.11.08.16.00.13.015 [6004] << Exit <<
TPrismMessaging.SendReplyMessage
2020.11.08.16.00.13.016 [6004] Information Response Message Sent For CorrelationID: {FE3455B7-7848-4C2A-94D9-8F7879653975}
2020.11.08.16.00.13.016 [6004] << Exit <<
TPOSV1RequestMessageConsumer.ProcessMessage
To find out what requests were sent prior to or after the one you are currently examining, search for the session token backward or forward in the log file. You should be able to see those log lines on log levels 2 and 3.
If requests from the SAME session are made to different modules (POSV1, BackOffice, Common) they will show the same Auth-Session value, so you can track whether that session was talking to multiple services.
Note: Do not pay attention to the CorrelationID. CorrelationID is used for tracking interactions between Apache and our services, and is useful only for developers and only in very special circumstances

Locate Request Entry and Exit
The next step is to find where that requests starts and ends. Look for the very first ">> Entry >>" line where it says xxxxxxMessageConsumer.ProcessMessage.
There will be a single blank space on each side of the "Entry" keyword. That is the beginning of the message handler.
Replace ">> Entry >>" with "<< Exit  <<"
There will be a single blank space to the left and TWO blank spaces to the right of the "Exit" keyword.
Keep the rest of the line as is, with FOUR blank spaces after the thread ID, like this:
[6004] << Exit  << TPOSV1RequestMessageConsumer.ProcessMessage
Keep the very same thread ID. If you search FORWARD for that line, it will be the VERY LAST log line for that specific message.
Note: It might end up being in the next log file, so if you did not find it, search in the next file. Or, if you are looking at the last request in the log file it might still be buffered in memory. Wait until the buffer is saved.
Since consumer threads do not change the thread ID while processing requests, each line between the Entry and Exit lines that has the same thread ID belongs to the same consumer thread working on the same request. If you see another line in between with a DIFFERENT thread ID, ignore it. It is coming from a different request.
Note: Each consumer has its own thread ID but there is no correlation between the SESSION and THREAD ID. Any consumer can process any request if it is available.
There is no rule stating that if you process a GET request for a document in thread XYZ, the same thread will process the next request for the same session. THREAD IDs are only important WITHIN the same request.
For tracking multiple requests use Auth-Session instead.

RabbitMQ Log Files
Prism uses RabbitMQ messaging service for data replication. RabbitMQ logs can provide valuable information for troubleshooting, especially issues related to replication.
RabbitMQ Log Management Best Practice for Prism
Change your RabbitMQ log level. Changing the log level will save hard drive space, reduce administration tasks and make it easier to search logs for errors. These log level settings are recommended by the Retail Pro Professional Services Team. You can find additional information about configuring RabbitMQ logs on the RabbitMQ website and on GitHub. The default log level in RabbitMQ is Info which is one severity below debug. When logging is set to the Info level, log entries will be recorded for events in the Info level and below, which includes Info, Warning, Error and Critical. This means that by default, only debug-level events are excluded from the logs. This is quite a lot of detail to include in the logs and is typically not necessary in a production environment. Instead, change the RabbitMQ log level to Error at each installation.
To edit the RabbitMQ log level:
Navigate to the C:\ProgramData\RetailPro\Server\RabbitMQ directory. Edit the file and change the contents to reflect the text in the log file below.
[{lager, [
                {handlers, [
                {lager_file_backend, [(file, "error.log"),
                {level, error},
                {date, "$00"},
                {size, 10485760},
                {count, 10}]}
]}]}]
 Refer to the following table for an explanation of the configuration file contents:

Line entry in rabbitmq.config Description
{file, "error.log"}, {level, error} Tells lager to log errors and above messages to error.log
{size, 10485760}, {date, "$00"} Tells lager to rotate the file at midnight or when it reaches 10mb, whichever comes first
{count, 10} Tells lager to keep 10 rotated logs in addition to the current one. Setting the count to zero does not disable rotation. Instead, it rotates the file and keeps no previous versions.
{size, 0}, {date, " "} To disable rotation, set size to zero and the date to " "

"$D0" (D-zero) Syntax
The $D0 syntax is taken from the syntax newsyslog uses in newsyslog.conf. The relevant extract follows.
Day, week, month and time format
The lead-in character for day, week and month specification is a '$' sign. The format of the day, week and month specification is: [Dhh], [Ww[Dhh]] and [Mdd[Dhh]], respectively. Hour specification is added on top of this, displayed as [Hmm]. Optional time fields default to midnight.

Range Specification
w Day of week    Range 0 ... 6, 0 = Sunday
dd Day of month    Range: 1 ... 31, or the letter L or l to specify the last day of the month
hh Hours    Range: 0 ... 23
mm Minutes    Range: 0 ... 59

Examples

"$D0" Characters Meaning
$D0 Rotate every night at midnight
$D23 Rotate every day at 23:00 hr
$W0D23 Rotate every week on Sunday at 23:00 hr
$W5D16 Rotate every week on Friday at 16:00 hr
$M1D0 Rotate on the first day of every month at midnight (i.e., the start of the day)
$M5D6 Rotate on every 5th day of the month at 6:00 hr
$H00 Rotate every hour at HH:00
$D12H30 Rotate every day at 12:30
$W0D0H0 Rotate every week on Sunday at 00:00