Logs Search Syntax

Every filter you build by checking a sidebar value, and every query you type directly, compiles to the same search-bar syntax. This page is the full operator reference; see Explorer layout for how the search bar fits into the rest of the screen.

This search-bar syntax is the pre-pipe (filtering) half of FuseQL, Kloudfuse’s query language. Everything on this page works unchanged after a | in a FuseQL query — see Logs Analytics for the post-pipe aggregation syntax, and Comparison operators, Text search operators, and Logical operators for the full operator reference with every function’s syntax, parameters, and examples.

Operators

The search bar’s own autocomplete shows this table when you start typing — type a field name to see it. msg and path below stand in for any field name; substitute your own.

Syntax Meaning

level=error

Equals

level!=debug

Not equals

msg=~"timeout.*"

Regex match

msg!~"health.*"

Regex exclude

path*~"/api"

Starts with

msg**"error"

Contains

path~*".json"

Ends with

@status=="404"

Facet terms exist (facet equals, quoted)

duration>500ms

Greater than

duration>=1s

Greater than or equal

bytes<1024

Less than

bytes⇐2048

Less than or equal

level="A OR B"

Union — matches either value

@status:number

Key exists

!@status:number

Key absent

'error'

Term search — matches the whole word error anywhere in the message

"error text"

Substring search (grep) — matches the exact phrase

!'error'

Exclude term

!"error text"

Exclude substring (not-grep)

Term search vs. field filters

A single-quoted word ('error') is a term search — it looks up a whole word in an index built from the message at ingest time, the same way a search engine matches words in a document. A double-quoted phrase ("connection refused") is a substring search (grep) — it scans the reconstructed message text for that exact, case-sensitive sequence of characters instead. A field=value expression is a field filter — it matches an indexed label or facet exactly, regardless of how the message text is worded.

Field filters are cheaper to evaluate, because the Logs Store already has every label and facet indexed — see How a search reaches the data. Prefer them over a term search whenever the value you’re looking for is already available as a field (level=error instead of the term 'error'; kube_namespace=payments instead of the term 'payments'), and reserve term/substring/regex search for text that only exists in the free-form part of the message.

Facets vs. labels in a query

Both facets and labels are field=value filters — the difference is in the field name, not the syntax. A facet (something Kloudfuse extracted from the message) is referenced with an @ prefix — @status==500; a label (attached at collection time — kube_namespace, level, source, and so on) is referenced by its bare name — kube_namespace=payments. See Facets, labels, and tags for what determines which one a given field is.

Combining filters

Type more than one filter separated by a space to AND them together:

level=error kube_namespace=payments "connection refused"

This matches logs where the level is error, and the namespace is payments, and the message contains the phrase "connection refused". Use the union syntax (level="A OR B") within a single field when you want an OR across values of that one field; combine that with other space-separated filters to AND it with the rest of the query.

Builder vs. Code

The search bar has two modes, switched at its left edge:

Builder

The default. Autocompletes field names as you type, shows the operator reference above, and keeps the search bar in sync with the sidebar’s checked values.

Code

A raw FuseQL query editor with a Run button, for queries more complex than the Builder is meant for — see Logs Analytics for the aggregation syntax (count by, roll up every, formulas) used in the analytics views.

How term search tokenizes a message

A term search doesn’t require an exact substring match the way a quoted phrase does — it looks up whole tokens in an index built at ingest time, rather than scanning message text. For the precise tokenization rule (what counts as a token, which characters are boundaries, case sensitivity) and worked examples, see Term search in the FuseQL reference — it covers this in more depth than duplicated here. When you need an exact, uninterrupted phrase instead of a token match, use a quoted substring search ("connection refused") or a regex (msg=~"connection refused").