> ## Documentation Index
> Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Logs in Honeycomb

> Learn how Honeycomb handles log data, how to get the most out of structured and unstructured logs, and how logs fit alongside your traces and metrics.

Honeycomb supports all three OpenTelemetry (OTel) signals: traces, logs, and metrics.
Whether you are starting with raw, unstructured logs or fully structured OTel output, Honeycomb can work with what you have, and your data becomes more powerful as you add structure over time.

<Tip>
  If you are new to logs or want to understand how Honeycomb thinks about structured versus unstructured data, visit [Traces, Metrics, and Logs](/get-started/honeycomb/traces-metrics-logs/).
</Tip>

## How logs work in Honeycomb

Honeycomb stores and queries logs alongside traces and metrics, using the same event-based data model.

### Logs as events

Honeycomb stores logs as events, the same foundational unit as trace spans.
A structured log maps naturally to a Honeycomb event: its fields become event fields, automatically indexed and immediately available in the Query Builder.

### Starting with unstructured logs

Honeycomb works with unstructured logs, and you can add structure incrementally.

* **For application logs:** [Configure an OTel SDK](/send-data/logs/opentelemetry/sdk) to wrap your existing log output and send it to Honeycomb as structured events.
* **For infrastructure or file-based logs:** [Configure the OpenTelemetry Collector to parse fields before ingestion](/send-data/logs/unstructured/collector).
* **After the fact:** [Use calculated fields to extract structure](/send-data/standardize/transform-data#parsing-unstructured-logs).

The more fields you add to your logs over time, the more of Honeycomb's query capabilities become available to you.

### Log dataset identification

Honeycomb treats a dataset as a log dataset when it includes a log message field: typically the OpenTelemetry `body` field, or a field you map to `Logs: Message` in your [dataset definitions](/configure/datasets/definitions).
That enables the Logs view on Honeycomb Home, which surfaces log volume, error and warning counts, severity breakdowns, and top messages without requiring you to build those queries manually.

To populate severity charts and color-coded log lines, also send a `severity` field or map a field to `Logs: Severity`.
If your severity values are non-standard, use [calculated fields](/send-data/standardize/transform-data) to normalize them to Honeycomb's expected levels.

<Note>
  Log datasets are typically kept separate from trace datasets, both for organizational clarity and so that Honeycomb can apply the appropriate Home visualizations for each signal type.
</Note>

## Log-trace correlation

One of the strongest reasons to send application logs via OTel is automatic correlation with traces (infrastructure and file-based logs can be sent to Honeycomb and queried, but don't automatically carry trace context).
When your application is configured with both an OTel log exporter and OTel tracing, logs emitted within the context of a request are automatically tagged with the trace ID and span ID for that request.

This makes OTel logs a useful starting point for teams who aren't yet on traces.
You can send your existing structured application logs to Honeycomb via OpenTelemetry and get queryable, high-cardinality log data immediately.
When you add tracing later, those logs become linked to the traces they belong to.
You usually don't need to change how you emit log lines; adding tracing attaches trace context to logs you are already sending.
You can build toward fuller observability incrementally, at whatever pace works for your team.

<Note>
  OTel log support varies by language; check [Send Logs from OpenTelemetry SDKs](/send-data/logs/opentelemetry/sdk) for current availability before getting started.
</Note>

## How to query logs

Querying logs in Honeycomb works the same way as querying any other data.
Use the Query Builder to filter by severity, group by message, aggregate counts over time, or identify outliers with BubbleUp.

A few patterns are particularly useful for log data:

* **Filter by severity** to focus on errors or warnings: `WHERE severity = error`
* **Group by your log message field** (typically `body`) to find which log messages occur most frequently
* **Use HEATMAP on a parsed numeric field**, such as a response time extracted from a log line, to visualize distribution over time
* **Use BubbleUp** on a spike in log volume to surface which field values are most common in that window compared to the baseline

The **Explore Events** view presents log data in a format optimized for scanning, with color-coding by severity level.

<Tip>
  Color-coding requires a field mapped to `Logs: Severity` in your dataset definitions.
  To learn more, visit [Map Your Data](/send-data/standardize/map-data).
</Tip>

## How logs work with traces and metrics

Logs, traces, and metrics are complementary signals.
In practice, you will often use all three together:

* A **metrics alert** surfaces a problem: error rate is elevated.
* A **log query** narrows the scope: these specific error messages are occurring most frequently.
* A **trace investigation** explains the cause: this is where in the request execution the error originates.

When logs carry trace context, you can navigate from a log event to its corresponding trace; logs and traces typically live in separate datasets, connected by their shared trace ID.

## Logs and your plan

Log data is measured in events per month (EPM) and counts against your event allotment alongside trace data.
To learn how Honeycomb measures usage, visit [How Honeycomb Calculates Usage](/get-started/manage-costs/how-honeycomb-calculates-usage).

## Next steps

* [Send Logs from OpenTelemetry SDKs](/send-data/logs/opentelemetry/sdk): Send structured application logs from your code, correlated with your traces.
* [Send Logs with the OTel Collector](/send-data/logs/unstructured/collector): Parse and forward infrastructure and file-based logs to Honeycomb.
* [Investigate Log Data in Honeycomb](/investigate/debug/log-data-in-honeycomb): Query, visualize, and debug your log data once it is in Honeycomb.
* [Map Your Data](/send-data/standardize/map-data): Map your field names to Honeycomb standard fields to enable log severity color-coding and Home visualizations.