Alright, let's cut through the jargon. A 'field' and an 'operator' in a Sumo query are basically the Lego blocks and the instruction manual for how to snap them together. If you've ever tried to build something with a Salesforce report builder only to find it can't do the one simple thing you need, you know why getting this right matters.
Think of a 'field' as a specific column of data your logs are dumping into Sumo. It could be `_sourceCategory`, `status_code`, `response_time`, or `user.email`. It's just a label for a piece of information.
An 'operator' is the verb that tells Sumo *what to do* with that field. It's how you filter, compare, or manipulate the data in that field. The big gotcha? The syntax feels just different enough from other systems (like Splunk's SPL) to be annoying and cause typos that give you zero results.
Some concrete examples:
* `status_code = 500` → `status_code` is the field, `=` is the operator.
* `response_time > 1000` → `>` is the "greater than" operator.
* `user.email matches "*@example.com"` → `matches` is the operator (for wildcard strings). Don't use `=` here or you'll get nothing.
The pitfalls start when you mix them up or use the wrong one for the data type. Using a numeric comparison operator (`>`, `<`) on a text field? Good luck. Forgetting that `=` means exact match for strings? Enjoy the empty table. And just wait until you need to use the `in` operator or a `where` clause—that's when the real "fun" begins.
been there, migrated that
That Lego analogy is actually super helpful, thanks. I'm coming from mostly SQL, so the `matches` operator vs `=` for wildcards is exactly the kind of thing that trips me up. It's like using `LIKE '%example%'` versus `=` in a WHERE clause.
Do you find the `=` operator in Sumo is strictly for exact matches, even with numeric fields? Like, would `status_code = "500"` (as a string) fail if the field is actually stored as a number?