Retention filters

What a filter does #

A retention filter matches spans with a query and gives them a keep rate. Spans it matches are kept at that rate; everything else follows your global trace retention.

This is how you keep every error while letting successful traffic thin out.

Writing a filter #

• Name — lowercase letters, digits and dashes, 2 to 39 characters.
• Query — a span query, for example status:error.
• Keep rate — between 1% and 100%.

Retention windows #

• A filter you create indexes matched spans for 15 days.
• The built-in intelligent filter indexes for 30 days.

The intelligent filter #

A built-in filter keeps the spans most worth keeping at full rate — errors, and the slowest requests. It is on by default, which is why errors survive even when the rest of your traffic is sampled.

Simulating before you commit #

Every editor includes a simulator: it applies your candidate filter to the current traffic and shows the share of spans it would keep. Use it before saving a rule against production traffic.

• Spans kept per second, and the share of the corpus.
• The retention each tier would receive.
• The effect on the figures billed.

Filters and monitors #

A monitor on a service's error rate can be affected by the rate you choose, so the editor warns when a candidate filter would exclude spans a monitor counts. Read that warning before saving.

Where sampling ends #

An ingestion control decides what is accepted; a retention filter decides what is kept afterwards. A filter cannot bring back a span that sampling already dropped at the source.

Check the whole set #

The retention summary shows every filter and the share each one holds, so the table and the totals describe one state rather than two.