LogoLogo
Log in|Playground
  • Welcome
    • Introduction
    • FAQ
  • Capabilities
    • Log Management
    • Infrastructure Monitoring
    • Application Performance Monitoring (APM)
      • Application Metrics
      • Traces
      • Supported Technologies
    • Real User Monitoring (RUM)
  • Getting Started
    • Requirements
      • Kubernetes requirements
      • Kernel requirements for eBPF sensor
      • CPU architectures
      • ClickHouse resources
    • Installation & updating
    • Connect Linux hosts
    • Connect RUM
    • 5 quick steps to get you started
    • groundcover MCP
      • Configure groundcover's MCP Server
      • Getting-started Prompts
      • Real-world Use Cases
  • Use groundcover
    • Monitors
      • Create a new Monitor
      • Issues page
      • Monitor List page
      • Silences page
      • Monitor Catalog page
      • Monitor YAML structure
      • Embedded Grafana Alerts
        • Create a Grafana alert
    • Dashboards
      • Create a dashboard
      • Embedded Grafana Dashboards
        • Create a Grafana dashboard
        • Build alerts & dashboards with Grafana Terraform provider
        • Using groundcover datasources in a Self-hosted Grafana
    • Insights
    • Explore & Monitors query builder
    • Workflows
      • Create a new Workflow
      • Workflow Examples
      • Alert Structure
    • Search & Filter
    • Issues
    • Role-Based Access Control (RBAC)
    • Service Accounts
    • API Keys
    • APIs
    • Log Patterns
    • Drilldown
    • Scraping custom metrics
      • Operator based metrics
      • kube-state-metrics
      • cadvisor metrics
    • Backup & Restore Metrics
    • Metrics & Labels
    • Add custom environment labels
    • Configuring Pipelines
      • Writing Remap Transforms
      • Logs Pipeline Examples
      • Traces Pipeline Examples
      • Logs to Events Pipeline Examples
      • Logs/Traces Sensitive Data Obfuscation
      • Sensitive Data Obfuscation using OTTL
      • Log Filtering using OTTL
    • Querying your groundcover data
      • Query your logs
        • Example queries
        • Logs alerting
      • Query your metrics
      • Querying you data using an API
      • Using KEDA autoscaler with groundcover
  • Log Parsing with OpenTelemetry Pipelines
  • Log and Trace Correlation
  • RUM
  • Customization
    • Customize deployment
      • Agents in host network mode
      • API Key Secret
      • Argo CD
      • On-premise deployment
      • Quay.io registry
      • Configuring sensor deployment coverage
      • Enabling SSL Tracing in Java Applications
    • Customize usage
      • Filtering Kubernetes entities
      • Custom data retention
      • Sensitive data obfuscation
      • Custom storage
      • Custom logs collection
      • Custom labels and annotations
        • Enrich logs and traces with pod labels & annotations
        • Enrich metrics with node labels
      • Disable tracing for specific protocols
      • Tuning resources
      • Controlling the eBPF sampling mechanism
  • Integrations
    • Overview
    • Workflow Integrations
      • Slack Webhook Integration
      • Opsgenie Integration
      • Webhook Integration
        • Incident.io
      • PagerDuty Integration
      • Jira Webhook Integration
      • Send groundcover Alerts to Email via Zapier
    • Data sources
      • OpenTelemetry
        • Traces & Logs
        • Metrics
      • Istio
      • AWS
        • Ingest CloudWatch Metrics
        • Ingest CloudWatch Logs
        • Ingest Logs Stored on S3
        • Integrate CloudWatch Grafana Datasource
      • GCP
        • Ingest Google Cloud Monitoring Metrics
        • Stream Logs using Pub/Sub
        • Integrate Google Cloud Monitoring Grafana Datasource
      • Azure
        • Ingest Azure Monitor Metrics
      • DataDog
        • Traces
        • Metrics
      • FluentBit
      • Fluentd
      • JSON Logs
    • 3rd-party metrics
      • ActiveMQ
      • Aerospike
      • Cassandra
      • CloudFlare
      • Consul
      • CoreDNS
      • Etcd
      • HAProxy
      • Harbor
      • JMeter
      • K6
      • Loki
      • Nginx
      • Pi-hole
      • Postfix
      • RabbitMQ
      • Redpanda
      • SNMP
      • Solr
      • Tomcat
      • Traefik
      • Varnish
      • Vertica
      • Zabbix
    • Source control (Gitlab/Github)
  • Architecture
    • Overview
    • inCloud Managed
      • Setup inCloud Managed with AWS
        • AWS PrivateLink Setup
        • EKS add-on
      • Setup inCloud Managed with GCP
      • Setup inCloud Managed with Azure
      • High Availability
      • Disaster Recovery
      • Ingestion Endpoints
      • Deploying in Sensor-Only mode
    • Security considerations
      • Okta SSO - onboarding
    • Service endpoints inside the cluster
  • Product Updates
    • What's new?
    • Earlier updates
      • 2025
        • Mar 2025
        • Feb 2025
        • Jan 2025
      • 2024
        • Dec 2024
        • Nov 2024
        • Oct 2024
        • Sep 2024
        • Aug 2024
        • July 2024
        • May 2024
        • Apr 2024
        • Mar 2024
        • Feb 2024
        • Jan 2024
      • 2023
        • Dec 2023
        • Nov 2023
        • Oct 2023
Powered by GitBook
On this page
  • Data Retention Strategies
  • Controlling Retention
  • Simple Data Retention
  • Default retention values
  • Advanced Data Retention
Export as PDF
  1. Customization
  2. Customize usage

Custom data retention

Data Retention Strategies

There are two ways to define retention in groundcover:

  1. Simple - each type of data has a global retention period

  2. Advanced - data is retained based on various criteria such as cluster, log level, namespace, etc.

For metrics, only the simple strategy is supported.

Controlling Retention

For managed inCloud deployments, the values will need to be set by the groundcover team. Please contact us to perform any retention changes.

To customize the retention on the groundcover platform, either create a new custom-values.yaml or edit your existing values.yaml with the overrides defined below and redeploy groundcover.

Retention Field Format

Retention value format is: {amount}[h(ours), d(ays), w(eeks), y(ears)] .

For example: 4h, 30d, 6w, 1y

Simple Data Retention

The most common and simple way to configure retention in groundcover. Based solely on data type, without exceptions.

Below is an example configuration for setting data retention values:

global:
  traces:
    retention: 24h # default traces retention
  logs:
    retention: 3d # default logs retention
  events:
    retention: 7d # default events retention
victoria-metrics-single:
  server:  
    retentionPeriod: 7d # default metrics retention

Default retention values

  • Traces - 24 hours

  • Metrics - 7 days

  • Logs - 3 days

  • Events - 7 days

  • Traces - 48 hours

  • Metrics - 30 days

  • Logs - 30 days

  • Events - 7 days

Advanced Data Retention

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.

Custom Retention Overrides

The custom_retention_overrides list allows you to define specific retention periods for data based on conditions. Each override has a retention field and a conditions field.

  • Retention: Specifies the duration for which the data should be retained.

  • Conditions: Specify the criteria that the retention policy applies to. When multiple conditions are set, they are connected by an AND condition, meaning all conditions must be met.

Default Retention

The retention field under each data type (traces, logs, events) specifies the default retention period for that data type, meaning, anything that doesn't match the custom conditions set.

If a default retention value is not set for a certain datatype, groundcover will apply its own default retention from the default list described above.

In instances of overlapping overrides, the override with the shorter retention interval will be used.

Example Advanced Configuration File

The configuration below implements the following logic:

  • Traces

    • Traces with labels cluster: prod, namespace: app will be retained for 7d

    • Traces with label env: staging will be retained for 14d

    • Other traces will be retained for 24h

  • Logs

    • Logs with labels cluster: prod, level: info will be retained for 20d

    • Logs with labels cluster: prod, level: error will be retained for 30d

    • Other logs will be retained for 3d

  • Events

    • Events with labels cluster: dev, type: Warning will be retained for 15d

    • Other events will be retained for 15d

global:
  traces:
    retention: 24h # default traces retention
    custom_retention_overrides:
      - retention: 7d
        conditions:
          cluster: 'prod'
          namespace: 'app'
      - retention: 14d
        conditions:
          env: 'staging'
  logs:
    retention: 3d # default logs retention
    custom_retention_overrides:
      - retention: 20d
        conditions:
          cluster: 'prod'
          level: 'info'
      - retention: 30d
        conditions:
          cluster: 'prod'
          level: 'error'
  events:
    retention: 7d # default events retention
    custom_retention_overrides:
      - retention: 15d
        conditions:
          type: 'Warning'
          cluster: 'dev'

victoria-metrics-single:
  server:
    retentionPeriod: 7d # {amount}[h(ours), d(ays), w(eeks), y(ears)]

Available Retention Fields

Logs

  • cluster

  • source

  • env

  • env_type

  • workload

  • namespace

  • level

Traces

  • cluster

  • source

  • env

  • env_type

  • protocol_type

Events

  • cluster

  • source

  • env_name

  • entity_workload

  • entity_namespace

  • type

Last updated 8 months ago