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’ll 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 a system is already instrumented with OpenTracing, OpenCensus, Zipkin, or Jaeger, check out our support for the OpenTelemetry Collector.
Custom code—the logic that most directly impacts your business—is often the most interesting code to observe. To get the most out of Honeycomb’s features, we recommend instrumenting your code.
Depending on your choice of languages, a Honeycomb Beeline or an OpenTelemetry instrumentation may be more appropriate for you.
Honeycomb supports OpenTelemetry’s native protocol, OTLP, over gRPC. There are a wide variety of instrumentations for OpenTelemetry at the OpenTelemetry Registry, including .NET. Learn more at the OpenTelemetry Collector.
Honeycomb has an endpoint that accepts raw json events over http. To send events directly as JSON objects, use the events API.
We also have native SDKs, called “LibHoney”, which provide idiomatic methods for sending events to Honeycomb; they do not, however, contain native support for distributed traces or automatic instrumentation.
While infrastructure usually can’t provide tracing data, its 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, including curling data directly in, tailing a logfile, and Kubernetes support.