Span Events
Closed this issue · 2 comments
I'm interested in trying to use the concept of span events, which requires setting the meta.span_type
to "span_event"
. As a first crack, I might try and repurpose a Honeycomb::Span
like:
Honeycomb.start_span(name: 'event') do |span|
span.add_field('meta.span_type', 'span_event')
span.add_field('interesting', 'banana')
end
However, Honeycomb::Span#send_internal
always clobbers the span type:
beeline-ruby/lib/honeycomb/span.rb
Line 98 in 4713124
beeline-ruby/lib/honeycomb/span.rb
Lines 133 to 141 in 4713124
Plus Honeycomb::Span
is going to include fields that don't make sense for span events.
So of course, rather than bolt this onto the wrong data type, I propose there should be a new class, Honeycomb::SpanEvent
. This could work much like Honeycomb::Span
, but doesn't need things like duration_ms
or children (right?). But it still needs things like the sampling hook, for example.
Since span events are single point-in-time structured logs, I think the API for generating them could be something as simple as:
module Honeycomb
class Span
# Sends a span event with the given fields.
# @param fields [Hash] values for the fields of this span event
# @return [void]
def add_event(fields)
span_event = Honeycomb::SpanEvent.new(
trace: trace,
builder: builder,
context: context,
parent_id: id,
sample_hook: sample_hook,
presend_hook: presend_hook,
)
fields.each do |field, value|
span_event.add_field(field, value)
end
span_event.send
end
end
end
Then Honeycomb::Client#add_event
(delegated to by Honeycomb.add_event
) would forward to the current span.
I'd PR this, but I can't work on it right at the moment, and it seems like it would get hairy threading through the current Trace
/Span
/Context
jenga (does it make sense to maybe have class SpanEvent < Span
and treat it mostly like any other span? 🤔). So I'm noting the idea / feature request for posterity. 😇
P.S.: in the interim, this might be another good chance to use Libhoney
directly, if the beeline gave access (like I've previously campaigned for).
Hello,
We will be closing this issue as it is a low priority for us. It is unlikely that we'll ever get to it, and so we'd like to set expectations accordingly.
As we enter 2022 Q1, we are trimming our OSS backlog. This is so that we can focus better on areas that are more aligned with the OpenTelemetry-focused direction of telemetry ingest for Honeycomb.
If this issue is important to you, please feel free to ping here and we can discuss/re-open.