Sentry JavaScript SDK 11 вийшов у beta та змінив правила збору даних

Команда Sentry опублікувала першу beta майбутнього JavaScript SDK 11 і прямо попередила: це ще не стабільний реліз, а migration guide продовжує змінюватися. Головні напрямки major-версії — чистіша сумісність з OpenTelemetry, нове instrumentування для сучасних runtime, span streaming і детальніший контроль збору даних. Найчутливіша зміна стосується privacy: новий default став ширшим, ніж у v10.

Це beta, а не сигнал оновлювати production

Release notes не містять повного changelog для версії 11. Натомість вони фіксують стан beta.0, дають таблицю розмірів bundles і посилаються на робочу версію migration guide. Тому пакет придатний для окремої test branch, перевірки type errors, збірки й телеметрії, але не для автоматичного rollout у критичні застосунки.

Сумісність із self-hosted backend заявлена від версії 24.4.2, як і для SDK 10. Старіші backend можуть працювати, але не зобов’язані підтримувати всі функції. Перед тестом потрібно перевірити не тільки frontend package, а й ingestion, dashboards, sampling та збереження полів на сервері.

OpenTelemetry більше не підпорядковується Sentry

У більшості server-side SDK версія 11 перестає автоматично реєструвати OpenTelemetry tracer provider. За замовчуванням Sentry керує власними spans без повного OTel setup. Якщо застосунок уже має OpenTelemetry pipeline, його можна залишити власником spans, а нова openTelemetryIntegration() прив’яже помилки, logs, metrics і crons Sentry до активного OTel span.

Це прибирає необхідність вбудовувати Sentry-specific context manager, sampler і span processor у власний provider. Для передачі самих spans потрібно налаштувати свій OTLP exporter. Важлива межа: якщо одночасно залишити Sentry tracing і повний OTel instrumentation для однакових бібліотек, можна отримати дублікати spans. Migration guide радить чітко визначити одного власника tracing.

@sentry/nextjs і @sentry/sveltekit залишають легкий OTel-compatible provider для spans, які створює framework. В інших server SDK новий параметр enableOpenTelemetrySetup зазвичай false. Він замінює старий skipOpenTelemetrySetup із протилежним значенням, тому механічне перейменування без перевірки змінить поведінку.

dataCollection потребує privacy review

Опцію sendDefaultPii замінює granular-конфігурація dataCollection. Це не просте перейменування. У v10 невказаний sendDefaultPii означав обмежувальну поведінку. У v11 невказаний dataCollection дозволяє більше категорій за замовчуванням, зокрема user info, cookies, request і response bodies, URL query parameters, GenAI inputs та outputs і database query data.

Вбудована фільтрація чутливих значень продовжує працювати, але не замінює політику застосунку. Request body може містити персональні дані, form fields — секрети, database query — бізнесові значення, а GenAI prompt — приватний контекст. Команді варто явно задати кожну категорію, оновити server-side scrubbing та перевірити data residency і строки зберігання.

Якщо потрібно зберегти поведінку v10, migration guide пропонує explicit restrictive baseline: вимкнути user info й cookies, заборонити bodies та GenAI content, обмежити headers і query parameters denylist та не передавати database query data. Це слід закріпити тестом, який переглядає реальний envelope, а не тільки TypeScript config.

Нові мінімальні версії

• Node.js — щонайменше 20.19.0; Node 18 більше не підтримується.
• Deno — щонайменше 2.8.3.
• TypeScript — щонайменше 5.0.4, без down-leveled types.
• Safari — від 15; підтримку Safari 14 прибрано.
• Next.js — від 14, React — від 17, Astro — від 4.
• Для AWS Lambda v11 layer розрахований на nodejs20.x, nodejs22.x і nodejs24.x.

Ці обмеження можуть заблокувати upgrade раніше, ніж breaking API. Корисно спочатку зібрати матрицю runtime і framework versions для всіх сервісів, browser support policy та Lambda layers, а вже потім піднімати SDK у спільному lockfile.

Span streaming та розмір bundle

Streaming spans стає стандартним шляхом і обходить обмеження старих transactions за розміром та кількістю spans. Водночас різні integrations дуже по-різному впливають на bundle. Beta notes наводять орієнтири: базовий browser package близько 28 КБ, варіант із tracing — близько 48 КБ, а комбінації з Replay та Feedback можуть перевищувати 90 КБ у наведеному вимірюванні. Це не універсальна вага вашого production bundle, тому її треба перевірити власним bundler analyzer.

Практичний план тестування

1. Створіть окрему branch і не розгортайте beta на весь production traffic.
2. Зафіксуйте одного власника spans: Sentry або власний OpenTelemetry provider.
3. Явно задайте dataCollection та перегляньте кілька реальних envelopes на секрети й персональні дані.
4. Перевірте мінімальні runtime, framework, TypeScript і browser versions.
5. Порівняйте bundle size, кількість spans, ingestion volume та вартість до і після.

Практичний висновок: головний ризик beta не в синтаксисі API, а в непомітній зміні ownership tracing і ширших defaults збору даних. Без privacy review та observability тесту оновлення робити не варто.

Джерело та ліцензія

Матеріал підготовлено за release notes Sentry JavaScript SDK 11.0.0-beta.0 і migration guide. Репозиторій поширюється за MIT License. Український текст перекладено й адаптовано редакцією.