Skip to content

Conversation

@lobsterkatie
Copy link
Member

@lobsterkatie lobsterkatie commented Nov 26, 2024

This adds a tally of the four possible types of frames (in-app vs system, each of which can be contributing or not) to exception and chained exception grouping components created by the newstyle config. To make this work:

  • First, each FrameGroupingComponent stores on itself whether it's in-app or not.*
  • Then, as we're walking through the frames when building the StacktraceGroupingComponent, we note each frame component's in_app and contributing values, and keep a running tally of the different frame types, which we then store on the stacktrace component.
  • Next, when creating an ExceptionGroupingComponent, we read the frame tally from the stacktrace component and store it on the exception component.
  • Finally, if we have a chained exception, we add up the tallies from the individual exception components and store a combined tally on the ChainedExceptionGroupingComponent.

Having this data will enable us to do a few different things (in follow-up PRs, if and when we choose to):

  • Gather metrics on the precise mix of frames. Right now we have a separately-calculated in_app_frame_mix metric, which just records the presence, or lack thereof, of in-app and system frames in the initial event in a group; should we choose, this will allow us to gather more detailed metrics. (One place this might be useful is as we start automatically adding code-mappings-based stacktrace rules to projects, to see the change in percentage of in-app vs system frame.) We also could consider switching the frame mix metric to rely on these counts, as it would make the code quite a bit simpler.
  • Store this information in grouphash metadata.
  • Use the information when deciding whether to send events to Seer.

*Note: Though in general this PR only applies to newstyle grouping, I did add in-app tracking to legacy frame components, too, to make them compatible with the newly-modified assemble_stacktrace_component helper both configs use.

@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Nov 26, 2024
@codecov
Copy link

codecov bot commented Nov 26, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

✅ All tests successful. No failed tests found.

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #81341   +/-   ##
=======================================
  Coverage   80.35%   80.35%           
=======================================
  Files        7219     7219           
  Lines      319608   319635   +27     
  Branches    20770    20770           
=======================================
+ Hits       256819   256846   +27     
  Misses      62395    62395           
  Partials      394      394           

@lobsterkatie lobsterkatie force-pushed the kmclb-tally-frame-types-on-exception-grouping-components branch from 319dddb to bc453dc Compare November 27, 2024 08:25
@lobsterkatie lobsterkatie marked this pull request as ready for review November 27, 2024 16:39
@lobsterkatie lobsterkatie requested a review from a team as a code owner November 27, 2024 16:39
@lobsterkatie lobsterkatie merged commit 32350ea into master Nov 27, 2024
50 checks passed
@lobsterkatie lobsterkatie deleted the kmclb-tally-frame-types-on-exception-grouping-components branch November 27, 2024 21:36
jan-auer added a commit that referenced this pull request Nov 28, 2024
* master: (219 commits)
  fix: flatten searchable os distribution fields (#81297)
  chore(profiling): Remvoe unused profile functions metrics hook (#81396)
  fix(prompts): Properly return false instead of undefined when prompt data is null (#81404)
  fix(insights): broken screen rendering doc link (#81257)
  fix(rpc): Only groupby when needed (#81403)
  feat(grouping): Tally frame types while building exception grouping components (#81341)
  fix(similarity): Limit > 30 system frame check to Java (#81385)
  feat(alerts): Adds EAP spans results consumer configs (#81365)
  ref(insights): simplify domain view header by using tab links (#81324)
  fix(issues): Add projectId for flag onboarding on click (#81387)
  chore(flamegraphs): Remove unused legacy flamegraph code path (#81381)
  fix(performance): No table overflow + glitchy behaviour (#81378)
  feat(widget-builder): Add feature flag for redesign (#81377)
  feat(profiling): Clean up continuous profiling ui and compat flags (#81260)
  feat(visibility): Clamp date range for `TagStore` queries (#81363)
  test(taskbroker): Add CLI command for sending taskbroker tasks (#81319)
  feat(dashboards): Add ff for favouriting dashboards (#81368)
  fix(trace) match event_id by error (#81370)
  fix(insights): add missing slash on performance moving banner (#81364)
  ref(models): Include event id in `Event` repr (#81345)
  ...
andrewshie-sentry pushed a commit that referenced this pull request Dec 2, 2024
…omponents (#81341)

This adds a tally of the four possible types of frames (in-app vs system, each of which can be contributing or not) to exception and chained exception grouping components created by the newstyle config. To make this work:

- First, each `FrameGroupingComponent` stores on itself whether it's in-app or not.*
- Then, as we're walking through the frames when building the `StacktraceGroupingComponent`, we note each frame component's `in_app` and `contributing` values, and keep a running tally of the different frame types, which we then store on the stacktrace component.
- Next, when creating an `ExceptionGroupingComponent`, we read the frame tally from the stacktrace component and store it on the exception component.
- Finally, if we have a chained exception, we add up the tallies from the individual exception components and store a combined tally on the `ChainedExceptionGroupingComponent`.

Having this data will enable us to do a few different things (in follow-up PRs, if and when we choose to):

- Gather metrics on the precise mix of frames. Right now we have a separately-calculated `in_app_frame_mix` metric, which just records the presence, or lack thereof, of in-app and system frames in the initial event in a group; should we choose, this will allow us to gather more detailed metrics. (One place this might be useful is as we start automatically adding code-mappings-based stacktrace rules to projects, to see the change in percentage of in-app vs system frame.) We also could consider switching the frame mix metric to rely on these counts, as it would make the code quite a bit simpler.
- Store this information in grouphash metadata.
- Use the information when deciding whether to send events to Seer.

*Note: Though in general this PR only applies to newstyle grouping, I did add in-app tracking to legacy frame components, too, to make them compatible with the newly-modified `assemble_stacktrace_component` helper both configs use.
@github-actions github-actions bot locked and limited conversation to collaborators Dec 13, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants