Add `ignoreSpans` option

[mydea]

Description

We have the recurring request to be able to ignore certain spans. We removed the option to use beforeSendSpan to allow dropping spans, because it can break metric extrapolation when using non-deterministic code to drop spans.

The replacement for this has been to configure specific integrations to drop spans. While this works, it has a few problems:

1. It can be hard to know where/how to configure integrations. Option names can differ, and you may have to configure a whole bunch of integrations to make this work as you want.
2. Some integrations do not have options to drop stuff. While we can add things in general, esp. with OpenTelemetry it can be hard because we require upstream changes.

In order to help alleviate this, we should add a ignoreSpans option that can be used to filter spans at creation time:

type IgnoreSpansFilter = 
{
  name: string | RegExp,
  op: string | RegExp,
} | 
{
  name: string | RegExp
} | 
{
  op: string | RegExp
}

interface Options {
  // ...
  ignoreSpans: (string | RegExp | IgnoreSpansFilter)[]
}

This will match against the span name at creation time, and make the span non-recording if it matches.

Important notes:

• On browser, this should work reasonably well, as we emit all the spans and they usually have the correct span name at span creation time. Important exception: pageload spans often get updated, they may not have the correct span name at creation time.
• On node, we need to infer the name at creation time, which is a bit more expensive, resource wise. This is an opt-in option though, we just need to make it clear there may be a performance overhead with this. Also, in node span names can often be updated later, this also needs to be documented well.
• We need to document well that ignoring a span like this will also drop child spans of this span. So this should ideally mostly be used for leaf nodes.

This function will be run in the place where we also run beforeSendSpan, so after processing. If possible, we will re-stitch parent-child relationships of spans that are dropped there.

[Lms24]

I think the span name alone might be a bit too generic in some cases. For example, let's say I want to filter out all http.client GET spans and I define a regex like this: ignoreSpans: [/GET .*/]. Now, if I throw this into the server-side config, it will also cause all http.server spans to be ignored because they also happen to start with GET. Meaning, we wouldn't emit any span server-side anymore. This might cause unintentional behaviour.

Sure, we can say that this is on users, to figure out a regex that's smart enough but I'd argue for this specific case, it's actually quite hard to do so. Even if I further refine the regex to ignoreSpans: [/GET api\/v0\/.*/], I would still likely ignore the http.server counterparts unintentionally.

I agree though that we probably want an API like this in some way. One idea I'd have is to also include op in the filter, and for ease of use make it an optional property:

type IgnoreSpansFilter = 
{
  name: string | RegExp,
  op: string | RegExp,
} | 
{
  name: string | RegExp
} | 
{
  op: string | RegExp
}

{
  ignoreSpans: (string | RegExp | IgnoreSpansFilter)[]
}

A type like this would also allow for ignoring

• all spans matching a specific name (generic, as before)
• all spans matching a specific op (generic, new)
• all spans matching a specific name and op combination (more specific)

This won't solve the too generic filterinrg by only specifying a string|RegExp, but by setting the name/op combination, users have a way to narrow things down significantly.

AFAIK, we infer name and op at the same time in Node, so the same resource and performance concerns would exist as with the intially proposed API. WDYT?

[s1gr1d]

I second your type proposal as it would be a bit too generic to just add a string/regex. However, in terms of simplicity, I would change the type to this:

{
  ignoreSpans: IgnoreSpansFilter[]
}

So a single string/regex is not allowed, and it gets more obvious if you are filtering by op or name.

[mydea]

makes sense to me! Your example is very reasonable, and op should be OK to check, overhead wise 👍