OBSESC Explore
An overview of the ways to query OBSESC from the console, and how large queries are checked before they run.
OBSESC answers questions about your logs in two ways. The navigation tier keeps compact summaries that make exploring your history fast. The fidelity tier is every original event, stored as Parquet in your own bucket. This page shows where to ask each kind of question in the console, and how OBSESC protects you from running a very large query by accident.
Ways to query
| Question | Where in the console | Reads raw data? |
|---|---|---|
| Arbitrary questions in SQL, down to individual rows | Explore (SQL reference) | Yes. Large queries ask for confirmation first. |
| Counts, distinct counts, percentiles and top values over time | Trends and Services | No |
| ”Where does this appear?” and “show me the lines” | Search (Search and filtering) | Yes, as needed |
| ”What is different about this period?” | What changed? | No |
| ”When did this last happen?” | Seen this before? | No |
| ”What happened next in this incident?” | What tends to follow? | No |
The tools work well together. Find a period of interest from an anomaly or a search. Explain it with What changed?. Check your history with Seen this before?. Then use Search or SQL to get the exact evidence lines.
Opening the console
In the AWS Marketplace deployment, open the console at the UiUrl output of your CloudFormation stack, for example https://obsesc.your-domain.internal. The console is served by OBSESC itself, on the query port (18080). When you deploy the UI load balancer, it forwards to that port for you.
If your administrator turned on per-user sign-in (EnableUiPerUserRbac), you sign in with your organisation’s identity provider, and what you can see and do depends on your own role. See IAM and permissions for roles, and Network configuration to control who can reach the console.
Running a query in Explore
- Open Explore from the console navigation.
- In Query Settings, choose a Time range and, where you can, the Services you care about. These two settings reduce the amount of data read more than anything else.
- Write your SQL against the
raw_eventstable. See the SQL reference for columns and examples. - Select Run query (or press ⌘↵ / Ctrl+↵). Results appear below the editor, with a summary of how much data the query actually read.
Use Save query to keep a query for later. Saved Queries and Query History sit beside the editor so you can rerun earlier work.
Large queries ask for confirmation
Before a SQL statement reads any raw data, OBSESC works out a cautious upper limit on how much it could read. If that is more than your limit, the statement does not run. The console shows the expected size and asks you to confirm before it runs anything. By default, the limit is 100 GiB.
You can set a different limit for your own queries in Query Settings (Max scan (GiB) and Max scan (s)). Contact us if you need to change the default for your deployment.
The actual amount read is often much less than the upper limit, especially for queries with a LIMIT.
Tips for fast queries
- Always set a time range. Without one, the query covers all your data.
- Name a
servicewhenever you can. - Prefer exact matches, such as
attributes['k'] = 'v'orenv = 'prod'. - Add
LIMITwhile exploring. The query can then stop as soon as it has enough rows. - To answer “how many” or “what percentile”, start in Trends. It does not read raw data.
Counts and statistics without reading raw data
Trends and each service’s page in Services show event volume, distinct counts, percentiles and the most common values over any time range, and let you break them down by service and by field. They read OBSESC’s summaries, not your raw data, so they return quickly.
Distinct counts and percentiles are close estimates, suitable for dashboards and investigation. For an exact figure, use SQL in Explore.
Using SQL from your own tools
You can also run SQL over the query API with an API token. See the SQL reference and IAM and permissions.