Like most companies, Lyft is data driven. We have hypotheses and use data to support or invalidate them. If you are reading this blog, you probably have a Clutch gateway instance running and have a custom workflow built. If you ever wondered how often those workflows are being used, we will show you how you can easily use Clutch’s built-in Security Auditing as a way to track and report on usage. The audit middleware saves data on each incoming request to a database and any additional sinks of your choosing. With this data, we can track usage of Clutch itself and its integrations.
Like most companies, Lyft is data driven. We have hypotheses and use data to support or invalidate them. If you are reading this blog, you probably have a Clutch gateway instance running and have a custom workflow built. If you ever wondered how often those workflows are being used, we will show you how you can easily use Clutch’s built-in [Security Auditing](https://clutch.sh/docs/advanced/security-auditing) as a way to track and report on usage. The audit middleware saves data on each incoming request to a database and any additional sinks of your choosing. With this data, we can track usage of Clutch itself and its integrations.
Here’s a recap of Clutch’s security auditing architecture ([Security Auditing](https://clutch.sh/docs/advanced/security-auditing)):
In Lyft’s configuration, we are storing our audit data to a PostgreSQL database in a table called `public.audit_events`. Within `AUDIT_EVENTS`, we want to focus on two columns, `OCCURRED_AT` and `DETAILS`.
In Lyft’s configuration, we are storing our audit data to a PostgreSQL database in a table called `public.AUDIT_EVENTS`. Within `AUDIT_EVENTS`, there are two columns that are the most relevant to us, `OCCURRED_AT` and `DETAILS`.
`OCCURRED_AT` stores the date / time of the event.
`DETAILS` stores event information in JSON
If you are not familiar with traversing JSON with Postgres, take a quick peek at JSON Functions and Operators.
With this SQL statement, we are able to get a list of all users and the actions they performed in Clutch over the last 90 days. If you are not familiar with traversing JSON with Postgres, take a quick peek at [JSON Functions and Operators](https://www.postgresql.org/docs/9.4/functions-json.html).
```sql
SELECT
occurred_at
,details->>'user_name'asuser_name
,details->>'method_name'asmethod_name
FROM
public.AUDIT_EVENTS
WHERE
occurred_at>=NOW()-INTERVAL'90d'
```
Using a 'Business Intelligence' tool, we can take this data and create nice charts to examine usage over time. We like to look at unique users per month and week and actions performed over the last 14 days and 90 days. From these charts, we can easily see which workflows are the most frequently used and how often Clutch is being used.
That’s it! Now, for some nuance. Our audit log only contains events sent to the middleware, so things like button clicks do not get logged. However, without installing tools like Google Analytics, mining the audit log is an easy way to see what your users are taking actions on.
If you are concerned about logging too much or logging sensitive information (e.g. PII), the Clutch middleware supports annotations that prevents a field from being logged.
Annotate the proto with “[ (clutch.api.v1.log) = false ]” to prevent a field from being logged.
Annotate the proto with `[ (clutch.api.v1.log) = false ]` to prevent a field from being logged.
At Lyft, for some actions we log entire response objects and are able to generate reports detailing information like how often our Slack integration is being utilized or which specific resources are being actioned against most often, all through the audit logs.
If you are interested in turning on Security Audit logging with Clutch, take a look at our guide.
Have a question? Join us in our Slack!
## Want to get involved?
To learn more about Clutch, contribute, or follow along:
* Check our [documentation](https://clutch.sh/) and [code](https://github.com/lyft/clutch)
* Join the [Community](https://clutch.sh/docs/community/)
