We use cookies or similar technologies to personalize your online experience & tailor marketing to you. Many of our product features require cookies to function properly.

Read our privacy policy I accept cookies from this site

Beelines and OpenTelemetry

Honeycomb’s data ingest path supports several types of instrumentation, including two approaches specific to instrumenting code: Honeycomb’s Beelines and vendor-neutral OpenTelemetry. Both of these approaches generate the structured event data format that will help you get the most out of Honeycomb.

New to instrumenting code? Want to learn about structured events? Read more about instrumentation.

Beelines vs. OpenTelemetry  🔗

When Should I Use Beelines?  🔗

When Should I Use OpenTelemetry?  🔗

Paths to Getting Data into Honeycomb

What is the Honeycomb Roadmap?  🔗

As OpenTelemetry grows to embrace more languages, Honeycomb plans to continue to support OpenTelemetry; we see OpenTelemetry as a key component of our ability to support many programming languages and environments.

Mixed Environment  🔗

You don’t need to instrument all the services in your stack the same way. If one service is instrumented with OpenTelemetry and another with Beelines, you can still get trace visualizations that include them both! Some things to keep in mind:

Tracing Interoperability  🔗

Beeline instrumentations do not read and write the OpenTelemetry trace header, W3C Trace Context, by default. To enable trace interoperability between services instrumented with Beelines and OpenTelemetry, you will need to configure the Beeline to use the W3C header for trace propagation. Here’s an example of this configuration in the Go Beeline.

To learn more about ongoing development for W3C trace context propagation, visit the W3C Trace Context GitHub repository.

Field Name Differences  🔗

The names of fields differ on events produced by the Beeline instrumentations and the OpenTelemetry instrumentations. For example, the Beelines' service_name field has an equivalent of service.name in OpenTelemetry events. To use a single column for this value in queries for the name of a service, define a derived column in the dataset and use the COALESCE function to determine the name:

COALESCE($service.name, $service_name, "unknown")

Note: For Secure Tenancy customers, the COALESCE function is not available. Instead, use IF and EXISTS in the derived column definition:

IF( EXISTS($service.name), $service.name,
    EXISTS($service_name), $service_name,
    "unknown" )

Sampling  🔗

In order to achieve trace-aware sampling across a mixed environment, all instrumented services need to send data to Honeycomb via Refinery.

Questions and Support  🔗

Do you still have questions about OpenTelemetry and Honeycomb, or have a specific use case for your architecture? The Honeycomb Community Slack is a great place to ask your questions and share your experience–if you misplaced your invite, ask us on Intercom or email support@honeycomb.io and we’ll send you a new one.