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:Field filters
Prefix a term with a field name and a colon to constrain it to that field:severity_number is the numeric
field — 17 is ERROR and above in the OpenTelemetry severity scale:
duration_ms and duration_ns are the numeric fields:
* 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:
Fields you can filter on
Several fields have aliases; any of the listed names works.
The container and Kubernetes fields are the ones worth knowing about: they are
what takes you from a pod in the Kubernetes view to that pod’s log lines.
k8sattributes processor does. Without it the
columns are empty and a filter on them matches nothing. See
Send data from Kubernetes.
The same field names work on traces, which is the point of one query language
across signals. Traces additionally accept name (aliased operation), kind,
status (aliased status_code), duration_ms, duration_ns and
parent_span_id; they have no level or body.
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.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
Status: implemented, not currently exposed. A separate fuzzy log-search
endpoint exists in the API service, backed by the full-text index rather than
the analytical store. It is served at
/search/logs — outside the /api/
prefix — and the reverse proxy in front of every deployment does not route that
prefix, so a request to it reaches the dashboard and comes back as HTML rather
than results.It is documented here because it appears in the generated API reference and
someone will find it. Do not build against it until the path is routed; the
Logs Explorer covers everything on this page today.Logs Explorer
Everything on this page. Exact. Supports fields, booleans and
comparisons. Use it when you know what you are looking for.
Fuzzy search
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.
Next
Turn a search into an alert
Alert when this query starts matching.
Send logs from another service
Add a second source.