rewrite focusing on telemetry

[the-mikedavis]

phoenix emits a telemetry event when it finishes a run with a conn and on that telemetry event is the conn and duration (exactly what we need)

so this PR changes the Hummingbird plug to solely determine trace IDs and put them into conn.private.hummingbird along with other metadata

when the telemetry event comes along, it'll trigger a telemetry handler Hummingbird.Telemetry (put that in your application sup tree) which will handle the sending of events to honeycomb and grabbing of metadata from the conn

a few other things:

• a helper function for all b3 headers (for use in in-app requests)
• respect the b3 sampled header (determines whether or not you should emit an event to honeycomb)
• set aside a field called events: [] in conn.private.hummingbird
  • this should work nicely in the future when we want to add more events to a batch, like database requests or other functions

[tonyvanriet]

that's a lot...
i approve

[bjornrud]

@the-mikedavis Only real concern here is that Defer sampling is done by absence of this header. 0 is deny and that seems ham-handed.

It makese sense to me to have each app have ownership of how it wants to set sampling or nah, especially since it should be able to trace according to its own rules. If it wants to make another trace, and link the two traces, that's its perogative.

[the-mikedavis]

yeah this header is just for the test though. there's another line somewhere setting the default when deferred to be true or "1" but I agree that should be configurable on a per app basis. something like config :hummingbird, sample_when_deferred: true|false

[bjornrud]

🤦 my bad

[the-mikedavis]

#22 made a little issue for it here