QPR ProcessAnalyzer Logs

From QPR ProcessAnalyzer Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

QPR ProcessAnalyzer writes a permanently stored log of all operations it's performing. The logs can be used for monitoring, auditing, troubleshooting and other purposes. The main types of logs are task log, script log and server file log. The task log (and visual reports based on it) can be used to monitor the system usage and collect statistics. The script log are collected for each script when the script runs. The server file log is not needed in every-day operations, but if there are exceptional situations, such as system malfunctioning, the server file log is helpful in investigating what has happened.

Task Log

All user created requests to the Web API are recorded as tasks, such as login, logout, modifying data, running queries etc. The Task Log can be browsed in the UI by opening the System Reports in the navigation menu (available only for system administrators). There are following task reports available:

  • Recent tasks: List of recent tasks in the order of start time.
  • Running tasks: All tasks currently being executed.
  • Tasks by time: Trend over time how task counts have changed.
  • Task duration: Distribution of task counts of different durations.
  • Most used models: List of models that are have been queried most.
  • Most active users: List of users who have used the system most actively.
  • User logins by time: Table of how many times users have logged in to the system over time.
  • Running tasks at specific time: This report can be checked afterwards what kind of activity was in progress the system at a specific time. It can be used to investigate for example experienced performance issues.

Currently running tasks can be stopped by the administrator both in the Recent tasks and Running tasks reports by selecting the task(s) and in the right click context menu selecting End tasks.

Note that loading of a model is visible as a separate task in the task log, besides to the task that initiated the model loading.

Task log have for example the following use cases:

  • To see the most active and idle times of the system to plan the optimal time for system updates and maintenance.
  • In case of performance issues, how much load the is in the system in different times.
  • How active the usage of the system is and how many users are using the system.
  • Which content and models are browsed by the users in the system.

Task Log Settings

The following settings are available for the task log (in the Analyze tab):

  • Time from: Show only tasks that have been started later than this time.
  • Time to: Show only tasks that have been started earlier than this time.
  • Only running tasks: Show only tasks that are currently running.
  • Only cancelled tasks: Show only tasks that have been requested to cancel.
  • Only model related tasks: Show only tasks that are related to a model.
  • Only user related tasks: Show only tasks that are related to a user.
  • Only logins: Show only login activities.
  • Only tasks longer than: Show only tasks where duration is longer is specified.
  • Maximum Text Length: Defines the maximum number of characters shown in the 'Additional Data' column.
  • Only logins: Show only log entries of successful authentications by users.
  • Maximum rows: Maximum number of rows shown by the log (default max. 1000).

The following columns can be selected for the task log (in the Columns tab):

  • Task type: Type of the task, e.g. run expression, run script, etc.
  • Start Time: Start time of the task.
  • End Time: End time of the task. This field is empty if the task is running.
  • Task duration: Duration of the task. Shown only if the task is completed.
  • Task cancelled: Whether the task was requested to be cancelled.
  • Task parameters: Input parameters of the task.
  • Task result: Exceptional results of the task, e.g., an error message.
  • Model name: Name of model for which the task was performed.
  • Model Id: Id of model for which the task was performed.
  • User name: Login name of the user performed the task.
  • User full name: Full name of the user performed the task.
  • User Id: Id of user performed the task.
  • Session Id: User session id that performed the task.
  • Task Id: Unique id of the task.

Script Log

The script log is collected for each run of a script. The script log contains possible errors in the script run and also log writes that are explicitly added to the code of the script. See more in Managing Scripts how to use the script log. Note that in the UI, you can only see the last completed script run, although the system is storing the entire run history.

Script logs contain following information:

  • All errors occurring during the script run (script run also stops when an error occurs).
  • All log writes made by commands in the script code (in expression scripts WriteLog function calls, and in SQL scripts --#WriteLog and PRINT commands).
  • For SQL scripts, all executed scripting commands (commands starting with --#).

Server File Log

The server file log contains information about all operations performed by the QPR ProcessAnalyzer server in a detailed level. The server file log is stored in the location defined by the LogFilePath setting in the appsettings.json file. The Web.config file also contains several other settings that affect the logging behavior, e.g. maximum log file size and file rotation.

All log entries are classified to the following logging levels based on their importance for the system administrator:

  • FATAL: (currently not in use) For failures that are likely application wide, and the entire application may have stopped working. Thus it requires immediate attention from the system administrator.
  • ERROR: For failures that cause handling of the current request to fail, but the failure is not application wide, and the application should continue responding to other requests. System administrator should soon investigate the reason for these log entries. If the failed requests serve important functionality in the system, these failures might be critical to users.
  • WARN: Abnormal or unexpected event has occurred in the application, but handling of the current request did not fail. No immediate resolution is required, but the system administrator should investigate the reason for these log entries when suitable.
  • INFO: Tracks the successful progress of the request handling or other flow in the application. Normally these log entries can be ignored by the system administrator, unless an unknown failure has occurred and more detailed information is needed.
  • DEBUG: These are technical details for application developers, so these log entries don't have any use for system administrators.

The following log entries for security auditing purposes are made to the server file log (using Information log level):

  • When specifying a non-existing username, the following log entry is made: User is not found: <username>
  • When specifying wrong password for an existing user account, the following log entry is made: User password is invalid: <username>
  • When trying to log in with an inactivated user account, the following log entry is made: User account is invalid: <username>