A exporter backend that sends telemetry in the form of traces of your application's behaviour, or event data—accompanied either way by [conceivably very wide] additional metadata—to the Honeycomb observability service.

When specifying the honeycombExporter you have to specify certain command-line options and environment variables to enable it:

$ export HONEYCOMB_TEAM="62e3626a2cc34475adef4d799eca0407"
$ burger-service --telemetry=honeycomb --dataset=prod-restaurant-001

If you annotate your program with spans, you can get a trace like this:

This library by default will upload telemetry information to the default Honeycomb endpoint at 'api.honeycomb.io'. However, it also offers support for intermediate services (such as Honeycomb Refinery) when specifying a host explicitly, such as:

$ export HONEYCOMB_HOST=my-intermediate-service.internal

The library still assumes that the service is running on port 443 and behind SSL.

More details on Refinery: https://docs.honeycomb.io/manage-data-volume/refinery/

Notice

This library is Open Source but the Honeycomb service is not. Honeycomb offers a free tier which is quite suitable for individual use and small local applications. In the future you may be able to look at Core.Telemetry.General if you instead want to forward to a generic OpenTelemetry provider.

Gotchas

Spans are sent to Honeycomb as they are closed. Hence, if you have a long lived span, while its child spans are sent to Honeycomb and are displayed, the parent span will be initially missing.

This is of course jarring, because the parent is defined in the code before the section where the child is called. So when writing long lived services, it is best to call beginTrace inside a function that will iterate continuously. That way complete telemetry will be generated for that part of the code, making on-the-fly diagnosis and monitoring possible.

Either way, when the parent span is closed, unless the process is killed, the full trace will be visible.