Interoperability with Honeycomb beelines?

[fiadliel]

I'm interested in this being interoperable with Honeycomb (Beeline) integrations for other languages, and wanted to check if this was of interest:

Historically Honeycomb used an X-Honeycomb-Trace header, encoding trace ID, span ID, and some attached context. Recent updates have made it possible to also read traces using the W3C Trace Context headers. The outgoing headers still default to using the Honeycomb header, but there are plans to make this configurable.

In line with the above, the new default generated trace ID is a 128-bit identifier, and the span ID is a 64-bit identifier. These are encoded in a hexadecimal representation on the wire (so can be represented by text). This change is so that trace/span IDs can be compatible with both tracing systems.

eg: honeycombio/beeline-go#113 and honeycombio/beeline-go#110

Possible improvements:

1. Change trace and span IDs to String type, and generate IDs compatible with W3C
2. Support X-Honeycomb-Trace header format
3. Support W3C trace header format (actually I'm hoping to use this format, as it makes it much easier to interoperate with other services that don't directly support Honeycomb)
4. Some Beeline implementations also now support AWS X-Ray headers inbound, but I don't really care about it 😄
5. It would be nice to be able to configure which serialization is used for inbound or outbound requests, but not clear if that should be in this library, or in http4s integration.

[tpolecat]

Hi Gary, sorry for the delay. This all seems reasonable to me. Back when I wrote this part there was no specification for any of this so I just made it up.