In SimpleOne, there are several log storages handled by the System Logs module. You can use them for troubleshooting and debugging that may take place. The storages are:
- Main Log – general log storage: all the logs generated by any module or script are recorded there.
- History – storage of the field changes.
- Script Log – storage of the extended logs of the script execution logs
- Exception Log – storage for the exceptions thrown during a server-side query.
- Record Deletion Log – storage for deleted objects.
Role required: admin.
Main Log
You cannot create, edit, or delete records in the Main Log (sys_log) table. Only users with the admin role can read them.
To access this storage, navigate to the System Logs → Main Log.
If you need to find specific records or to sort them in a particular order, use a filter tool at the top of the page. Use the Condition Builder to configure the filters that will fit your needs most.
The following system events are written down in the storage:
- adding attachments
- impersonation
- search performing
- quick import logs
- LDAP user authorization
- LDAP autoprovision (creating user accounts via LDAP)
- email authorization
- calling the server-side SimpleSystem logging methods
- server validation errors
- incoming email errors
- errors occurred when sending incorrect parameters into notifications.
Main Log form fields
| Field | Mandatory | Description |
|---|---|---|
| Source | Y | Message source (the module, script, or functionality that was the originator of the logging). |
| Level | Y | Message importance level:
These messages can be added using relevant SimpleSystem API methods. |
| Message | N | The log message content. |
| Username | N | Reference to the user initiated this record creation. |
In the audit.tables.ignoredList property, you can specify tables which changes will not be saved in history.
History
History storage displays the record field changes in all tables in the human-readable format.
You cannot create, edit, or delete records in the History (sys_history) table. Only users with the admin role can read them.
To access System History, navigate to the System Logs → History.
If you need to find specific records or to sort them in a particular order, use a filter tool at the top of the page. Use the Condition Builder to configure the filters that will fit your needs most.
History form fields
| Field | Mandatory | Description |
|---|---|---|
| Table Name | Y | The table name. |
| Field Name | Y | The changed field. |
| Record | Y | The record ID. |
| Old Value | N | Old record value. |
| New Value | N | New record value. |
| Type | Y | Change type:
|
| Username | Y | Username of the change originator. |
Script Log
This storage is for script execution extended information. All related information can be found here, from the script body to its memory usage.
You cannot create, edit, or delete records in the Script Log (sys_log_script) table. Only users with the admin role can read them.
To access this storage, navigate to System Logs → Script Log.
If you need to find specific records or to sort them in a particular order, use a filter tool at the top of the page. Use the Condition Builder to configure the filters that will fit your needs most.
Script Log record fields
| Field | Mandatory | Description |
|---|---|---|
| Script Document | N | A reference to the script object realized by this script. It may be, for example, a business rule. |
| Script | N | The script body. |
| Result | N | Script execution results (the returned value, as an example). |
| Exception Log | N | Reference to the Exception Log record that appeared during script execution. |
| Essence Document | N | A reference to the object on which this object was executed. Script and Essence documents
|
| Start Time | N | This field shows the script start timestamp (in the Unix time format). |
| Processing Time | N | Script processing time (in seconds). |
| Memory Usage | N | Total script memory usage. |
| Memory Start | N | Script memory usage when it just started. |
| Page | N | The unique ID of the page on which the script was executed. If more than one log records have the same Page UUID, it means that different scripts or actions were running on the same page. |
| URL | N | Page URL where the script has been called. |
| Info | N | Information returned by the script. |
| Username | N | Reference to the user initiated this record creation. |
Exception Log
This storage contains records with the exception thrown when running a script.
You cannot create, edit, or delete records in the Exception Log (sys_log_exception) table. Only users with the admin role can read them.
To access this storage, please navigate to System Logs → Exception Log.
If you need to find specific records or to sort them in a particular order, use a filter tool at the top of the page. Use the Condition Builder to configure the filters that will fit your needs most.
Exception Log
| Field | Mandatory | Description |
|---|---|---|
| Message | N | Error message text returned by script. |
| File | N | PHP-script file that has returned this error. |
| String | N | Line number in script file. |
| Backtrace | N | A call back stack with a list of the functions called. |
| Page URL | N | Link to a page where this exception was thrown. |
Record Deletion Log
This storage keeps information about deleted objects. You can also restore them.
You cannot create and edit records in the Record Deletion Log (sys_record_deletion_log) table. Only users with the admin role can read and delete them.
To access this storage, navigate to System Logs → Record Deletion Log.
Deletion logs are only available to tables with the selected Record Deletion Logging checkbox. See the Table Attributes article to learn more.
If you need to find specific records or to sort them in a particular order, use a filter tool at the top of the page. Use the Condition Builder to configure the filters that will fit your needs most.
| Field | Mandatory | Description |
|---|---|---|
| Table Name | N | Table name to which the deleted record belongs. |
| Record | N | The ID of the deleted record. |
| Parent Record | N | The ID of the deleted record that caused deletion of the current record: if the record A causes deletion of record B, and this causes deletion of record C, then for the C record this field will display record A ID (as the initial cause). This field is populated in case the On Delete attribute in the reference is Cascade. See the Reference Fields article to learn more. |
| Username | N | User who initiated the record deletion. |
| JSON | N | This field stores deleted record attributes in JSON format as an associative massive. {"sys_id": 162212096614481484, "title": "Smith", "sys_created_at": "2021-05-27 13:09:26", "sys_created_by": 155931135900000001, "sys_updated_at": "2021-05-27 13:09:26", "sys_updated_by": 155931135900000001}
|
Restoring a record
To restore a record, perform the following steps:
- Navigate to System Logs → Record Deletion Log.
- Find the record you need using the list search or the Condition Builder:
- choose one or several records by selecting the checkbox at the left
- open the record you need.
- Click Restore.
The restored record will have the attributes described in the JSON field. The system restores record version as it was just before the deletion.
Records are restored one by one, independently from each other. For example, if deletion of record A causes deletion of records B and C, and then record A is restored, records B and C will remain deleted. They need to be restored additionally.
Log Archiving
With time, instance log storage grows over. And at most of the time, logs for the last two weeks or month are needed to analyze.
Log archiving engine allows saving deprecated logs so they do not affect system performance.
How it works
Archiving engine is not active by default. To activate it, please complete the steps below:
- Navigate to System Scheduler → Schedule Script.
- Go to the one of the Run Log Archiving record delivered and select the Active checkbox.
- Click Save or Save and Exit to apply changes.
Default supply includes three archive scripts with different starting time: 01 AM, 03 AM and 05 AM. You can specify another archiving execution time and periodicity by modifying existing records or by cloning them with the Make a copy UI action and modifying the copy.
Archiving background process performs operations as described below:
- Gather logs which are the most outdated to this date.
- Pack them into an archive.
The script determines the oldest log from three tables as listed: sys_log, sys_log_script, sys_log_exception. After that, outdating check is performed (are these logs outdated today or not). For this, the simple.logs.rotate_period_in_days property is added allowing to define logs rotating period in days. If a period is not defined, then the default value is 30 days.
Managing log archives
To unpack a log archive, please complete the steps below:
- Navigate to System Logs -> Archive.
- Find the date you need the logs for and go to the specified logs record.
- On the record form, click on the Unpack button.
- After finishing, all records will be available in relevant tables.
To pack a log archive, please complete the steps below:
- Navigate to log record.
- Click on the Archive unpacked data button.
