Skip to content

Add ignoreSpans option #16820

Closed
Closed

Description

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

Activity

  1. Lms24 commented on Jul 7, 2025

    @Lms24
    Member

    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?

  2. s1gr1d commented on Jul 7, 2025

    @s1gr1d
    Member

    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.

  3. mydea commented on Jul 7, 2025

    @mydea
    MemberAuthor

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

  4. mydea commented on Jul 9, 2025

    @mydea
    MemberAuthor

    ref: https://develop.sentry.dev/sdk/telemetry/spans/filtering/#filter-with-ignorespans --> we should also update if we adjust things here, possibly.

  5. self-assigned this
    on Jul 18, 2025
  6. assigned and unassigned on Jul 28, 2025
  7. added a commit that references this issue on Jul 30, 2025
  8. arielweinberger commented on Aug 1, 2025

    @arielweinberger

    desperately need this!

  9. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Aug 1, 2025
  10. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Aug 1, 2025
  11. Lms24 commented on Aug 4, 2025

    @Lms24
    Member

    @arielweinberger expect this to be released in the next days. I just merged the PR. (A GH bot will comment under this issue once it is released).

  12. github-actions commented on Aug 6, 2025

    @github-actions
    Contributor

    A PR closing this issue has just been released 🚀

    This issue was referenced by PR #17078, which was included in the 10.2.0 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions