Skip to content

Retrieve

Read back the cohort the Receiver diverted from the log analyzer into a customer-owned S3 bucket (fingerprinted by log pattern, indexed by Bloom filter). When a pattern carries an offload action, those events flow to the bucket instead of the log analyzer. The Retriever fetches them back on demand, byte-range-scoped, reading the bucket in place rather than copying or re-ingesting. The bucket stays in the customer's account.

You

pull payment_retry for acme-corp, 90d back

Log10x

412 events match the tenant filter, pulled directly from S3. Time-bucketed series available, or raw events.

You

30d series of Payment_Retry, hourly, by tenant

Log10x

720 hourly buckets, broken down by tenant. ~8B events in the window, so per-bucket counts are sampled estimates; shape and tenant ranking stay reliable.

You

what's in the overflow bucket this month?

Log10x

3 patterns · 12.4 GB total · top grower +18%/week. Fetch any of them back with a query.

You ask Example answer
pull payment_retry for acme-corp, 90d back Raw events, count rollups, time-bucketed series, pulled directly from S3.
30d series of Payment_Retry, hourly, by tenant A time series across the full window, broken down by tenant.
what's in the overflow bucket this month? 3 patterns · 12.4 GB total · top grower +18%/week.

Prerequisites

These tools require the Retriever deployed, with at least one pattern assigned an offload action via log10x_configure_engine.