Skip to main content
An index holds your logs and defines a schema that determines how each field is stored and queried. When you attach an existing Quickwit instance, its indexes appear in Rootprint automatically.

Built-in OpenTelemetry index

Rootprint ships with otel-logs-v0_9, the OpenTelemetry logs index bundled with Quickwit 0.9.1. Its schema maps directly to the OpenTelemetry Log Data Model. Rootprint’s default field-role mappings match it, so it works without configuration.

Schema

The index uses strict mode: Quickwit rejects any document with a top-level field outside the schema. Omitted fields are allowed. Put custom key-value data in the attributes, resource_attributes, or scope_attributes JSON fields. When you use an OpenTelemetry collector, Quickwit maps fields automatically. In the Search columns below, indexed fields are searchable and fast fields support range queries, aggregations, and sorting. See Indexed, stored, and fast. For how the raw and default tokenizers match, see Tokenizers and case sensitivity.

Core fields

These fields carry the primary log data.

Attributes

Key-value metadata on the log event and its resource.

Trace context

A log carrying trace_id opens its trace. See Read a trace. If your custom schema keeps the trace ID elsewhere, set the index’s Trace ID field. See Correlate logs with traces.

Instrumentation scope

Metadata about the library that produced the log. Stored only: visible in results, not searchable.

Example payload

Custom indexes

For non-OpenTelemetry data (audit trails, custom application events, third-party log formats), create an index with the schema your data needs. See Create a custom index for the Create-index form: field types, tokenizers, and retention policy. Once it exists, configure how Rootprint maps its fields from the index’s Configuration tab.

Next steps