Loki’s compactor is what actually enforces your retention policies, and it does it by deleting data that’s older than your configured retention period.
Let’s see how Loki handles data deletion and retention. Imagine you have a Loki instance running, and you’ve set up a retention policy. You’ve probably done this by setting chunk_store_config.max_look_back_period in your Loki configuration, something like 30d or 90d. This is the theoretical maximum age of data Loki will try to keep. But it’s the compactor that makes this happen.
Here’s a simplified view of the data flow: Logs are ingested and written into chunks. These chunks are initially stored in a temporary location (like local disk or S3 if using object storage). Over time, these chunks are "compacted." This compaction process involves reading smaller chunks, merging them into larger ones, and then writing these larger chunks to their final, long-term storage. This is crucial for query performance and storage efficiency.
The compactor’s job is to manage these compacted chunks. It periodically scans the tenant data, identifies chunks that are older than the max_look_back_period, and then initiates their deletion from the long-term storage. It doesn’t delete raw ingested logs; it deletes the compacted chunks that represent those logs.
Consider a Loki setup with object storage (like S3). When logs are ingested, they are written as small chunks to S3. The compactor’s job is to:
- Identify old chunks: It looks at the metadata of compacted chunks in your object storage bucket.
- Mark for deletion: If a chunk’s data falls outside the
max_look_back_period, it’s marked for deletion. - Delete chunks: The compactor then issues delete commands to the object storage service for these marked chunks.
Here’s a snippet from a typical Loki configuration file (loki-local.yaml or similar) that controls retention:
compactor:
data_directory: /loki/boltdb-shipper
shared_store: s3 # Or your configured object storage
retention_period: 7d # This is the key setting for deletion
# ... other compactor settings
In this example, retention_period: 7d tells the compactor to delete any compacted chunks that are older than 7 days. This is the primary lever for controlling how long your logs are actually stored.
The compactor operates on a schedule. By default, it runs periodically to perform its cleanup tasks. You can configure this frequency, but the core action is the deletion of old chunks.
What most people don’t realize is that the max_look_back_period in chunk_store_config is more of a query-time cutoff. The compactor uses its own retention_period setting (or similar configuration depending on Loki version and setup) to physically remove data. If retention_period is set to 30d, and max_look_back_period is set to 90d, Loki will stop querying data older than 90 days, but the compactor will delete data older than 30 days. The compactor’s retention_period is the actual storage deletion trigger.
If you want to change your retention from 30 days to 7 days, you’d edit your Loki configuration file, specifically the compactor section:
compactor:
# ...
retention_period: 7d
# ...
After restarting the Loki compactor (or the entire Loki deployment if it’s a monolithic setup), it will start deleting chunks older than 7 days. It’s important to note that this is not instantaneous. The compactor works through existing data over time. You might still see data slightly older than 7 days for a while until the compactor has processed all the relevant chunks.
The next thing you’ll likely encounter is understanding how Loki’s querier interacts with this deleted data, and what happens to query performance as data ages and is eventually deleted.