Sentry Backend Modification for SSR Traces

Bắt đầu với Span Links Spec và entry point được tham chiếu sentry/search/eap/spans/attributes.py, sau đó xem xét cách Relay và span consumer truyền các link vào EAP. Công việc được xem là hoàn tất khi dự án có một phương pháp đã được quyết định và có thể truy vấn để liên kết các trace máy chủ và máy khách được lưu trong cache, bao gồm các hướng được hỗ trợ và các cửa sổ truy vấn theo thời gian tồn tại của cache, hoặc có một workaround bằng attribute được ghi lại tài liệu nếu không thể triển khai các link được lập chỉ mục.

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)
   • 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?