getsentry / getsentry/sentry-javascript

Sentry Backend Modification for SSR Traces

Đang mở
#24,227 1 bình luận 0 reaction 0 người được giao Xem trên GitHub
javascript
Ngôn ngữ chính
TypeScript
Star
8.7k
Fork
1.8k
Merge trung bình
1 ngày 17 giờ
Pull request đã merge (30 ngày)
523

Mô tả

## 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?

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Lĩnh vực
backend-api-design, observability-sre
Loại issue
Tính năng
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Sôi nổi
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
25/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.