getsentry / getsentry/sentry-javascript
Sentry Backend Modification for SSR Traces
- Langage dominant
- TypeScript
- Étoiles
- 8.7k
- Forks
- 1.8k
- Merge moyen
- 1 j 17 h
- PR mergées (30 j)
- 523
Description
## The Problem: Cached SSR pages have no connected client/server trace
SSR meta-frameworks cache the HTML/render output: a server renders a page once (build-time, first visit, or on revalidation). Later visitors get the stored result from the server (so no server trace or a disconnected one).
Probably thousands of client pageloads map to one server render.
### Differences to previous_trace linking
- `previous_trace` is a 1:1 relationship
- Cached server pages are 1 origin with many consumers (1:N)
- Time-gap between server and client can be as long as the cache lifetime
## What exists
- Span Links Spec: https://develop.sentry.dev/sdk/telemetry/traces/span-links/
- Relay has full support for span links (`sentry.links` and `sentry.link.type`) and passes them through untouched
- Span consumer flattens each span link(s) into a JSON attribute `sentry.links` - stored in EAP
- `sentry.links` is not queryable (`private=True`)
- Span Attribute support for `previous_trace`
## What we need
1. **Span links, queryable in EAP** - indexed by `trace_id` in both directions
- **Prio 1**: One of multiple, different consuming traces (e.g. browser pageload trace) should be able to link to the one connecting server trace
- **Prio 2**: Also nice: One cached server trace should be able to link to all the client/browser traces it served
- What is the cost of this query?
- Can we get an aggregate (e.g. just the number) of it?
2. Workaround (near-term solution): Register a queryable attribute (similar to previous_trace - [here in code](https://github.com/getsentry/sentry/blob/f4df1b22e6a2b5460eb0cfcc5d3d29a6d0b5d3e7/src/sentry/search/eap/spans/attributes.py#L526))
- we only need this workaround if the task above (links in EAP) takes too long
- Only works for N:1 lookup (like Prio 1 task from above)
- Example naming: `simple_sentry_field("cache_origin_trace")`
- Can we do a 1:N lookup with this attribute?
3. Querying Time Window
- Being able to query links within a window that fits cache lifetimes (not assumptions of e.g. 1 hour windows)
- What are possible limitations here?
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Start with the Span Links Spec and the referenced sentry/search/eap/spans/attributes.py entry point, then review how Relay and the span consumer pass links into EAP. Done means the project has a decided, queryable approach for linking cached server and client traces, including supported directions and cache-lifetime query windows, or a documented attribute workaround if indexed links are not feasible.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Domaine
- backend-api-design, observability-sre
- Type d'issue
- Fonctionnalité
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- Active
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100