← Cloudflare Workers / workers / observability

Метрики и аналитика

Информацию о трафике Workers в конкретный момент времени можно получить из двух графических источников: Workers metrics и Workers analytics на уровне зоны.

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

Аналитика зоны показывает, какой объём трафика обрабатывают все Workers, привязанные к зоне.

Workers metrics агрегируют данные запросов для отдельного Worker (если ваш Worker работает на нескольких доменах, а также на *.workers.dev, метрики будут агрегировать запросы по всем им). Чтобы просмотреть метрики вашего Worker:

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

На первом графике показано историческое количество запросов от среды выполнения Workers с разбивкой на успешные запросы, запросы с ошибками и подзапросы.

• Всего: Все входящие запросы, зарегистрированные Worker. Запросы, заблокированные WAF ↗ или другие функции безопасности учитываться не будут.
• Успешно: Запросы со статусом вызова Success или Client Disconnected.
• Ошибки: Запросы со статусом вызова Script Threw Exception, Exceeded Resources или Internal Error. Подробнее см. Статусы вызовов чтобы узнать, откуда возникают ваши ошибки.

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

Подзапросами называются запросы, инициируемые вызовом fetch изнутри Worker. Подзапрос, завершившийся необработанной ошибкой, не учитывается.

• Всего: Все подзапросы, вызванные при обращении к fetch изнутри Worker.
• В кеше: Количество возвращённых кешированных ответов.
• Без кеша: Количество возвращённых некешированных ответов.

Астрономическое время означает время в миллисекундах между началом вызова Worker и моментом, когда среда выполнения Workers определяет, что выполнение JavaScript больше не требуется. В частности, график wall time per execution измеряет время, в течение которого JavaScript-контекст оставался открытым: включая время ожидания ввода-вывода и время, потраченное на выполнение кода в вашем Worker waitUntil() обработчик. Реальное время не совпадает со временем, за которое ваш Worker отправляет клиенту последний байт ответа: оно может быть больше, если задачи внутри waitUntil() ещё выполняются после отправки ответа, или может быть ниже. Например, при возврате ответа с большим телом среда выполнения Workers в некоторых случаях может определить, что больше не требуется выполнять JavaScript, и закрывает контекст JavaScript до того, как все байты были переданы и отправлены.

График времени выполнения (wall time) на вызов показывает исторические данные о времени выполнения с разбивкой по квантилям с использованием выборка методом резервуара ↗. Подробнее о интерпретация квантилей ↗.

График CPU Time per execution показывает исторические данные о процессорном времени, разбитые на соответствующие квантили с использованием выборка методом резервуара ↗. Подробнее о интерпретация квантилей ↗. В некоторых случаях более высокие квантили могут превышать Лимиты времени CPU без появления ошибок вызова благодаря механизму среды выполнения Workers, который позволяет переносить неизрасходованное процессорное время для запросов, уложившихся в лимит CPU.

График Duration per request показывает исторические длительность на один вызов Worker. Данные разбиты по квантилям, аналогично графику времени CPU. Подробнее об этом см. интерпретация квантилей ↗. Понимание длительности выполнения Worker особенно полезно, если вы планируете выполнять на нём значительный объём вычислений.

График использования памяти показывает, сколько памяти V8 isolate использует ваш Worker в момент каждого вызова, с разбивкой по перцентилям P50, P90, P99 и P999 с использованием выборка методом резервуара ↗. Дополнительную информацию см. в Интерпретация квантилей ↗.

Workers выполняются в V8 изоляты, каждый со своим лимит памяти 128 MB. Один isolate может обрабатывать множество одновременных запросов, разделяя между ними память. Метрика использования памяти показывает, сколько из этой общей памяти занято на момент каждого вызова.

Маркеры развертывания на графике позволяют сопоставить изменения памяти с конкретными развертываниями кода, что упрощает определение того, привела ли новая версия к регрессии по памяти.

Если использование памяти со временем растёт, это может указывать на утечку памяти. Используйте профилирование памяти с помощью DevTools локально, чтобы делать снимки кучи и находить конкретные объекты, вызывающие высокое потребление памяти.

Чтобы просмотреть статусы вызовов:

Статусы вызова Worker показывают, был ли Worker выполнен успешно или не смог сформировать ответ в среде выполнения Workers. Статусы вызова отличаются от Коды состояния HTTP. В некоторых случаях вызов Worker завершается успешно, но не возвращает успешный HTTP-статус из-за другой ошибки, возникшей вне среды выполнения Workers. Некоторые статусы вызова приводят к код ошибки Workers возвращается клиенту.

¹ Статус Exceeded Resources может появляться, если Worker превышает лимит времени выполнения. Чаще всего причиной является превышение времени процессора, но это также может быть вызвано превышением времени запуска Worker или лимитов бесплатного тарифа.

² Статус Internal Error может появляться, если среда выполнения Workers не может обработать запрос из-за внутреннего сбоя в нашей системе. Эти ошибки не связаны с кодом Worker и не зависят от каких-либо ограничений ресурсов. Запросы со статусом Internal Error встречаются редко, но некоторые могут появляться и при обычной работе. Такие запросы не учитываются при расчёте использования для выставления счетов. Если вы замечаете повышенную частоту запросов со статусом Internal Error, изучите www.cloudflarestatus.com ↗.

Чтобы подробнее изучить исключения, используйте wrangler tail.

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

В отличие от продолжительность выполнения, который измеряет только время активности Worker, длительность запроса измеряется от момента поступления запроса в дата-центр до момента доставки ответа.

На диаграмме показана длительность запросов с включённым Smart Placement по сравнению с запросами, для которых Smart Placement отключён (по умолчанию 1% запросов направляется с отключённым Smart Placement). Диаграмма представляет собой гистограмму, где по оси X отложена длительность, а по оси Y процент запросов, попадающих в соответствующий интервал длительности.

Метрики Worker можно просматривать за период до трёх месяцев назад с максимальным шагом в одну неделю.

Аналитика зоны собирает данные о запросах для всех Workers, привязанных к любой маршруты заданы для зоны.

Чтобы просмотреть метрики зоны:

На панели управления Cloudflare перейдите к разделу Аналитика Workers странице вашей зоны.

Данные зоны можно ограничить временным диапазоном в пределах последних 30 дней. Дашборд включает графики и информацию, описанные ниже.

Эта диаграмма показывает подзапросы: запросы, инициированные вызовом fetch изнутри Worker с разбивкой по статусу кеша.

• Без кеша: Запросы, на которые напрямую ответил ваш origin-сервер или другие серверы, обрабатывающие subrequest.
• В кеше: Запросы, на которые ответил кеш ↗. Чем больше вашего контента кеширует Cloudflare, тем быстрее происходит доставка контента и тем меньше нагрузка на origin.

На этом графике показано историческое использование трафика всеми Workers в зоне в разбивке по статусу кеша.

На этом графике показаны исторические запросы всех Workers в зоне в разбивке по коду статуса HTTP.

На этом графике показаны исторические данные по всем Workers в зоне в разбивке на успешные запросы, неуспешные запросы и подзапросы. Эти типы запросов классифицируются по коду статуса HTTP, где 200-уровня запросы выполняются успешно, и 400 к 500-уровня запросы завершаются ошибкой.

Метрики Worker строятся на основе GraphQL. Подробнее о том, как выполнять запросы к нашим наборам данных, читайте в Руководство по запросу метрик Workers через GraphQL.

Метрики, описанные выше, дают представление о производительности Worker и поведении во время выполнения. Для пользовательской аналитики на уровне приложения используйте Workers Analytics Engine.

Analytics Engine полезен для:

• Пользовательские бизнес-метрики - Отслеживайте события, специфичные для вашего приложения, такие как регистрации, покупки или использование функций.
• Аналитика для каждого клиента - Записывайте данные с измерениями высокой кардинальности, такими как ID клиентов или ключи API.
• Оплата по факту использования - Подсчитывайте количество вызовов API, единиц вычислений и других тарифицируемых событий в разрезе клиентов.
• Отслеживание производительности - Измеряйте время отклика, частоту попаданий в кэш и частоту ошибок с пользовательскими измерениями.

Запись в Analytics Engine выполняется неблокирующим образом и не увеличивает задержку вашего Worker. Запрашивайте данные с помощью SQL через Analytics Engine SQL API или визуализировать это в Grafana.

См. пример Analytics Engine чтобы начать работу.