Support raw log compaction for tiered retention

[omry]

Hi, thanks for maintaining atop. It is a very useful tool for post-incident investigation.

I would like to request support for compacting atop raw log files to lower sample frequency, ideally integrated with the existing daily rotation flow.

Motivation

High-resolution atop logging is very useful for debugging short-lived issues, especially memory spikes, CPU bursts, IO stalls, or brief process-level anomalies. For example, a 10-minute interval can easily miss a short memory spike that explains an OOM or latency incident.

However, keeping high-resolution raw logs for many days can consume a lot of disk space. In practice, recent data is where fine granularity matters most, while older data is usually useful at a coarser resolution for trend analysis.

Desired policy example

One useful policy would be:

last 24 hours: 1-minute samples
days 2-7:      10-minute samples
older:         delete

This would allow running atop initially at high resolution, e.g.:

LOGINTERVAL=60

Then rotation/retention could compact older files instead of only deleting by age.

Possible compaction capabilities

The key feature is the ability to reduce the sample frequency of an existing raw log.

The simplest useful implementation might be compaction by a fixed factor, e.g. keeping every second sample:

1-minute -> 2-minute -> 4-minute -> 8-minute -> ...

Or, more generally:

compact raw log by factor N

This would already make high-resolution logging much more practical.

A more flexible implementation would support compacting to a target interval:

1-minute -> 10-minute
1-minute -> 1-hour
10-minute -> 1-hour

That would make policies like this easy to express:

last 24 hours: 1-minute samples
days 2-7:      10-minute samples
older:         delete

Possible integration

This seems like it could fit naturally into the existing rotation process:

1. Run atop with a high initial logging resolution, e.g. LOGINTERVAL=60.
2. On daily rotation, close the current raw log and start a new one.
3. Compact older raw logs according to the configured retention policy.
4. Delete logs older than the final retention window.

This could be implemented either directly in atop, as a helper tool for raw-log compaction, or as an extension of the existing rotation script/service.

Open question

I am not sure whether atop already has a safe way to rewrite/compact raw logs to a coarser sampling interval. If such a mechanism already exists, documenting how to use it with rotation would solve much of this.

Acceptance criteria

An administrator should be able to run atop at high initial resolution and configure automatic retention/compaction such as:

last 24 hours: 60-second samples
days 2-7:      600-second samples
older:         delete

without needing custom scripts that understand atop's raw log format.