[CLEAN] Synthetic Benchmark PR #103875 - feat(explorer): rpcs for getting log/metric attrs for a trace id + substring #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Benchmark PR getsentry#103875
Type: Clean (correct implementation)
Original PR Title: feat(explorer): rpcs for getting log/metric attrs for a trace id + substring
Original PR Description: Adds specialized rpcs for getting a list of log/metric attribute dicts filtered by trace_id and optional substring. This is done with a single snuba rpc (not counting short id lookup) and is a lot more performant than the table queries we were doing earlier.
Return format is list of attr key-value dicts. This is different from the current tool output format which includes
type, tbd if we still need to include thatGetTrace experiment:
Using https://snuba-admin.getsentry.net/#rpc-endpoints, I made requests to EndpointGetTrace and EndpointTraceItemTable for the same purpose - filter logs by a trace (2h old) in Seer project. Time range is last 30d, and I selected the same columns. The table query has an additional LIKE filter on
sentry.body(message) - this isn't supported for GetTrace so we'd have to post-process in sentry or seerEndpointGetTrace - 1318904 progressBytes (bytes processed by clickhouse)
EndpointTraceItemTable - 52792914551 progressBytes. 40k times more, prob scanning from the start of the time range. This is evidence the GetTrace endpoint is way better optimized for trace_id filters.
The requests:
GetTrace:
TraceItemTable
Original PR URL: getsentry#103875