0

Logging Events in LogicNets [DRAFT]

  • updated 2 wk ago

Introduction to Logging

Logging for security, auditability, troubleshooting, etc. is very important in any system and this article summarizes the logging associated with LogicNets solution. Below are outlined the different logging mechanisms in place starting with those events closest to the business process/solution and ending with notes about infrastructure logging. Note that infrastructure logging is relevant for hosted installations only.

  • Business event Logging (automatic and customizable)
  • Application Logging
  • Session, Trace and LogicNets Log Files
  • Debug Logging
  • IIS/server Logging
  • Windows Event Logging
  • Infrastructure Logging

Business Event Logging

Within your LogicNets business logic, you can create a custom logging event at any place in the process using the Add to Changelog process part. Using this part will add the key and value to the changelog every time the node is traversed. Examples of using this part include

  • a calculated value*
  • a piece of meta data associated with the session but not directly input* by the user (day of week, department, user's cost center, etc.)
  • adding an "event" when a specific menu option is selected

* When Enable usage logging is selected for Assessment Framework applications, all user inputs (form parts) are automatically added to the changelog and no additional modelling is required for those variables to be included in the event log.

Some other processing steps offer the opportunity to add their key/value (data object and stored result) to the event log as a part option. Set data object has this feature, and you can use this part as a second step to another other process part that does not offer logging directly as a part configuration option. (e.g. the result of date calculations does not get added to the log, but you can use set data object to store the result in the log).

The result of logging of this nature is to create a series of records that overall summarize the business selections made. These can be rolled up into reports and charts by modelling additional views using the LogicNets Reporting Framework (requires knowledge of LogicNets Designer and SQLite (views, select statement queries, etc.). These reports can be available under their own LogicNets application or incorporated into the Standard Reporting package.

Application Logging

In addition to any custom or user input logging from above, LogicNets will record a set of security-focused events in the following categories

  • Client Requests and Server Responses, such as a webservice URL requested and their response
  • Account Information such as successful (and failed) authentication attempts
  • System Usage Information such as number of transactions, sessions 
  • Significant Operational Actions, such as application start up and shut down

Release 8.1 includes an extensive new list of new security events generated within the LogicNets standard Access Management package (listed here).

Together with existing events, LogicNets supports the NIST 800-92 guideline. More information on that is available here.

All these application/security events are posted to the changelog (as per business events above) and are available to review and download in the Standard Reporting package

These events are also stored for backup and security purposes in a separate file in JSON format.

Session, Trace and LogicNets Error Log Files

During runtime, the LogicNets engine will create several files on the logicnets installation as follows:

  • session files are created in the .../[company]/dat/bnt/ses folder and are written in binary format for performance and security reasons by default (this can be changed in the config.sys file (see here). This folder also contains any temporary session tables generated by the client application.
    Session files are read and written to on every click and contain the latest snapshot of the context (data model structure and values) and other settings used by the LogicNets engine.
  • trace files are located in the .../[company]/dat/bnt/trace folder and consist of the sequence of steps taken by the LogicNets engine 
  • error log files are created in the .../[company]/dat/bnt/log folder and consist of entries when there has been an error during runtime (e.g. a database SELECT statement error)

These files are removed from the logicnets installation folder on a daily basis after the retention period. The default retention period is 7 days but that can be configured differently (see here).

Debug Logging

For those more technically advanced on-premise installation users of LogicNets, it is possible to add debug log events that show in Debugger logs (such as those collected by dbgview.exe). These events are added using the Debug Logging part

[For on-premise installations only]. More details of how you can view debug logs on the server are here.

IIS Server Logging

IIS server logs can be configured in the IIS Manager, and they are available for viewing in the logs in ../windows/system/inetpub folder. These log events are useful to review when checking what LogicNets processes have been running.

Windows Event Logging

While not LogicNets specific, windows event logs can sometimes be useful to see what caused a machine crash or other unexpected event. These are available through the standard Microsoft Windows Event Manager.

Infrastructure Logging 

[For Hosted Installations Only] 

On LogicNets hosted environments, we monitor and track a wide range of events associated with the WAF, Load Balancer and other infrastructure components. If you would like to understand more about this or have questions regarding your on-premise installation, please contact your LogicNets Project Manager.

Changelog Table

The changelog table that houses the business and application logging events is located in the data.db and serves as the source of data for the Standard Reporting package. Given the growing size of this table over time in larger applications, the desire to move/manipulate data faster, and potentially merge data from multiple sources, it is possible to periodically move data from here to an enterprise db. Read this article for more information.

Reply Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
Like Follow
  • 3 wk agoLast active
  • 16Views
  • 1 Following

Home