Replies: 3 comments 10 replies
-
|
So glad you brought this up! It's definitely a pain point. Some color:
So pain points from my end are scaling (how many auditable resources do we really want) and UX (how many audit log lines do we really want; how can we make associations between log items clear; how do we handle filtering). |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the extra context links. A thought on secondary audit events is that many can be implemented on the persistence layer itself. So every change to the db will automatically drop these logs. You bring up even more points of "secondary events" such as failed jobs. This would give the provisioner a way to drop an audit logs as a failed event relating to the primary user action. This does bring up a question though. Should the provisioner log show in the UI as it's own row? Or underneath the |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of toggling because I actually think it might keep the UI simpler. What I would like to avoid is having to put in a bunch of filtering so users can make sense of the view - as @spikecurtis mentioned below, most filtering is probably going to be done in Splunk. IDK though - warrants more thought. |
Beta Was this translation helpful? Give feedback.
-
|
In the RFC, we set this as a requirement, and the proposed solution was to generate a RequestID that would tie together multiple logs if the request resulted in multiple actions. |
Beta Was this translation helpful? Give feedback.
-
|
It does seem like we might have to store the Originally I was thinking it can all go on the |
Beta Was this translation helpful? Give feedback.
-
|
I mean, we should already be storing it on the Audit Logs, but in the case that a request writes something to the database which then gets picked up by some background process (e.g. builds) then yes, the job that gets picked up would need the request ID. |
Beta Was this translation helpful? Give feedback.
-
|
I do like the idea of I still think there is value in |
Beta Was this translation helpful? Give feedback.
-
|
Have we done any investigation into how other products that often involve linked, async requests handle their audit logs (e.g. CI vendors (e.g. circleci), git providers (e.g. gitlab), or identify-based access tools (e.g. teleport)? I'm personally curious if there are any patterns in how they link/relate logs, mostly to ensure that we don't do something bespoke that may be confusing for customers who are used to consuming logs from these other platforms (via the UI, consuming via the API, or ingesting into Splunk/StackDriver) |
Beta Was this translation helpful? Give feedback.
-
|
@bpmct I have not, but this is essentially tracing which is rather normal. The only flair is how we present it on our UI |
Beta Was this translation helpful? Give feedback.
-
|
Another reason for this is we log If we can link audit log actions, then we could have a |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
Currently audit logging is initiated per route. This means that each route has at most 1 audit event created. However, single http request can cause multiple changes to multiple entities. This is currently not being tracked.
Examples
Create workspace
Create workspace has multiple db changes;
workspace,parameters,provisioner_job, andworkspace_build. Onlyworkspaceis logged even though 4 different db changes are made.These tables can be updated in other routes and generate different audit log events (eg
workspace_build). But because it is a side effect in thecreate workspaceroute, it is not logged the same as it is inupdate workspace.Question
Should we design/implement a way to audit log side effects?
Example
Create workspace
An audit log for the create workspace should be made, as that is the user action. Side effects of the provisioner job and workspace build should also be logged so that they can be tracked in the context of the original user action.
Now a
provisionercan be searched to see what jobs it ran and see the original context for each job. Without the linking and side effect audit logs, these jobs are impossible to track the origin because only theworkspacediff and id are logged.Proposal
Linked audit logs (parent -> child or primary -> secondary)
Allow creating linked audit logs with an optional
parent_idfield. Setting aparent_idof an audit log allows relating to a primary action. In the UI only parent logs should be shown. Children logs should be hidden under some sort of "toggle" to see all side effects of a primary action.We should not allow infinite nesting, and only allow 1 level of "children" logs. We do not want to build full tracing here.
Linked audit log table
A new audit log table for these secondary audit logs would be created.
Other ideas?
You got any?
Beta Was this translation helpful? Give feedback.
All reactions