Skip to main content
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.
If you are new to logs or want to understand how Honeycomb thinks about structured versus unstructured data, visit Traces, Metrics, and Logs.

​
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. 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. 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 to normalize them to Honeycomb’s expected levels.
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.

​
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.
OTel log support varies by language; check Send Logs from OpenTelemetry SDKs for current availability before getting started.

​
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.
Color-coding requires a field mapped to Logs: Severity in your dataset definitions. To learn more, visit Map Your Data.

​
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.

​
Next steps