Events that happen anywhere on an instance of LabKey Server are logged for later use by administrators who may need to track down issues or document what has occurred for compliance purposes. Different types of events are stored in separate log categories on the master Audit Log. In addition, there are other locations where system and module-specific activities are logged.

Master Audit Log

The master Audit Log is available to site administrators from the Admin Console. Users with the site-wide role "Troubleshooter" can also read the audit log.

  • Select (Admin) > Site > Admin Console.
  • Under Management, click Audit Log.
  • Use the dropdown to select the specific category of logged events to view. See below for detailed descriptions of each option.

The categories for logged events are listed below. Some categories are associated with specific modules that may not be present on your server.

  • 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 settings events: Information about modifications to authentication configurations and global authentication settings.
  • Client API Actions: Information about audit events created by client API calls.
  • Copy-to-Study Assay events: Events related to copying assay data into a study.
  • Dataset events: Inserting, updating, and deleting dataset records. QC state changes.
  • Domain events: Data about domain (list, dataset, etc.) creation, deletion, and modification.
  • Domain property events: Records per-property changes to any domain. 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.
  • Flow events: Keyword changes in the flow module.
  • 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.
  • Inventory Events: Events related to freezer inventory locations, boxes, and items. (Freezer management will be added in a future release.)
  • LDAP Sync Events (Premium Feature): The history of LDAP sync events and summary of changes made.
  • List events: Creating and deleting lists. Inserting, updating, and deleting records in lists.
  • Logged sql queries (Premium Feature): 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 made via SQL queries, such as inserting and updating records using the query. Note that changes to samples are not recorded in the query update events section; they are tracked in sample timeline events instead.
  • Sample timeline events: Events occurring for individual samples in the system.
  • Sample Type events: Summarizes events from sample type inserts or updates.
  • Samples workflow events: Events related to jobs and tasks created for managing samples.
  • Search: Text searches requested by users and indexing actions.
  • 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 and troubleshooters 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 Dataset Properties.
ETL JobsSee ETL: Logs and Error Handling.
Files Web PartClick Audit History. See File Repository Administration.
ListsGo to (Admin) > Manage Lists. Click View History for the individual list.
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. Options 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. Hover over a row to see a (details) link. Click to see the logged details.

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 (legacy name used for Sample Type Audit Events)
  • SearchAuditEvent
  • SelectQuery

Related Topics


Was this content helpful?

Log in or register an account to provide feedback

expand all collapse all