Using custom audit filters
Customizing Atlas audit filters using the users’ criteria provides you with the flexibility to finalize which audit events can be persisted with and which of the events can be ignored.
Custom audit filters are configured in the Atlas server which improves the performance of audit trail and an enhancement towards audit reduction. Using this feature, you can set some predefined rules or conditions that enable you to filter certain events that queues up the storage space in Atlas.
Common example use-cases:
-
User might want to skip audit for all temporary tables.
-
User might want to skip all entities name starts with “test”.
-
User might want to skip all update events for all entities.
-
All types of operation can be allowed for auditing.
-
All types of operation can be ignored from auditing.
-
You can accept/discard audits by one specific attribute or combination of multiple attributes. Example attributes include,
typeName
,isIncomplete
,temporary
, and attributes (likeowner
,qualifiedName
,name
).
The audit filters operate based on a logic that transforms into a rule that results in a single action. The logic executes rules stored in the database to perform the following actions:
-
Retrieve appropriate rules stored in the database
-
Evaluate one or more rules.
-
Match the rule conditions.
-
Perform one or more actions that match the conditions.
-
Result orientation.
-
Repeat the process for the remaining rules.
Custom audit filters are supported using the REST API method.
The following REST API calls are used to perform various custom audit filter operations.
- POST: /api/atlas/admin/audits/rules
- GET: /api/atlas/admin/audits/rules
- PUT: /api/atlas/admin/audits/rules/{guid}
- DELETE: /api/atlas/admin/audits/rules/guid/{guid}
- DELETE: /api/atlas/admin/audits/rules
- DELETE: /api/atlas/admin/audits/rules/all