This is an experimental feature: the API is subject to change and robustness is not yet comparable to production-grade features.
The aging feature enables periodic deletion of events based on user-specified queries. When would you use this?
- The retention policy requires to store data only up to N months.
- The amount of new data exceeds your storage budget in the foreseeable future.
- Sensitive data may enter the system but should not be recorded.
There are two aging mechanisms supported by VAST: content-based aging and quota-based aging.
The most straightforward way to constrain the disk space used by VAST is to configure a disk quota:
Whenever VAST detects that its database directory has grown to exceed the
configured quota, it will erase the oldest data in the database. It is possible
to specify an additional
--disk-quota-low option to define a corridor for
the disk space usage. This can be used to avoid having VAST running permanently
at the upper limit and to instad batch the deletion operations together.
The full set of available options looks like this:
When using this method, we recommend placing the log file outside of the database directory. It counts towards the size calculations, but cannot be automatically deleted during a deletion cycle.
An alternative way to keep the size of the database in check is to erase data based on content. To do this, an aging query can be specified when starting VAST:
The query is periodically executed and returns a set of events that VAST erases from the archive.
Content-based deletion of data currently does not delete the corresponding data in the index, since that might require re-indexing which is not yet implemented.
As a side effect, index statistics from the
vast status command are no
longer reliable after an aging cycle.
It is also possible to set up the aging query using a