Master Audit Log

The master Audit Log is available to site administrators from the Admin Console:

  • Select (Admin) > Site > Admin Console.
  • Click the Settings tab.
  • Under Management, click Audit Log.
  • Use the dropdown to select the kind of activity to view. See below for detailed descriptions of each dropdown value.

The dropdown groups events as follows:

  • Assay/Experiment events: Assay run import and deletion, assay publishing and recall.
  • Attachment events: Adding, deleting, and downloading attachments on wiki pages and issues.
  • Authentication Provider Configuration events: Enabling and disabling authentication providers, such as LDAP.
  • Client API Actions: Errors raised by client API calls.
  • Copy-to-Study Assay events: Events related to copying assay data into a study.
  • Dataset events: Inserting, updating, and deleting datasets records. QC state changes.
  • Domain events: Changes to column properties. Creating and deleting domains.
  • Domain property events: Records per-property changes to any domain (list, dataset, specimen table, assay result, etc.). If a user changed 3 properties in a given domain, the "Domain events" log would record one event for changes to any properties; the "Domain property events" log would show all three events. The comment field of a domain property event shows the values of the attributes of the property that were created or changed, such as PHI level, URL, dimension, etc.)
  • File batch events: Processing batches of files.
  • File events: Changes to a file repository.
  • Group events: The following group-related events are logged:
    • Administrator created a group.
    • Administrator deleted a group.
    • Administrator added a user or group to a group.
    • Administrator removed a user or group from a group.
    • Administrator assigned a role to a user or group.
    • Administrator unassigned a role from a user or group.
    • Administrator renamed a group.
    • Administrator configured a container to inherit permissions from its parent.
    • Administrator configured a container to no longer inherit permissions from its parent.
  • List events: Creating and deleting lists. Inserting, updating, and deleting records in lists.
  • Logged sql queries: SQL queries sent to the database, including the date, the container, the user, and any impersonation information. Applies to SQL queries sent to the native database only; does not apply to external data sources. To log SQL queries from external data sources, see SQL Query Logging.
  • Message events: Message board activity, such as email messages sent.
  • Pipeline protocol events: Changes to pipeline protocols
  • Project and Folder events: Creation, deletion, renaming, and moving of projects and folders. Changes to file roots are also audited.
  • Query export events: Query exports to different formats, such as Excel, TSV, and script formats.
  • Query update events: Changes to SQL queries, such as inserting and updating records in the query.
  • Sample Set events: Records inserted and updated in sample sets.
  • Search: Text searches requested by users.
  • Site Settings events: Changes to the site settings made on the "Customize Site" and "Look and Feel Settings" pages.
  • Specimen Comments and QC: Comments and QC changes in specimen repositories.
  • Study events: Study events, including sharing of R reports with other users.
  • User events: All user events are subject to the 10 minute timer. For example, the server will skip adding user events to the log if the same user signs in from the same location within 10 minutes of their initial login. If the user waits 10 minutes to login again then the server will log it.
    • User added to the system (via an administrator, self sign-up, LDAP, or SSO authentication).
    • User verified and chose a password.
    • User logged in successfully (including the authentication provider used, whether it is database, LDAP, etc).
    • User logged out.
    • User login failed (including the reason for the failure, such as the user does not exist, incorrect password, etc). The IP address from which the attempt was made is logged for failed login attempts.
    • User changed password.
    • User reset password.
    • User login disabled because too many login attempts were made.
    • Administrator impersonated a user.
    • Administrator stopped impersonating a user.
    • Administrator changed a user's email address.
    • Administrator reset a user's password.
    • Administrator disabled a user's account.
    • Administrator re-enabled a user's account.
    • Administrator deleted a user's account.

Allowing Non-Admins to See the Audit Log

By default, only administrators can view audit log events and queries. If an administrator would like to grant access to read audit log information to a non-admin user or group, they can do so assigning the role "See Audit Log Events". For details see Security Roles Reference.

Other Logs

Other event-specific logs are available in the following locations:

Logged EventLocation of Log
Assays Copied to a StudySee Copy-To-Study History.
DatasetsGo to the dataset's properties page, click Show Import History. See Edit Dataset Properties.
ETL JobsSee ETL: All Jobs History.
Files Web PartSee File Repository Administration.
ListsSee Manage Lists.
Project UsersGo to (Admin) > Folder > Project Users, then click History.
Queries (for external data sources)See SQL Query Logging.
Site UsersGo to (Admin) > Site > Site Users, then click History.
All Site ErrorsGo to (Admin) > Site > Admin Console > Settings and click View All Site Errors under Diagnostics. Shows the current contents of the labkey-errors.log file from the <CATALINA_HOME>/logs directory, which contains critical error messages from the main labkey.log file.
All Site Errors Since ResetGo to (Admin) > Site > Admin Console > Settings and click View All Site Errors Since Reset under Diagnostics. View the contents of labkey-errors.log that have been written since the last time its offset was reset through the Reset Site Errors link.
Primary Site Log FileGo to (Admin) > Site > Admin Console > Settings and click View Primary Site Log File under Diagnostics. View the current contents of the labkey.log file from the <CATALINA_HOME>/logs directory, which contains all log output from LabKey Server.

Setting Audit Detail Level

You can set the level of auditing detail on a table-by-table basis, determining the level of auditing for insert, update, and delete operations. Option include:

  • NONE - No audit record.
  • SUMMARY - Audit log reflects that a change was made, but does not mention the nature of the change.
  • DETAILED - Provides full details on what change was made, including values before and after the change.
When set to detailed, the audit log records the fields changed, and the values before and after. A Details link appears in the audit log, linking to full information.

The audit level is set by modifying the metadata XML attached to the table. For details see Query Metadata: Examples.

Write Audit Log to File System

Audit Log messages can be written to the filesystem in addition to being stored in the database. Such additional archiving may be required for compliance with standards and other requirements.

To configure filesystem logging, an administrator edits the log4j.xml file, which is deployed to the $LABKEY_HOME/build/deploy/labkeywebapp/WEB-INF/classes directory. Note that any other options permitted by log4j can be enabled, including writing the audit log content to the console, using multiple files, etc.

The administrator first creates a log name corresponding to the name of the particular log to record on the filesystem. For example, the GroupAuditEvent log would be written to "labkey.audit.GroupAuditEvent." Within the default log4j.xml file, there is a default template available showing how to include the audit logs and columns to be written to each designated file.

These log messages are not part of any transaction, so even if the writing of the audit event to the database fails, the writing to the filesystem will already have been attempted.

The format of audit messages written to the designated file(s) or other output source is:

<eventType> - key: value | key: value | …

For example:

UserAuditEvent - user: (1003) | auditEventCreatedBy: (1003) 
| container: / (48d37d74-fbbb-1034-871f-73f01f3f7272) | comment: logged in
successfully via Database authentication. |

Audit Event Types

The audit event types available for writing to the filesystem include, but are not limited to:
  • AppPropsEvent - written upon change to a System setting (such as one of the Compliance settings)
  • AssayPublishAuditEvent - written when an assay is published
  • AttachmentAuditEvent - one action that triggers this is to attach a file to a message
  • AuthenticationProviderConfiguration - written upon a change to authentication settings (e.g., enable/disable self-signon)
  • ClientAPIActions - triggered when client script code explicitly calls the log
  • ComplianceActivityAuditEvent - written from the complianceActivities module
  • ContainerAuditEvent - creating or deleting containers are two examples
  • DatasetAuditEvent -
  • DomainAuditEvent - creating a new list will create a domain audit event
  • ExperimentAuditEvent
  • FileSystem
  • FileSystemBatch
  • GroupAuditEvent - creating or modifying a group will create one of these events
  • ListAuditEvent - updating a list will create such an event
  • LoggedQuery - written from the compliance module
  • MessageAuditEvent - generated when an email message is sent
  • PipelineProtocolEvent
  • QueryExportAuditEvent
  • QueryUpdateAuditEvent
  • SampleSetAuditEvent
  • SearchAuditEvent
  • SelectQuery

Related Topics


Was this content helpful?

Log in or register an account to provide feedback

expand all collapse all