Updated: November 12, 2020 8:48am

Log Files

PDF

Prism includes several log files that can assist with monitoring and troubleshooting.
This topic has information about:

  • Viewing log files
  • List of Prism log files
  • PrismLogging.ini configuration file
  • Changing global log settings
  • Changing log settings for a service
  • Log levels
  • Log entry types
  • Using alternate log directory
  • Using the logfile API to make requests that filter logs by log file type, log entry type, date range, and files with errors.


View Logs
The Prism Tech Toolkit includes a Logs tool that makes it easy to view log files.
Log in to the Tech Toolkit and click the Logs tab on the top menu.  A separate log-in is required for viewing logs. The default username/password is "loguser/loguser".
After successful login a list of recent logs is displayed.
Scroll the list to locate the desired log and then click on the hyperlink to display the log.
Log File List


Log Folder Authorization - Creating Users and Passwords
When opening the Web TTK Log Files tool, the user is prompted to enter valid credentials created using the Apache password tool. New users and passwords are created or updated using the Apache password tool, htpasswd. See the following link for more information:
https://httpd.apache.org/docs/2.4/programs/htpasswd.html

Note: You can copy the contents of the log to a text editor like Notepad++ if you want to search text within the log.
After viewing a log, click the blue arrow button to return to the log list.
 
Prism Log File List
The following table lists Prism log files and the location to which the files are saved:

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\Server\Logs Logs activity in the Desktop 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

PrismLogging.ini
Configuration settings for log files are stored in the PrismLogging.ini file. The PrismLogging.ini file is in the …\ProgramData\RetailPro\Server\Conf folder. PrismLogging.ini has a [global] section and can have sections for each Prism service. The settings defined in the [global] section apply to all services.
You can change log configuration settings for individual Prism services in the Services area of the toolkit. If a changed setting for a service differs from the existing global setting, a section is added to the PrismLogging.ini file for the service with the setting's key-value pair.
Example of service-specific setting in PrismLogging.ini:
[PrismMQ]
FORCELOGINFO=true
RetainXLogs=12
[PrismCommon]
LOGLEVEL=3
RetainXLogs=15

The following table lists the available settings for PrismLogging.ini and the default settings:

Property Default Notes
Log Level
LOGLEVEL
2 How much logging to produce:
0 - None, 1 - Minimal, 2 - Normal, 3 - Verbose, 4 - Debug
Max Entry Length
MAXENTRYLENGTH
100000 Pertains to the size in bytes of the message being logged. A message greater than 100 Kb slows Prism performance dramatically but has little impact below that number. Large-size log messages are typically the HTTP response payloads. (See below)  Default = 100000. Maximum = 100000
Log Timing
LOGTIMING
False Outputs CPU clock ticks with each log entry; debug level only.
RetainXLogs
RETAINXLOGS
9 The RetainXLogs setting retains 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.
RetainXLogs is set to "9" by default. for the new (what would be the tenth) log, the cleanup task clears the oldest log.
If RetainXLogs is set to zero, all the service's logs will be cleared when the cleanup task is run.
If RetainXLogs is set to "1", only the current log file is kept.
If RetainXLogs is set to "7", the last 7 logs are kept.
Buffer Size
BUFFERSIZE
100 The number of log lines to hold in memory before flushing the buffer (i.e., writing the lines to log).
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.
A lower number will affect performance because of frequent writes; a higher number will result in less-frequent writes. The upper limit for the BufferSize is the MaxEntryLength.
Force Log of Info
FORCELOGINFO
False True =  Log calls with Info Log Entry Type will be logged regardless of the log level.
Log CPU Timing
LOGTIMING
False Output timings for parts of the system in the log file; use for debugging purposes only
Log Payloads
LOG PAYLOADS
True 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.
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.
Log Exception Stack Trace
DEBUGSTACKTRACE
False False = When exception is detected write the call stack trace in addition to the error message.
True = When exception is detected write the error message and a stack trace
Max Lines Per Log
MAXLINESPERLOG
100000 Number of lines after which the current log file will be closed and new file will be created for continued logging.
Log File Directory
LOGFILEDIR
empty 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 the TTK web client. 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 web client'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.


Sample PrismLogging.ini with Comments
[Global]
LOGLEVEL=2
RetainXLogs=9
FORCELOGINFO=false
ForceLogInfo, when true, means log calls with ltInfo LogEntryType will be logged regardless of the log level.
DebugStackTraceActive=False
BUFFERSIZE=100
BufferSize refers to how many log lines to hold in memory before "flushing" to disk.
MAXENTRYLENGTH=100000
100000 here equates to 100k size limit for the 'message'. Anything beyond 100k slows the logger exponentially. But message 100k or less, minimal impact.
MAXLINESPERLOG=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.
LOGPAYLOADS=TRUE
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.
LOGTIMING=false
LogTiming, when true will record CPU time with every log write. Requires llVerbose log level
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.

Edit Global Log Settings
You can change the default global log settings. Do not edit the PrismLogging.ini file directly. Instead, use the Prism Stack element in the Services area to make changes.
In Tech Toolkit, click the Services tab on the top menu.
At the bottom of the list is an element labeled "Prism Stack."
Click the down arrow button. The UI now has a set of buttons on the bottom of the screen.
Click the Settings button.
Settings icon

Global log settings are displayed. Make changes to the available fields and then click the blue check mark icon to save the changes.
Sample Prism Stack global log settings:
Prism stack logs section

Edit a Service's Log Settings
The settings in the [Global] section of the PrismLogging.ini file apply to all services by default. You can change log settings for individual Prism services in the Services area of the toolkit. For example, you can change the log level of a service on a temporary basis to capture more information.
In Tech Toolkit > Services, locate the desired service and click the down arrow.
 Click the Settings icon and navigate to the Logs area.  Make any needed changes to the log settings and then click the blue check mark button.
Service log settings

When you save the changes, the PrismLogging.ini file is automatically updated. A new section is added to the PrismLogging.ini file for the service with the key-value pair.
PrismLogging ini file updated

Log Level
The Log Level determines the level of detail captured by logs. Log levels range from 1 to 4, with 1 being the least amount of detail and 4 being the most detail. To change the logging level, edit the Prism Stack element in the Services area of Tech Toolkit.

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.


Log Entry Type
The following table lists the available log entry types and usage notes.

Log Entry Type Notes
ltError Used to log errors and error related information. Developers should be using ltError in "try/except" blocks.
ltWarn Used to log warnings or irregular flow control.
ltInfo Information. Used to log information not related to other entry types. Developers should use this to log additional information. This entry type should be used the least. The "Force Log Info" flag, when selected, will
ltFlow 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. Use carefully with If/Case/Repeat/Do operations to avoid bogging down code execution. Instead log before and after and use ltDebug inside the loop.
ltEntry Entry Point. Used to track the entry point in a method. Developers should use this as the first line in each method.
ltExit Exit Point. Used to track the exit point of a method
Developers should wrap the method in a "Try" block and this should be in the final section.
ltDebug Debug. Used to provide additional debug information at runtime. Remove this log entry type once a problem has been debugged.


Alternate Logs Folder
By default, logs for Prism services are written to C:\ProgramData\RetailPro\Server\Logs. You can change the folder, if necessary. The default login credentials (loginuser/loginuser) will still work if you change the logs folder.
To change the folder to which log files are written:
Launch Prism Tech Toolkit.
Click the Services tab.
At the bottom of the list is an element labeled "Prism Stack." Click the down arrow button and then click the Settings icon.
Enter the path to the folder where log files should be saved.
Click the blue check mark button to save the changes.
Restart Apache.
Sample Prism Stack element with Alternate Logs folder defined:
Alternate log folder

Apply Log Folder Change during Maintenance Window
If you specify an Alternate Log Folder, do it during non-business hours. Restart all Prism services or reboot the machine after executing the change. The other Prism services will only recognize the log folder change when they are restarted. The log folder change affects Prism services' logging, including the Web Client, but not RabbitMQ or the DB services. So the latter do not need to be restarted.

API
This section has information about:
Logfile virtual resource
Using Prism API Explorer to make API requests
Notes about API updates of PrismLogging.ini
Filtering log files by date range, log entry type, files with errors, as well as applying multiple filters and opening a specific log file
logfile virtual resource
API calls related to logging use the logfile virtual resource.
Example:
http:///api/techtoolkit/logfile
Returns a listing of all Prism-related log files. Sample info is shown below.
"logfilename" : "PrismPOSV1AsService_190905_120515615.log",
"logfiletype" : "PrismPOSV1",
"logfiledate" : "2019-09-05T17:41:05.582-07:00",
"logfilesize" : "20744",
"errorcount" : "0",
"logfilepath" : "C:\\ProgramData\\RetailPro\\Server\\Logs\\PrismPOSV1AsService_190905_120515615.log",
"logfileendpoint" : null

The logfile virtual resource has the following properties:
property LogFileName: Nullable read FLogFileName write FLogFileName;
property LogFileType: Nullable read FLogFileType write FLogFileType;
property LogFileDate: Nullable read FLogFileDate write FLogFileDate;
property LogFileSize: Nullable read FLogFileSize write FLogFileSize;
property ErrorCount: Nullable read FErrorCount write FErrorCount;
property LogFilePath: Nullable read FLogFilePath write FLogFilePath;
property LogFileEndpoint: Nullable read FLogFileEndpoint write FLogFileEndpoint;
The names can be changed. For example, a developer might prefer to remove the "Log" prefix as redundant.

Using Prism API Explorer to make API requests
You can use Prism's built-in API Explorer (or a tool like Postman) to make API calls that access the logfile virtual resource.
To access Prism API Explorer, launch Prism and append "/api-explorer" to the Prism hostname in the browser address bar. Log in if prompted.
Example: http://myhost.mydomain.com/api-explorer
On the left, under the heading "Services" is a set of folders that provide API access to different Prism services and resources.
Click techtoolkit > REST Resources > logfile.
API Explorer folders
Click the Raw Requests tab.
In the Raw Requests area, the UI has a set of drop-downs that make it easy to construct API requests. Select the desired REST request type (e.g. GET), area and resource.
In the Payload section, you can enter parameters for filtering log files by date range, log entry type, etc. (see the "Setting Filters" section).
Click Send Request.
Sample Prism API Explorer Raw Request area:
API Explorer request
The response is returned as an array of matching objects. Click the arrow icons to expand/collapse the object contents.
Sample Prism API Explorer Response Details:
API Explorer Request Details
Considerations when making API updates of PrismLogging.ini

  • Review the settings in the PrismLogging.ini file before AND after making changes to the log settings from the API.
  • If a log setting change that is requested for a service is different from the exiting [global] key value for the setting, the setting is placed in a section for that service (identified by the base name of the binary). If the section or key does not exist it is created.
  • If a log setting change is the same as the [global] value and the service has an existing setting in its section PrismLogging.ini, the key is removed since the global value can now be used by the Logger.

Setting Filters
This section has a few examples showing how log files can be filtered.
Filter by Log File Type
Filtering by logfiletype will return a payload with only the specified log file type:
http:///api/techtoolkit/logfile?filter=logfiletype,eq,prismcommon
Use these values when setting filters by logfiletype: PrismBackOffice, PrismCommon, RPSRestServiceModule, LicenseServer, PrismMQService, PrismScheduling, TechToolKit, PrismV9, EFTServiceModule, PrismResiliencyServer, PrismPOSV1, PrismWebModule, PubSubService, V9DRSPubSub, PrismProxy, HardwareServices, JTEInstaller
Sample API Request filtered by logfiletype:
 
Filter by date
Filter by logfiledate to include log files with a date greater than or equal to the specified date. The api uses the date value, starting at midnight for that date. Therefore passing only a date value in the yyyy-mm-dd format will also work.
http:///api/techtoolkit/logfile?filter=logfiledate,ge,2020-09-01T07:00:01.886Z
Files with Errors
Filter by errorcount to return a list containing only log files that have errors:
http:///api/techtoolkit/logfile?filter=(errorcount,ge,1)

Apply Multiple Filters
Use parentheses and the AND/OR operators to apply multiple filter elements.
http:///api/techtoolkit/logfile?filter=(logfiletype,eq,PrismPOSV1)AND(errorcount,ge,1)AND(logfiledate,ge,2020-02-01T17:41:05.582-07:00)
Open a specific log file
http:///techtoolkit/logfile?filter=(logfilename,eq,PrismTechToolKitAsService_190916_154037697.log)
The api will copy the requested file to a new folder and return a payload with the http link where the user can download the file or open it in their editor of choice.
Information for Developers
This section has information for developers about the simplified log method call syntax introduced in 1.14.7 and the StartLogSession() method.
Log Method Call Syntax
In 1.14.7, the log method call syntax no longer requires a log level.
Logger.Log( ‘The message', TlogEntryType);
Example: Logger.Log(‘Some information', ltInfo);
StartLogSession()
procedure StartLogSession(const AAppLogFileName: string; ALogIsSegmented: boolean = true; AAppLogDir: string = '');

Parameter Description
AAppLogFileName  (Required) This is typically the base name of the binary although some services and apps have chosen to use a slightly different name for the log file.
ALogIsSegmented ALogIsSegmented should be true unless for some reason the intent is to use only one file for logging with no rollover based on size or date change.
AAppLogDir AAppLogDir should only be used when the app does not have access to the server\logs folder or there is a special need. Two examples. For example, Prism installers logging the DB scripts need to write to the \Documents folder because in a fresh install the RP RetailPro\Server\Logs folder does not exist.

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.