honeycombio/beeline-ruby

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:

add_field "meta.span_type", span_type
&
def span_type
if root?
parent_id.nil? ? "root" : "subroot"
elsif children.empty?
"leaf"
else
"mid"
end
end

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.