Have you ever wanted to know what changed in your workspace? Maybe, you wanted to answer “how did that component get there?” or “who updated this property I’m looking at?”. Today, you’ll be able to answer these questions with the Audit Trail feature.

The Audit Trail feature gives you the ability to know what is going on inside of your workspace with real-time updates. Through a structured log format and a sleek, spreadsheet-like interface, you can see mutations to the system and scope them by entity name, user, change set and more.

How it works

Every mutation you make to the system kicks off an event session. While your mutation makes its way through the system, Audit Logs are published rapidly, but staged in a pending events queue. Once your change is successful, all pending events are drained and asynchronously published as formal Audit Logs to be used by the Audit Trail dashboard.

In essence, the system automatically knows how to flush Audit Logs on success and discard them on failure. All future System Initiative features can and will trivially use the Audit Trail subsystem as the inner workings are abstracted and safely protected.

All Audit Logs share the same structure, which includes the entity name, entity type, kind, metadata and more. However, the metadata field’s structure will change based on the Audit Log kind. This gives each Audit Log kind the ability to attach kind-specific information, such as showing the “before value” and “after value” when updating a property for a component. In fact, the example below showcases the raw Audit Log structure and contents for exactly that scenario.

How it looks

The Audit Trail dashboard displays all Audit Logs for the current selected change set. If you are on HEAD, it will show all Audit Logs for both HEAD and for all change sets that have been applied to HEAD. Every non-timestamp column can be filtered. The filters are populated based on the current set of loaded entries. You can combine filters and select multiple filter options to see exactly what you want.

These screenshots were taken while going through our How to create macOS instances on AWS EC2 guide. As a result, all entity names map to those in the How-to guide if you’d like to use it as a reference.

What it solves

While the Audit Trail feature provides catch-all answers to those curious about what happened in their workspace, it is aimed at specific use cases as well:

• It’s for those with compliance needs or who see a future where you’ll need to ingest System Initiative logs into your data processing stack. This is the first, big step towards tackling your needs.
• It’s for those who use System Initiative and simply want to see how their co-worker modified their infrastructure while they were on vacation. This is the feature you’re looking for.
• It’s for those who are hobbyists who have been searching for the future of DevOps Automation and are looking for something analogous, yet with more potential, than Git history.

Where it's headed

This is the first iteration of the Audit Trail. The architecture is geared towards supporting text search, fuzzy filtering, facet population and the addition of more Audit Log event kinds in the future. In addition, we plan on providing the ability to export Audit Logs out of System Initiative too.

We would love to hear your feedback. Find us on Discord and let us know what you think. You can message me directly at SI_Nick 👋!