Suppress all gRPC Span Events; suppress all Span Events

[fujin]

Is your feature request related to a problem? Please describe.
My distributed tracing vendor quota is consumed by span events attached to my spans (e.g. for both the span, and each event as an "event" - we have X events per month).

Describe the solution you'd like
I would like to suppress the span events in the gRPC instrumentation. I might also like to suppress all auto-instrumented span events globally or enable them on a case-by-case basis.

Describe alternatives you've considered

• Dropping span events with experimental/closed PR Span event filter  opentelemetry-collector-contrib#5716
• Testing experimental transform processor described here New component: Span Event Filter Processor opentelemetry-collector-contrib#7151 (comment) gregoryfranklin/opentelemetry-collector-contrib@cc4adfb
• Disabling gRPC instrumentation

[trask]

hi @fujin, one way to do this would be in a Java agent extension using a wrapping SpanExporter, registered via https://github.com/open-telemetry/opentelemetry-java/blob/bebf684436b0f54c0c81b19eba1dd9d12ff37532/sdk-extensions/autoconfigure-spi/src/main/java/io/opentelemetry/sdk/autoconfigure/spi/AutoConfigurationCustomizer.java#L61

[fujin]

Yeah, we certainly could build one and package our own image+extension for usage with opentelemetry operator instrumentation injection. However, I would still prefer to disable by default / disable all span events without any additional work.

I ended up using a filter:

      filter/ottl:
        traces:
          spanevent:
            - 'name == "message"'
            - 'name == "ss"'
            - 'name == "cr"'

[trask]

I would still prefer to disable by default / disable all span events without any additional work

is this not possible using the opentelemetry collector spanevent filter?

[fujin]

Yes of course, that's the filter that I mentioned in my previous reply; well, I am currently specifying each one to drop (by name). I would still prefer to not emit them by default/globally rather than discover a new one and filter it (potentially after eating event budget at my tracing vendor).

[trask]

I think it would be worth making this request in the collector-contrib repo where that spanevent filter is maintained

[fujin]

hmm.. I'm not sure that I agree. Two different problems/solutions, no?

The code in this repository is responsible for emitting the span events that I would like my collector not to receive.

The collector configuration that filters those events is acceptable to us but doesn't allowing control over if they're emitted in the first place (without disabling that instrumentation library wholesale). I'd like to keep the instrumentation library, but not the events, without having to rely on a filter. I'm fine with closing it, but I would not say those are the same.

[trask]

This is being worked on at the specification level now through a combination of

• https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0265-event-vision.md
• Add scope configuration properties opentelemetry-configuration#140
• OTEP: Logger.Enabled opentelemetry-specification#4290

(and some followups will be needed still)