Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Span Events #66

Closed
ajvondrak opened this issue Jan 27, 2020 · 2 comments
Closed

Span Events #66

ajvondrak opened this issue Jan 27, 2020 · 2 comments

Comments

@ajvondrak
Copy link
Contributor

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. 😇

@ajvondrak
Copy link
Contributor Author

ajvondrak commented Jan 27, 2020

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).

@vreynolds
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants