Baggage span processor - key predicate

[MikeGoldsmith]

This issue is to track adding a method of selecting what baggage key entries should be copied.

Feedback in the JS contrib PR was to allow a user-provided predicate function. This puts the responsibility on the user to ensure sensitive baggage keys are not copied while also not prescribing how that is determined.

• Baggage span processor - key predicate opentelemetry-js-contrib#2166

          > What about making the baggage items that are added as spans tags configurable, with the option to provide `*` for all - like here: https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/355003538a4dcf7ec58b6d9be42086c53238bdac/instrumentation/log4j/log4j-appender-2.17/library/README.md?plain=1#L101
  

We had a similar feedback in the .NET contrib project but thought it was more complicated than just using a set of prefixes so created an issue to continue the discussion. The plain processor that copies all baggage entries (like using * in your example) is likely to be accepted first.

• Baggage activity processor - key predicate opentelemetry-dotnet-contrib#1695

[robbkidd]

I am wary of adding too much to the new processor while the proposal to add this type of functionality is still winding its way through committee.

The BaggageSpanProcessor is currently simple. It's core—and really only—business logic is two lines of code: a guard and the additions.

class BaggageSpanProcessor
  def on_start(span, parent_context)
    return unless span.respond_to?(:add_attributes) && parent_context.is_a?(::OpenTelemetry::Context)

    span.add_attributes(::OpenTelemetry::Baggage.values(context: parent_context))
  end
  # ...
end

As an alternative to adding configuration complexity to this new contrib library, developers/operators interested in customizing which keys from baggage get duplicated as attributes onto spans can add their own span processor to their applications. Something (wholly untested by me) like:

module AcmeO11yWrapper
  class BaggageSpanProcessor

    ALLOWED_PREFIX = 'acme.'

    def on_start(span, parent_context)
      return unless span.respond_to?(:add_attributes) && parent_context.is_a?(::OpenTelemetry::Context)

      span.add_attributes(
        ::OpenTelemetry::Baggage
          .values(context: parent_context)
          .select { |k, _v| k.start_with? ALLOWED_PREFIX }
      )
    end
    # ...
  end
end

⚠️ The more work a span processor does on_start(), the more compute resources are needed every time a span is created.

[MikeGoldsmith]

I think the proposed context-scoped attributes would supersede this processor. I don't think you'd need to run both alongside each other. However, that proposal was seems to have stalled at the moment and may by some time before it accepted.

The want to limit the keys that are copied is real and this enhancement helps solve the issue until context-scoped attributes are available.

Agreed more work in on_start consumes compute resource but this is an opt-in processor and the user is in control of what prefixes they configure. They are in-charge of their own destiny. We can also add an extra warning to the processor to indicate more prefixes is more compute time.

[github-actions]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.