Skip to main content
OpenTelemetry (OTel) is an open-source framework for collecting and exporting telemetry data, including traces, metrics, and logs, from your applications and infrastructure. It provides a standardized, vendor-agnostic way to instrument your code so that the telemetry you generate isn’t tied to any single observability tool. Honeycomb uses OpenTelemetry as its primary instrumentation standard. When you instrument your application with OTel, you can send that data to Honeycomb, and if you ever want to send it elsewhere, the same instrumentation works with any OTel-compatible backend.

​
How OpenTelemetry works

OpenTelemetry has two main components:
  • Instrumentation libraries: Language-specific SDKs and auto-instrumentation packages that you add to your application. They capture telemetry data as your code runs: function calls, HTTP requests, database queries, and more.
  • Exporters: Plugins that send the captured telemetry to a backend like Honeycomb over OpenTelemetry Protocol (OTLP), OTel’s native wire protocol.
When you instrument your application with an OTel SDK, it generates spans and traces that describe what your code did and how long it took. The exporter sends that data to Honeycomb, where you can query and visualize it.

​
Why Honeycomb uses OpenTelemetry

Honeycomb recommends OpenTelemetry for all new instrumentation because:
  • It’s vendor-agnostic. Your instrumentation isn’t tied to Honeycomb or any other vendor. You own your telemetry.
  • It’s the industry standard. OTel is maintained by the Cloud Native Computing Foundation (CNCF) and widely supported across the observability ecosystem.
  • It covers all three signals. A single OTel SDK can send traces, metrics, and logs from your application. You don’t need separate libraries for each signal type.
  • It’s future-proof. As OTel evolves and new semantic conventions emerge, your instrumentation stays current without requiring a full rewrite.

​
OpenTelemetry and Honeycomb’s data model

Honeycomb stores telemetry as events: structured records with fields and values. When OTel sends a span to Honeycomb, Honeycomb stores it as an event with fields like name, duration_ms, trace.trace_id, and service.name. You can query on any of these fields, group by them, and filter by them the same way you would with any other data in Honeycomb. Traces are collections of spans that share a trace.trace_id. Honeycomb uses the parent-child relationships between spans to render the trace waterfall view.

​
Already using OTel?

If your application already sends OTLP data, you can point your exporter at Honeycomb without changing your instrumentation. Visit OpenTelemetry configuration reference for the endpoint and authentication details.

​
Learn more