Skip to main content
The Logs Explorer search box takes a query language rather than a plain keyword. It is the same syntax used for searching traces, so learning it once covers both surfaces.
Before you start. You need logs arriving from at least one service — see Send data with OpenTelemetry.

​
Free text

The simplest query is a bare word, which matches anywhere in the log body:
Two words are an implicit AND — both must be present:
Quote a phrase to match it exactly, rather than as separate words:

​
Field filters

Prefix a term with a field name and a colon to constrain it to that field:
Numeric fields support comparisons:
A trailing * matches a prefix, and field:* tests only that the field is present at all:

​
Booleans and grouping

AND, OR and NOT combine terms, and parentheses group them. - is a shorthand for NOT:
Putting it together — errors from the checkout service, excluding the noisy timeouts you have already triaged:

​
Fields you can filter on

Several fields have aliases; any of the listed names works. Any name not in that list is looked up in the log record’s attributes, which is how dotted OpenTelemetry attribute keys work:
An unrecognised field name is not an error. Because unknown names fall through to an attribute lookup, a typo like levle:error is a valid query — it searches for an attribute called levle and matches nothing. A query that unexpectedly returns zero results is worth re-reading for a misspelled field before concluding the data is missing.
Attribute keys are case-sensitive: service.name and Service.Name are different fields.

​
Time range and retention

The search box controls what matches; the time-range picker controls when. They are independent, and the most common reason a query that should match returns nothing is a time range that predates the data. Queries are also bounded by your plan’s retention period. Selecting a range that starts before it returns an explicit retention error rather than an empty result, so you can tell “we do not have this any more” apart from “nothing matched”.

​
Fuzzy full-text search

Alongside the Logs Explorer, the API exposes a separate log search endpoint backed by OpenSearch, which does fuzzy full-text matching over the log body. The two are genuinely different tools, and it is worth not confusing them:

Logs Explorer

Everything on this page. Exact. Supports fields, booleans and comparisons. Use it when you know what you are looking for.

Fuzzy search API

Tolerates typos and near-misses in the body text, but takes no field filters, booleans or comparisons. Use it when you are not sure of the exact wording.
The syntax on this page does not apply to the fuzzy endpoint — sending level:error there searches for the literal text level:error in the body.

​
Next

Turn a search into an alert

Alert when this query starts matching.

Send logs from another service

Add a second source.