# Search the logs, keep the trace

Logs arrive structured, with their resource attributes and their trace id intact. That means a search result is not a dead end — every line opens the request that wrote it.

## Severity, service and attribute, in one filter rail

Facets are computed from the rows actually in range, so the counts beside each severity are the counts you are about to see, not a stale summary.

- **signal**: logs
- **transport**: OTLP · no agent
- **severity**: TRACE · DEBUG · INFO · WARN · ERROR · FATAL
- **filters**: body · resource.* · log.*
- **joins.on**: trace_id · span_id
- **buckets**: 5 min

## What you can ask of a log line

### /logs?q= — Search the body and the attributes

Resource and log attributes are columns, not a blob. Filter on service.name, deployment.environment or your own keys the same way you filter on the message text.

### severity — Severity as meaning

The six OTel severity levels keep their own colour and their own facet. WARN and ERROR are one click apart, and neither is buried in a text match.

### trace_id — Open the trace behind the line

Any line carrying a trace id opens its request, positioned at the span that was running when the line was written.

### volume histogram — Volume before detail

The histogram above the results is stacked by severity, so a burst of ERROR at 14:20 is visible before you have read a single line.

### OTLP — Sent the way OTel defines it

Logs come in over OTLP alongside traces and metrics. No log-shipping agent, no second pipeline to keep alive, no separate retention to reason about.

## Related

- [Distributed Tracing](https://maple.dev/features/distributed-tracing.md)
- [Error Tracking](https://maple.dev/features/error-tracking.md)
- [Metrics & Dashboards](https://maple.dev/features/metrics-dashboards.md)
- [E-Commerce Observability](https://maple.dev/use-cases/ecommerce-observability.md)