Difference between revisions of "Audit Settings"
(→Log Events) |
|||
| (16 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Installation_and_Configuration]] | ||
[[Category:FMR_Configuration_Reference]] | [[Category:FMR_Configuration_Reference]] | ||
| − | =Overview= | + | ==Overview== |
| − | The Fusion Metadata Registry can be used to audit activity, | + | The Audit Settings function is available to logged-in users and found on the main menu. |
| + | |||
| + | The Fusion Metadata Registry can be used to audit activity, for example structure queries and submissions. For each audited event, the associated server side logs can be captured and stored against the event. The Audit tab in the settings Registry Settings enables the level of auditing to be controlled, and the definition of which log events are captured can also be set. Audit and log information can be given a lifetime after which time they will be deleted. | ||
Audit events are split into two categories: | Audit events are split into two categories: | ||
| − | + | ===1. Transactional=== | |
| − | These audit events are ones which result in the Registry modifying structures | + | These audit events are ones which result in the Registry modifying structures, or metadata. A transactional event includes structure submissions and reference metadata submissions.<br> |
| − | + | ===2. Non Transactional=== | |
These audit events are one where information is being read from the Registry, but no information is being modified. These events include (amongst others) data queries, structure queries, and schema queries.<br> | These audit events are one where information is being read from the Registry, but no information is being modified. These events include (amongst others) data queries, structure queries, and schema queries.<br> | ||
| Line 16: | Line 19: | ||
| − | [[File: | + | [[File:Audit7.PNG|Activity Page|1200px]] |
| − | =Audit Events= | + | ==Audit Events== |
Auditing can either be enabled or disabled. | Auditing can either be enabled or disabled. | ||
| − | + | ===Audit Level=== | |
| − | |||
| − | |||
You can either log '''All Events''' (as shown in the example below) or '''Transactional Events''' only.<br> | You can either log '''All Events''' (as shown in the example below) or '''Transactional Events''' only.<br> | ||
| − | |||
'''Delete Audits Every''' input filed can be set how many days the audit events should be kept for, if the field is left empty then the audits will never be deleted. It is important to note that this setting is only relevant for non-transactional events. Transactional audit events will not be deleted even if this setting is applied. | '''Delete Audits Every''' input filed can be set how many days the audit events should be kept for, if the field is left empty then the audits will never be deleted. It is important to note that this setting is only relevant for non-transactional events. Transactional audit events will not be deleted even if this setting is applied. | ||
| Line 31: | Line 31: | ||
| − | [[File: | + | [[File:Audit5.PNG|Audit Events|700px]] |
| − | =Log Events= | + | ==Log Events== |
| − | Logging can be enabled or disabled. | + | Logging can be enabled or disabled. |
| + | ===Logging Level=== | ||
| − | ''' | + | You can either log '''Transactional Events''' (as shown in the example below) or '''All Events''' only. |
| − | + | '''Delete Logs Every''' can be used to specify the number of days or hours that the server logs should be kept for, leaving this filed blank will be used to indicate the logs should never be deleted. Note log events will only be deleted for non-transactional audit events.<br> | |
| − | |||
| + | [[File:Audit6.PNG|Log Events|500px]] | ||
| − | + | '''Note''': In order to take full advantage of the Rollback feature, '''Audit Events''' should be enabled. Additionally, if you wish to review the log file prior to performing a Rollback it is wise to switch on '''Log Events'''.<br> | |
| + | <br> | ||
| − | + | [https://fmrwiki.sdmxcloud.org/Restore_(Rollback)_Structures Click here to read more about Structure Rollback.] | |
Latest revision as of 05:16, 26 March 2024
Contents
Overview
The Audit Settings function is available to logged-in users and found on the main menu.
The Fusion Metadata Registry can be used to audit activity, for example structure queries and submissions. For each audited event, the associated server side logs can be captured and stored against the event. The Audit tab in the settings Registry Settings enables the level of auditing to be controlled, and the definition of which log events are captured can also be set. Audit and log information can be given a lifetime after which time they will be deleted.
Audit events are split into two categories:
1. Transactional
These audit events are ones which result in the Registry modifying structures, or metadata. A transactional event includes structure submissions and reference metadata submissions.
2. Non Transactional
These audit events are one where information is being read from the Registry, but no information is being modified. These events include (amongst others) data queries, structure queries, and schema queries.
Audit events are used to capture additional information for structure modifications.
They are also used to provide an overview of User Activity as shown in the image below.
Audit Events
Auditing can either be enabled or disabled.
Audit Level
You can either log All Events (as shown in the example below) or Transactional Events only.
Delete Audits Every input filed can be set how many days the audit events should be kept for, if the field is left empty then the audits will never be deleted. It is important to note that this setting is only relevant for non-transactional events. Transactional audit events will not be deleted even if this setting is applied.
Log Events
Logging can be enabled or disabled.
Logging Level
You can either log Transactional Events (as shown in the example below) or All Events only.
Delete Logs Every can be used to specify the number of days or hours that the server logs should be kept for, leaving this filed blank will be used to indicate the logs should never be deleted. Note log events will only be deleted for non-transactional audit events.
Note: In order to take full advantage of the Rollback feature, Audit Events should be enabled. Additionally, if you wish to review the log file prior to performing a Rollback it is wise to switch on Log Events.
