Производительность

Раздел «Производительность» показывает не отдельные ошибки, а то, как быстро работает приложение: транзакции (обработанные запросы или фоновые операции), из которых состоят спаны (запросы к БД, HTTP-вызовы к другим сервисам, рендер шаблона и т. п.), и трейсы — сквозные цепочки таких транзакций/спанов одного запроса.

Как отправлять данные

Транзакции и спаны присылает SDK вашего приложения — тот же официальный Sentry SDK, что и для ошибок (см. SDK и интеграции), только с включённым трейсингом. Ключевая настройка при инициализации — tracesSampleRate (доля запросов, которые SDK трассирует и отправляет, от 0 до 1):

Sentry.init({
  dsn: "<ВАШ_DSN>",
  tracesSampleRate: 1.0, // на старте — 100%, на проде обычно снижают
});

Аналогичный параметр есть у SDK любого языка (Go/PHP/Python и т. д.) — конкретное имя опции и способ включить автоинструментацию фреймворка смотрите в документации вашего Sentry SDK. Пока tracesSampleRate равен нулю или не задан, раздел «Производительность» остаётся пустым — данные появляются только после того, как SDK начинает реально отправлять трассировку.

Список эндпойнтов

Раздел открывается по ссылке «Производительность» в левом рельсе — URL /projects/<id>/performance (в меню подраздел называется «Транзакции»). Фильтры сверху — окружение и период (1 час / 24 часа / 7 дней / 30 дней). Таблица эндпойнтов:

Заголовки колонок — ссылки, клик сортирует список по этой колонке. Список эндпойнтов ограничен по размеру; если реальных эндпойнтов больше, над таблицей появляется пометка «показаны первые N из M».

Apdex. Под фильтрами показывается используемый порог T (например, «Apdex T = 300ms», настраивается в настройках проекта). Запрос длительностью до T считается «удовлетворённым», от T до 4T — «терпимым», дольше — «неудовлетворённым»; Apdex = (удовлетворённые + терпимые/2) / всего. Резкий рост p95/p99 при стабильном трафике — типичный признак деградации, а не просто увеличения нагрузки: трафик не растёт, значит дело не в объёме запросов.

Деталь эндпойнта

Клик по имени эндпойнта открывает /projects/<id>/performance/<transaction>: период/окружение/порог Apdex в шапке, панель Web Vitals (если это транзакция загрузки страницы — подробнее ниже), график латентности (p50/p95 во времени), график трафика, гистограмма распределения длительностей, таблица самых медленных трейсов за период (ссылка на waterfall каждого) и список связанных проблем производительности.

Проблемы производительности (N+1-запросы, медленные запросы к БД, HTTP-флуд) — это отдельная, автоматически обнаруживаемая категория находок внутри транзакций, не то же самое, что регрессии из этого документа. Полный список — в разделе «Проблемы производительности» (/projects/<id>/perf-issues), доступном из того же подменю «Производительность».

Waterfall трейса

Ссылка «Трейс» из таблицы медленных трейсов или из детали события в Проблемах открывает /traces/<trace_id>: id трейса, общая длительность, время, и ниже — waterfall дерева спанов (каждый спан — полоса, смещённая и растянутая по времени относительно начала трейса; спаны с ошибкой отмечены красным). Если у трейса есть привязанный профиль (см. Профилирование), над waterfall появляется ссылка на его флеймграф — так можно перейти от «какой спан долгий» к «что именно внутри него выполнялось».

Web Vitals

Web Vitals — метрики скорости страницы, измеренные в браузере реального пользователя (RUM), а не синтетическим тестом на сервере. Раздел открывается вкладкой «Web Vitals» в подменю «Производительность» — URL /projects/<id>/web-vitals.

Пороги (Google, фиксированные)

Рейтинг good / needs-improvement / poor считается по 75-му перцентилю (p75) значения за выбранный период — это официальные пороги Google для Core Web Vitals. Они не настраиваются по проектам: одни и те же числа для всех, потому что это внешний, общепринятый стандарт, а не собственная метрика Gotcha.

Граница good включительна (p75, равный порогу, — ещё «good»), значение выше poor-порога — «poor», всё между — «needs-improvement».

Как считается p75

Для каждой страницы (транзакции загрузки страницы) и метрики Gotcha берёт 75-й перцентиль значений, собранных за выбранный период фильтра (1 час / 24 часа / 7 дней / 30 дней), и присваивает рейтинг по таблице выше. Если замеров для метрики за период нет, вместо значения показывается «—» без бейджа.

Как читать страницу

Таблица — по одной строке на страницу (транзакцию), колонки p75 LCP/INP/CLS с цветным бейджем рейтинга и число замеров; сортировка по клику на заголовок, фильтры окружения и периода те же, что на списке эндпойнтов. На странице конкретного эндпойнта (если это pageload-транзакция) те же три метрики показаны в виде панели с мини-графиком p75 во времени — удобно увидеть, ухудшилось значение недавно или это стабильный уровень.

Данные приходят из браузерного SDK (@sentry/browser) с включённым трейсингом — без него Web Vitals собирать некому, серверные SDK этого не делают. Установка описана в SDK и интеграции.

Регрессии

Регрессия производительности — это статистически значимое ухудшение p95 длительности эндпойнта или p75 web vital’а относительно скользящей базовой линии, обнаруженное автоматически, без ручной настройки порогов «на глаз» под каждый эндпойнт. Список — в подразделе «Регрессии» (/projects/<id>/regressions), с вкладками «Открыто / Решено / Все». Таблица: цель (эндпойнт или ссылка на Web Vitals), метрика, рост в процентах, диапазон «база → пик», статус, когда началась, длительность (или «идёт», пока регрессия открыта).

Как работает детекция (порог + гистерезис)

Фоновый оценщик периодически сравнивает свежее окно (по умолчанию 60 минут) с базой — медианой дневных значений за последние 7 дней — для самых нагруженных эндпойнтов и страниц с web vitals проекта:

• Открытие происходит, только если выполнены сразу два условия: относительный рост (свежее > база × (1 + порог)) и абсолютный «пол» (свежее > база + Floor). Порог по умолчанию — 25%. Пол нужен, чтобы рост с 20 мс до 40 мс (формально +100%) на почти неощутимых цифрах не поднимал ложную тревогу.
• Закрытие использует более мягкий порог восстановления — по умолчанию 10% (свежее ≤ база × 1.10), а не тот же 25%, что и открытие. Это гистерезис: без разрыва между порогом открытия и закрытия регрессия «мигала» бы туда-сюда на границе.
• Решение принимается только при достаточной статистике: и в свежем окне, и в базе должно быть не меньше минимального числа замеров (по умолчанию 100), иначе оценщик ничего не решает в этот тик.

Дефолтные абсолютные полы: 100 мс для длительности эндпойнта, 200 мс для LCP/FCP/TTFB, 50 мс для INP, 0.05 для CLS.

Все эти пороги (проценты открытия/закрытия, размер окна, минимум замеров, полы по каждой метрике, а также полный выключатель детектора) настраиваются отдельно для каждого проекта — карточка «Регрессии» на странице «Настройки проекта».