Трассировка Cloudflare Workers: какой Worker замедлил запрос

17 сентября 2026 года Cloudflare упростила поиск источника задержки в клиентском запросе: теперь трассировка Cloudflare Workers не обрывается на вызывающей стороне, а следует за JavaScript RPC-вызовом в другой Worker или Durable Object. Еще до добавления ручных спанов можно увидеть, какой сервис и метод задержал запрос, и не искать виновника во всем стеке сразу.

Как трассировка Cloudflare Workers закрывает слепую зону

RPC лишь звучит сложно. В Cloudflare Workers удаленный вызов процедуры — это обращение одного Worker к публичному JavaScript-методу другого Worker или Durable Object через привязку. В коде оно выглядит как обычный вызов локального метода, хотя выполняется в другом месте.

Трасса — это временная шкала одного запроса, а каждый измеряемый участок внутри нее называется спаном. До этого релиза шкала обрывалась, когда вызывающий Worker пересекал границу JavaScript RPC. Было видно, как Worker A отправляет вызов, но надежно связать его с работой в Worker B или Durable Object не получалось.

Релиз Cloudflare от 17 сентября закрывает этот разрыв. Теперь в одной трассе видны сессия на стороне вызывающего Worker, каждый вызов метода, запуск принимающей стороны, вложенные вызовы и обратные вызовы в другой Worker. После включения трассировки Cloudflare записывает эти спаны автоматически. Для такого инструментирования на уровне платформы не нужно подключать SDK наблюдаемости или менять код приложения.

Спан сессии служит контейнером для RPC-сессии на вызывающей стороне. Внутри него группируются вызовы, которые используют эту сессию повторно. В спанах отдельных вызовов указывается путь к методу или свойству, а вызов на принимающей стороне получает собственный спан. Смена цвета показывает, где выполнение переходит между Workers или в Durable Object.

Так вместо слепой зоны появляется карта ответственности.

Разберем один запрос на оформление заказа

Представим клиентский запрос POST /checkout.

Сначала его принимает Worker оформления заказа. Затем он вызывает inventory.reserve() в Worker управления остатками и order.commit() в Durable Object заказов. Для клиента это один медленный процесс оформления, но задержка может возникнуть в трех разных местах приложения.

Раньше трасса оформления могла закончиться на RPC-вызове. Чтобы восстановить дальнейший путь, приходилось сопоставлять идентификаторы в логах каждого сервиса или заранее добавлять собственные спаны.

Теперь весь путь запроса остается в одной трассе. Можно раскрыть RPC-сессию, найти спаны методов reserve и commit, увидеть вызовы нижестоящих компонентов и сравнить, где сосредоточено общее время. Корневые спаны также могут содержать Cloudflare Ray ID, имя Worker, точку входа, результат, процессорное и общее время — этого достаточно, чтобы во время инцидента быстро найти нужный запрос.

Новый вид не объясняет, почему метод работает медленно. Он подсказывает, где продолжить поиск. Если большая часть ожидания приходится на вызов Worker управления остатками, проверяйте его хранилище или внешнюю зависимость. Если самым широким оказался спан Durable Object, изучите обработчик этого объекта и работу с хранилищем. Если задержка возникает на вызывающей стороне еще до начала обоих RPC-вызовов, нижестоящие сервисы не должны быть первыми подозреваемыми.

Кому это пригодится

Основателю, который разделил бэкенд на несколько сервисов

Основатель, у которого оформление, остатки и состояние заказа работают в отдельных Workers, может воспроизвести одну медленную покупку и проследить весь ее путь в Cloudflare. Область поиска заметно сужается: исследовать нужно именно тот Worker или Durable Object, которому принадлежит задержка, а не проверять заново каждый сервис.

Руководителю бэкенда в продукте с состоянием

В приложении для совместной работы действие внутри комнаты может идти через пограничный Worker в Durable Object этой комнаты. Руководитель бэкенда увидит, сколько времени ушло на вызывающую сторону, а сколько — внутри объекта с состоянием, после чего передаст трассу команде, отвечающей за эту границу.

Платформенному инженеру с внутренними сервисами на Workers

У платформенной команды несколько Workers могут быть связаны через сервисные привязки, а возвращаемые стабы и обратные вызовы способны превратить маршрут в цепочку, которую трудно восстановить по логам. Спаны сессий и методов показывают, какие вызовы повторно использовали одну сессию, какой Worker выполнял каждый участок и где в маршрут вошел вложенный вызов.

Руководителю поддержки, которому нужны доказательства

Пока детали инцидента еще свежи, поддержка может попросить инженеров воспроизвести тот же маршрут. В результате к обращению прикладывается трасса с конкретным сервисом и границей метода, а не расплывчатое «оформление заказа тормозило». Это полезно, даже если для окончательного исправления все равно понадобятся логи, профилировщик или план запроса к базе данных.

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

Начинать стоит с одного маршрута запроса, а не со всех Workers в production-среде одновременно.

1. 1

   Выберите заметный для клиента маршрут

   Возьмите запрос, который уже пересекает RPC-границу между двумя Workers либо между Worker и Durable Object и для которого можно повторить медленный сценарий. Запишите маршрут, ожидаемые вызовы нижестоящих методов и время воспроизведения.

2. 2

   Включите трассировку в Wrangler

   Добавьте параметр из документации Cloudflare в конфигурацию Wrangler того Worker, который обрабатывает выбранный маршрут:

   {
     "$schema": "./node_modules/wrangler/config-schema.json",
     "observability": {
       "traces": {
         "enabled": true
       }
     }
   }

   Разверните конфигурацию обычным для вашей команды способом. Этот переключатель включает автоматические спаны Cloudflare; добавлять SDK внутрь Worker не требуется.

3. 3

   Воспроизведите один медленный запрос

   Один раз выполните тот же запрос в контролируемых условиях. Сохраните маршрут, метку времени и Cloudflare Ray ID, если служба поддержки или система логирования уже его фиксирует. Контролируемая среда дает более чистый результат: если не указано иное значение, стандартная частота семплирования трасс равна 1, то есть отслеживаются 100% входящих запросов.

4. 4

   Читайте трассу снаружи внутрь

   В Cloudflare откройте Workers & Pages, выберите Worker и перейдите в Observability. Найдите воспроизведенный запрос и раскройте его трассу. Начните с корневого запроса, затем последовательно просмотрите RPC-сессию, спан метода на вызывающей стороне, вызов принимающей стороны и все вложенные обращения к Durable Object. По ширине спана и полям общего времени определите границу, которую следует исследовать дальше.

5. 5

   Оцените счет до масштабного включения

   Зафиксируйте, сколько спанов создала воспроизведенная трасса. Затем оцените месячный объем событий трассировки по формуле sampled requests × average spans per sampled trace. Прибавьте события логов, которые расходуют ту же квоту наблюдаемости. Измеренное количество спанов станет исходным значением для выбора семплирования в production.

Стоимость считают по спанам, а не по запросам

На первом этапе бета-тестирования трассировка Workers бесплатна. Условия изменятся 1 октября 2026 года: с этой даты каждый спан будет считаться отдельным событием наблюдаемости и расходовать ту же квоту по тем же тарифам, что и Workers Logs.

Корпоративным клиентам нужно свериться со своим договором. Всем остальным важно учитывать единицу тарификации: один клиентский запрос может создать корневой спан, спан RPC-сессии, спаны вызовов методов, вызовы принимающей стороны и спаны вложенных привязок. По одному лишь числу запросов стоимость трассировки не определить.

В документации Cloudflare по трассировке указано, что стандартное значение head_sampling_rate равно 1, то есть 100%. В примере для высокой нагрузки используется 0.05: трассируется пять из каждых ста входящих запросов. Это пример механизма управления, а не универсальная рекомендация.

Семплирование в начале запроса делает компромисс очевидным. Меньшая частота сокращает объем событий, но решение принимается до обработки запроса, поэтому редкий медленный запрос может не попасть в выборку. Используйте полное семплирование при контролируемом воспроизведении или в достаточно изолированной среде, а для production выбирайте частоту на основе реального трафика и измеренного количества спанов на трассу.

Срок хранения тоже влияет на работу с инцидентами. На тарифе Free трассы доступны 3 дня, на Paid — 7 дней. Если сообщение клиента придет позже, нужной трассы уже может не оказаться. Практическое правило простое: воспроизводите и исследуйте проблему, пока данные еще доступны, либо экспортируйте трассы в систему с подходящим вашему процессу сроком хранения.

О каких ограничениях важно знать

Трассировка Workers все еще находится в открытой бете. Названия спанов и атрибутов могут измениться, а Cloudflare предупреждает, что часть атрибутов пока заполнена не полностью.

Некоторые спаны без операций ввода-вывода могут показывать 0 ms, даже если работа заняла больше времени. Workers Runtime обновляет время только при событии ввода-вывода, поэтому нулевое значение не доказывает, что участок JavaScript не занял времени.

За пределами Cloudflare автоматическая связность трассы тоже заканчивается. При экспорте трасс Workers Cloudflare пока не передает идентификаторы трассировки во внешние сервисы. Поэтому трасса вызова к платежному провайдеру или базе данных на сторонней платформе не присоединится к временной шкале Workers автоматически.

Наконец, этот релиз решает узкую задачу. Один Worker без границы JavaScript RPC не получает нового представления межсервисного пути. Общая трассировка Workers по-прежнему может быть полезна для fetch-запросов, привязок и обработчиков, но изменение от 17 сентября особенно важно для приложений, уже разделенных между Workers или Durable Objects.

Что делать сейчас

Действуйте на этой неделе, если клиентские запросы проходят через сервисные привязки или Durable Objects, а команда пока сопоставляет несколько логов, чтобы найти медленный переход. Начните с маршрута, разбор которого отнимает больше всего ресурсов у поддержки или во время инцидентов.

Можно подождать, если приложение по-прежнему состоит из одного Worker либо предполагаемая задержка целиком находится на стороне внешнего провайдера. Этот релиз не связывает трассы за пределами Cloudflare.

Если трассировка уже включена, сначала изучите новые RPC-спаны и только потом добавляйте собственное инструментирование. Собственные спаны нужны лишь тогда, когда автоматическая трасса обнаружит существенный пробел внутри метода, за который отвечает ваша команда.

Первый шаг на понедельник невелик: включите observability.traces.enabled для одного реального маршрута запроса, воспроизведите задержку, изучите RPC-сессию и спаны методов, а затем запишите частоту семплирования, среднее количество спанов на трассу, срок хранения и ожидаемый расход квоты — и только после этого расширяйте охват.

Если вам нужна короткая практическая заметка о каждом изменении платформы, которое влияет на рабочий процесс или сумму счета, подпишитесь на рассылку.