Custom data retention
Last updated
There are two ways to define retention in groundcover:
Simple - each type of data has a global retention period
Advanced - data is retained based on various criteria such as cluster, log level, namespace, etc.
For metrics, only the simple strategy is supported.
For BYOC deployments, the values will need to be set by the groundcover team. Please contact us to perform any retention changes.
Retention value format is: {amount}[h(ours), d(ays), w(eeks), y(ears)] .
For example: 4h, 30d, 6w, 1y
The most common and simple way to configure retention in groundcover. Based solely on data type, without exceptions.
Below are the default retention values for BYOC:
Traces - 7 Days
Metrics - 30 days
Logs - 30 days
Events - 7 days
The following is not supported for metrics - which allow only a global retention period
groundcover allows you to customize retention policies for your data to better manage storage and compliance requirements. You can define specific retention periods for logs, traces, and events based on various criteria such as cluster, log level, namespace and more.
The following rules apply:
Values not meeting any criteria will use the default retention period for the specific data type
In instances of overlapping overrides, the override with the shorter retention interval will be used
Traces
Traces with cluster: prod, namespace: app - 7d
Traces with env: staging - 14d
Else - 24h
Logs
Logs with cluster: prod, level: info - 20d
Logs with cluster: prod, level: error - 30d
Else - 3d
Events
Events with cluster: dev, type: Warning - 15d
Else - 15d
Only exact matches are supported - regex or pattern matching is not available
You can use any of the fields below to specify custom retention for the relevant data type
Logs
cluster
source
env
env_type
workload
namespace
level
Traces
cluster
workload
container
source
env
env_type
protocol_type
server
return_code
Events
cluster
source
env_name
entity_workload
entity_namespace
type
Last updated