getsentry / getsentry/sentry-javascript

Sentry Backend Modification for SSR Traces

Ouverte
#24,227 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub
javascript
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

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.