In this section, we walk you through adding an integration, instrumenting your code, and verifying that your data arrives successfully in Honeycomb from your local dev environment. From there, you will be ready to deploy and start observing production!
To learn more about instrumentation, visit the About Instrumentation section of our docs.
In order to have the best experience with Honeycomb, you should have access to run, modify, and deploy source code for at least one app or service.
If your system is instrumented with OpenTelemetry, you can set the OTLP exporter to point to Honeycomb.
If a system is already instrumented with OpenTracing, OpenCensus, Zipkin, or Jaeger, check out our support for converting and exporting your data with the OpenTelemetry Collector.
To get the most out of Honeycomb’s features, we recommend instrumenting your code.
We recommend starting with OpenTelemetry for instrumenting any new service.
Honeycomb provides several official OpenTelemetry SDK distributions:
as well as documentation for using the vendor-neutral OpenTelemetry SDKs:
These options provide the most direct way to send OpenTelemetry data to Honeycomb.
If using a language that we do not support via a distribution or documentation, you can manually configure the OTLP exporter in your language’s SDK. Check the OpenTelemetry Registry for a wide variety of instrumentation SDKs.
Honeycomb supports receiving telemetry data via OpenTelemetry’s native protocol, OTLP, over gRPC, HTTP/protobuf, and HTTP/JSON. The minimum supported versions of OTLP protobuf definitions are 0.7.0 for traces and metrics.
Honeycomb also supports proprietary SDKs called Beelines. However, because Beelines are proprietary and pre-date OpenTelemetry, we recommend starting with OpenTelemetry if possible, and migrating to OpenTelemetry if you are using a Beeline today. You can read more about Beelines and OpenTelemetry.
Honeycomb has an endpoint that accepts raw JSON events over HTTP. To send events directly as JSON objects, use the Events API.
The format of these events is specific to Honeycomb and is not related to the OpenTelemetry OTLP format.
We also have native SDKs, called Libhoneys, which provide idiomatic methods for sending events to Honeycomb; they do not, however, contain native support for distributed traces or automatic instrumentation. These exist for Go, Ruby, Python, Java, and Node.js and Javascript.
There are also community-contributed Libhoneys for other languages.
While infrastructure usually cannot provide tracing data, it is still possible to get rich data into Honeycomb. If you have something in your infrastructure, we have probably already thought about the best way to get events from it into Honeycomb. Check out these integrations, which include AWS integrations for logs and metrics, curling data directly in, tailing a logfile, and Kubernetes support.
For Honeycomb Enterprise users with services hosted on AWS, we provide an AWS PrivateLink connection to the Honeycomb API.
Did you find what you were looking for?