Deliberate search

OBSESC answers aggregate questions from the navigation tier straight away. Searches that must read your raw events work differently: OBSESC works out how much they could read and checks that against a limit before they run. We call this deliberate search. Nothing stops you running a big search. OBSESC just tells you how big it is before it starts.

Two kinds of question

Question	Answered from	Cost to run
”How many 5xx did checkout return per day last quarter?”	Navigation tier	Fast at any range
”Show me every event containing TOK-99 last quarter”	Fidelity tier (your S3 bucket)	Reads Parquet from S3. Checked against your limit first

Explore views, What changed?, Seen this before?, What tends to follow? and timelines of unusual behaviour are the first kind. Search, SQL over raw_events, event context and drill-down are the second.

The scan limit

Before a search reads raw data, OBSESC works out an upper bound on how much it could read. If that is above your limit, OBSESC does not run it straight away. It tells you how much it would read and asks you to confirm.

The figure is a ceiling, not a forecast. A query with LIMIT usually stops early and reads far less.

The deployment sets a default limit. You can confirm a larger search when you need to. Contact us if you want a different default.

Protecting ingest

Searches share the node with ingest. When several heavy searches arrive together, some wait their turn rather than being rejected, so ingest is not slowed down.

Searching across services

In the console you can search every service at once. Searching every service may not include the most recent events, and a very large search may not cover the whole time range in one go. For a thorough search, name a service and bound the time range, or use SQL over raw_events.

Writing searches that stay small

• Always bound the time range.
• Name the service when you know it.
• Add LIMIT when you only need examples.

See the SQL reference and Search and filtering for syntax.