The audit log records the actions performed on the CLC Server.
Working with the audit log via the web interface
The audit log can be viewed under:
Management () | Audit log ()
By default, only administrative users have access to this, but this can be extended to members of other groups (see Web admin access).
When first opened, the 50 most recent operations are listed. Older operations can be loaded by clicking on a link at the bottom of the table. Fields at the top can be used to limit the list of operations based on when an action was taken, by whom, what sort of operation it was, and on the job status (success of failure).
Jobs submitted to run on a grid node have a G in the status column and jobs submitted to run on a CLC Genomics Cloud setup have a C in the status column. Every command submitted to the queue goes through the phases "Queued", "Executing", and "Done". The status of failed jobs is visualized by a red exclamation mark in the Status column of a "Command done" entry.
Much information about jobs is available by clicking on the link for each operation. To see all operations for a given job, click on the Show process thread link at the right hand side (figure 12.1).
Figure 12.1: Each operation is logged in the audit log. Items in red are links. Clicking on these allows you to drill down to detailed information. To see just the operations associated with a given job, click on "Show process Thread" on the right hand side. "Command done operations" are preceded by an arrow pointing left. All other commands have arrows pointing right.
In cases such as batch jobs, where there is a master process that submits other jobs to the queue, the process threads are color coded. An example is shown in figure 12.2 for a batch job with 2 batch units. Here, the process threads for each batch unit could be viewed by clicking on Show sub process thread at the right hand side.
Figure 12.2: The process threads for a batch run of Map Reads to Reference containing 2 batch units are shown. Operations related to the batch as a whole are in red. The 2 mapping jobs each have three process threads shown. Those for the first batch unit are in green, and those for the second are in blue.
Click on Show all Threads to return to the full audit log listing.
Note: Data management operations such as copying, deleting and adding files are not Server actions and are thus not recorded in the audit log.
When troubleshooting, it can sometimes be useful to re-launch a particular job. This can be done by finding the "Command queued" operation for the job of interest, and clicking on the link in the "Data in" column (figure 12.3).
Figure 12.3: The link in the audit log to "Batch process: Map Reads to Reference" in the "Data in" column was clicked upon. A button to re-execute that job is available in the window that pops up.
Audit log database and text files
Audit log information is stored in a database. Once a month, and when the CLC Server is started up, entries in the audit log older than 3 months are deleted.
The limit the audit log database can grow to is 64 GB. If a new entry will push the size past this limit, the system will remove some of the oldest entries so that is is possible for newer entries to be added.
Audit information is also written to text-based log files. Upon the first activity on a given date, a new log file called audit.log is created. This file is then used for logging that activity and subsequent Server activities on that day. When this new audit.log file is created, the file that previously had that name is renamed to audit.<actual events date>.log. These log files are retained for 31 days. When the creation of a new audit.log file is triggered, audit log files older than 31 days are checked for and deleted.
The audit log files can be found under the Server installation area under
The audit log text files are tab delimited and have the following fields:
- Date and time
- Log level
- Operation: Login, Logout, Command queued, Command done, Command executing, Change server configuration, Server lifecycle; more may be added and existing may be changed or removed.
- IP Address
- Process name (when operation is one of the Command values) or description of server lifecycle (when operation is Server lifecycle)
- Process identifier - can be used to differentiate several processes of the same type.
- Status - can be used to identify whether the entry was successful or not, e.g. if a job execution failed it will be marked here. Any number other than 0 means failed.