Справочник по показателям, параметрам и фильтрам аналитики

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

Синтаксис API: tps

Число успешных запросов API, использующих кэш ответов вместо ответа от целевой службы.

Синтаксис API: sum(cache_hit)

Возвращает количество элементов в кэше L1 (в памяти) на одну транзакцию за заданный период времени. Например, если вы выберете max на период дня, и в течение этого дня наибольшее количество элементов в кэше будет равно 12 для конкретной транзакции, то счетчик будет равен 12. Для avg , если за время есть три транзакции период, к которому вы запрашиваете, и их счетчики кэша равны 5, 6 и 7, среднее значение равно 6. Кеш L1 — это кеш в памяти, в отличие от кеша базы данных L2, как описано в разделе «Внутреннее устройство кэша» .

Синтаксис API: avg(ax_cache_l1_count)

Общее количество ошибок политики за указанный период времени.

Ошибки политики обычно возникают намеренно. Например, политика проверки ключа API выдает ошибку, когда в запросе передается недопустимый ключ API, а политика Spike Arrest выдает ошибку, если количество вызовов API превышает предел, определенный в политике. Таким образом, эта метрика полезна для поиска потенциальных проблемных мест в ваших API. Например, метрики policy_error, сгруппированные по измерению Developer_app, могут помочь вам обнаружить, что срок действия ключа API или токена OAuth для данного приложения истек; или вы можете обнаружить, что конкретный прокси-сервер API выдает множество ошибок Spike Arrest, что приведет к тому, что предел блокировки пиков прокси-сервера не учитывает увеличение трафика в праздничные дни.

Ошибка политики регистрируется в аналитике только в том случае, если ошибка приводит к сбою прокси-сервера API. Например, если для атрибута continueOnError политики установлено значение true , прокси-сервер API продолжает обрабатывать запрос, даже если политика завершается сбоем. В этом случае ошибка политики не регистрируется в аналитике.

Измерение «Имя политики при ошибке» (ax_execution_fault_policy_name) полезно для группировки ошибок политики по имени политики.

Сбой цели (например, 404 или 503) не считается сбоем политики. Это считается сбоем прокси-сервера API (is_error).

Синтаксис API: sum(policy_error)

Общее количество сбоев прокси-серверов API за указанный период времени. Сбой прокси-сервера может произойти при сбое политики или сбое во время выполнения, например 404 или 503 от целевой службы.

Параметр «Прокси» (apiproxy) полезен для группировки сбоев прокси-сервера API по прокси-серверам.

Синтаксис API: sum(is_error)

Время (среднее, минимальное или максимальное) в миллисекундах , которое требуется Edge для обработки входящих запросов. Отсчет времени начинается, когда запрос достигает Edge, и заканчивается, когда Edge пересылает запрос целевой службе.

Используя различные измерения, вы можете изучить задержки обработки запросов по прокси-серверу API, приложению разработчика, региону и т. д.

Синтаксис API: max(request_processing_latency)

Размер полезных данных запроса, полученных Edge, в байтах .

Синтаксис API: avg(request_size)

Общее количество применений политики кэша ответов за заданный период времени.

Поскольку политика кэширования ответов прикрепляется к прокси API в двух местах (один раз в запросе и один раз в ответе), она обычно выполняется дважды при вызове API. Кеш-получение и кэш-помещение считаются за одно выполнение.

Однако выполнение кэша ответов равно 0, если элемент <SkipCacheLookup> в политике оценивается как true (в запросе), и 0, если элемент <SkipCachePopulation> в политике оценивается как true (в ответе).

В инструменте «Трассировка» вы можете щелкнуть значок «Кэш ответов» в выполняемом вызове API и просмотреть переменную потока responsecache.executed , чтобы узнать, было ли выполнено кэширование (значение 1).

Синтаксис API: sum(ax_cache_executed)

Время (среднее, минимальное или максимальное) в миллисекундах , которое требуется Edge для обработки ответов API. Отсчет времени начинается, когда прокси-сервер API получает ответ целевой службы, и заканчивается, когда Apigee пересылает ответ исходному вызывающему абоненту.

Используя различные измерения, вы можете изучить задержки обработки ответов по прокси-серверу API, региону и т. д.

Синтаксис API: min(response_processing_latency)

Размер полезных данных ответа, возвращаемых клиенту, в байтах .

Синтаксис API: max(response_size)

Общее количество ответов 5xx от целевой службы. Это ошибки целевой службы, не вызванные Apigee.

Синтаксис API: sum(target_error)

Время (сумма, среднее, минимальное или максимальное) в миллисекундах , в течение которого целевой сервер отвечает на вызов. Этот показатель показывает, как работают целевые серверы. Отсчет времени начинается, когда Edge пересылает запрос целевой службе, и заканчивается, когда Edge получает ответ.

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

Синтаксис API: avg(target_response_time)

Количество времени (сумма, среднее, минимальное или максимальное) в миллисекундах с момента, когда Edge получает запрос от клиента, до момента, когда Edge отправляет ответ обратно клиенту. Время включает в себя сетевые издержки (например, время, необходимое балансировщикам нагрузки и маршрутизаторам для выполнения своей работы), задержку обработки запроса, задержку обработки ответа и целевое время ответа (если ответ подается из целевой службы вместо кэша).

Используя различные измерения, вы можете изучить задержки обработки по прокси-серверу API, приложению разработчика, региону и т. д.

Синтаксис API: avg(total_response_time)

Общее количество вызовов API, обработанных Edge за указанный период времени.

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

Синтаксис API: sum(message_count)

Имя продукта API, содержащего вызываемые прокси-серверы API. Чтобы получить это измерение, приложения разработчиков, совершающие вызовы, должны быть связаны с одним или несколькими продуктами API, содержащими прокси-серверы API, а вызываемые прокси-серверы должны проверять ключ API или токен OAuth, отправленный с вызовом API. Ключ или токен связан с продуктом API. Дополнительные сведения см. в разделе Прежде всего: как создать полные аналитические данные .

Если вышеуказанные критерии не выполняются, вы увидите значение «(не установлено)». См. также Что означает значение аналитической сущности «(не установлено)»? .

Ключ, содержащий значение кэша ответов, к которому был осуществлен доступ. Дополнительные сведения о том, как создается ключ для кэша ответов, см. в разделе Политика кэширования ответов .

В инструменте трассировки , когда вы выбираете политику кэша ответов, которая читает или записывает в кеш, вы можете увидеть это значение в переменной потока responsecache.cachekey .

Имя кэша, содержащего ключи/значения, используемые политикой кэша ответов, с префиксом orgName__envName__ . Например, если организация — «foo», среда — «test», а имя кэша — «myCache», то ax_cache_name — foo__test__myCache.

В инструменте трассировки при выборе политики кэширования ответов вы можете увидеть это значение в переменной потока responsecache.cachename .

Уровень кэша («L1» в памяти или база данных «L2»), из которого был получен кэш ответов. В этом измерении также отображается «CACHE_MISS», когда ответ был доставлен из целевого объекта, а не из кэша (и кеш ответа был обновлен целевым ответом); или когда ключ кэша в запросе недействителен. Размер ключей кэша ограничен 2 КБ.

В инструменте Trace при выборе политики Response Cache вы можете увидеть это значение в переменной потока responsecache.cachesource .

Дополнительные сведения об уровнях кэша см. в разделе Внутреннее устройство кэша .

Потребительский ключ (ключ API) приложения разработчика, выполняющего вызовы API, независимо от того, передается ли он в запросе как ключи API или включен в токены OAuth.

Чтобы получить это измерение, прокси-серверы, принимающие вызовы, должны быть настроены на проверку действительного ключа API или токена OAuth. Приложения разработчика получают ключи API, которые можно использовать для создания токенов OAuth, когда приложения регистрируются в Edge. Дополнительные сведения см. в разделе «Перво-наперво: как создать полные аналитические данные» .

Если вышеуказанные критерии не выполняются, вы увидите значение «(не установлено)». См. также Что означает значение аналитической сущности «(не установлено)»? .

Приложение разработчика, зарегистрированное в Edge, совершающее вызовы API.

Чтобы получить это измерение, приложения должны быть связаны с одним или несколькими продуктами API, которые содержат вызываемые прокси-серверы API, а прокси-серверы должны проверять ключ API или токен OAuth, отправленный с вызовом API. Ключ или токен идентифицирует приложение разработчика. Дополнительные сведения см. в разделе «Перво-наперво: как создать полные аналитические данные» .

Если вышеуказанные критерии не выполняются, вы увидите значение «(не установлено)». См. также Что означает значение аналитической сущности «(не установлено)»? .

Электронная почта зарегистрированных в Edge разработчиков, чье приложение выполнило вызовы API.

Чтобы получить это измерение, у разработчиков должны быть приложения, связанные с одним или несколькими продуктами API, которые содержат вызываемые прокси-серверы API, и прокси-серверы должны проверять ключ API или токен OAuth, отправленный с вызовом API. Ключ или токен идентифицирует приложение разработчика. Дополнительные сведения см. в разделе Прежде всего: как создать полные аналитические данные .

Если вышеуказанные критерии не выполняются, вы увидите значение «(не установлено)». См. также Что означает значение аналитической сущности «(не установлено)»? .

Уникальный идентификатор разработчика, сгенерированный Edge, в форме org_name @@@ unique_id .

Чтобы получить это измерение, у разработчиков должны быть приложения, связанные с одним или несколькими продуктами API, содержащими вызываемые прокси-серверы API, а прокси-серверы должны проверять ключ API или токен OAuth, отправленный с вызовами API. Ключ или токен идентифицирует разработчика. Дополнительные сведения см. в разделе Прежде всего: как создать полные аналитические данные .

Если вышеуказанные критерии не выполняются, вы увидите значение «(не установлено)». См. также Что означает значение аналитической сущности «(не установлено)»? .

Код неисправности . Например: messaging.adaptors.http.flow.GatewayTimeout .

Именованный поток в прокси-сервере API, вызвавший ошибку. Например, «PreFlow», «PostFlow» или имя созданного вами условного потока.

Обратите внимание, что полное имя, которое будет использоваться в API управления, — ax_execution_fault_flow_name, без разрыва строки.

Если ошибок не произошло, вы увидите значение «(не установлено)».

В названии потока прокси-сервера API указано, что возникли ошибки, например «PROXY_REQ_FLOW» или «TARGET_RESP_FLOW».

Обратите внимание, что полное имя, которое будет использоваться в API управления, — ax_execution_fault_flow_state, без разрыва строки.

Имя политики, которая вызвала ошибку и привела к сбою вызова API.

Обратите внимание, что полное имя, которое будет использоваться в API управления, — ax_execution_fault_policy_name, без разрыва строки.

Если политика выдает ошибку, но корневому атрибуту политики continueOnError присвоено значение true , поток прокси-сервера API продолжается без сбоев, а сбой политики не учитывается в этом измерении.

BasePath, настроенный на прокси-сервере API ProxyEndpoint. Базовый путь не включает домен и порт URL-адреса прокси-сервера API. Например, если базовый URL-адрес прокси-сервера API — https://apigeedocs-test.apigee.net/releasenotes/, базовый путь — /releasenotes.

Значение также сохраняется в переменной потока proxy.basepath .

Путь к ресурсу добавлен к базовому пути прокси-сервера API. Например, если базовый URL-адрес прокси-сервера API — https://apigeedocs-test.apigee.net/hello/ и выполняется вызов https://apigeedocs-test.apigee.net/hello/json , суффикс пути будет /json .

Если суффикс пути не используется, значение пустое.

Значение также сохраняется в переменной потока proxy.pathsuffix .

Содержит IP-адрес исходного клиента. Значение измерения ax_resolved_client_ip рассчитывается на основе значений измерений ax_true_client_ip и x_forwarded_for_ip .

Обратите внимание, что при использовании продуктов маршрутизации, таких как Akamai, для захвата истинных IP-адресов клиентов, IP-адрес клиента передается Edge в HTTP-заголовке True-Client-IP , который затем используется для установки измерения ax_true_client_ip .

Значение измерения ax_resolved_client_ip рассчитывается следующим образом:

1. Если ax_true_client_ip не равен нулю и не содержит локальный IP-адрес, установите для ax_resolved_client_ip значение ax_true_client_ip .
2. В противном случае установите ax_resolved_client_ip первый нелокальный IP-адрес в x_forwarded_for_ip .
3. Если и ax_true_client_ip , и x_forwarded_for_ip содержат только локальные IP-адреса, установите для ax_resolved_client_ip первый локальный IP-адрес в x_forwarded_for_ip .
4. Если оба ax_true_client_ip и x_forwarded_for_ip равны нулю, установите для ax_resolved_client_ip значение (not set) .
5. Если ax_true_client_ip — это локальный IP-адрес, а x_forwarded_for_ip имеет значение null, установите для ax_resolved_client_ip значение (not set) .

Версия операционной системы устройства, совершающего вызов.

Полезно использовать это в качестве второго «детализированного» измерения с семейством ОС (ax_ua_os_family), чтобы увидеть версии операционных систем.

IP-адрес вызывающего клиента, хранящийся в переменной потока proxy.client.ip . Часто это адрес X-Forwarded-For входящего вызова, который представляет собой IP-адрес Edge, полученный в результате последнего внешнего TCP-квитирования. Это может быть вызывающий клиент или балансировщик нагрузки. Если в заголовке X-Forwarded-For указано несколько IP-адресов, это последний IP-адрес в списке.

При использовании продуктов маршрутизации, таких как Akamai, для захвата истинных IP-адресов клиентов, IP-адреса клиентов передаются Edge в HTTP-заголовке True-Client-IP . Это измерение фиксирует настоящие IP-адреса клиентов из этого заголовка.

Чтобы определить исходный IP-адрес клиента, доступ к которому осуществляется через измерение ax_resolved_client_ip , Edge использует измерения ax_true_client_ip и x_forwarded_for_ip .

Путь ресурса (не включая домен) к целевой службе, исключая параметры запроса.

Например, пример цели Apigee http://mocktarget.apigee.net включает в себя несколько ресурсов, включая /user , который возвращает приветствие. Независимо от того, как ваш прокси-сервер API вызывает http://mocktarget.apigee.net/user , путь_запроса равен /user .

Путь ресурса (не включая домен) к целевой службе, включая параметры запроса.

Например, пример цели Apigee http://mocktarget.apigee.net включает в себя несколько ресурсов, включая ресурс /user?user={name} и параметр запроса для возврата пользовательского приветствия по указанному имени. Независимо от того, как ваш прокси-сервер API вызывает http://mocktarget.apigee.net/user?user=Dude , request_uri равен /user?user=Dude .

Имя пользовательского агента или программного агента, используемого для вызова API. Примеры:

• Pixel XL совершает вызов через Chrome: Mozilla/5.0 (Linux; Android 7.1.2; Pixel XL Build/NHG47N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.92 Mobile Safari/537.36
• iPad совершает вызов через Chrome: Mozilla/5.0 (iPad; CPU OS 10_2 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/54.0.2840.91 Mobile/14C92 Safari/602.1
• cURL из терминала: curl/7.51.0

Версия пользовательского агента.

Полезно использовать это в качестве второго «детализированного» измерения с семейством пользовательских агентов (ax_ua_agent_family), чтобы получить версию семейства агентов.

Путь ресурса (не включая домен) к целевой службе, за исключением параметров запроса, который определен в <TargetEndpoint> прокси-сервера.

Например, скажем, прокси-сервер API вызывает следующую цель:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

В этом примере целевой_базовый путь — /user .

Если бы цель была такой:

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net</URL>
</HTTPTargetConnection>

target_basepath будет нулевым.

В инструменте «Трассировка» при выборе значка AX в конце блок-схемы переменная потока target.basepath сопоставляется с измерением target_basepath.

Код состояния ответа HTTP, возвращаемый целевой службой прокси-серверу API, например 200, 404, 503 и т. д.

Значение «null» означает, что запрос никогда не достиг целевой службы. Это происходит, когда ответ обслуживается политикой кэша ответов или в случае сбоя при обработке запроса.

Это отличается от измерения «Код состояния ответа» (response_status_code) .

Полный URL-адрес целевой службы, определенный в TargetEndpoint прокси-сервера API.

<TargetEndpoint name="default">
...
<HTTPTargetConnection>
  <URL>http://mocktarget.apigee.net/user?user=Dude</URL>
</HTTPTargetConnection>

В этом примере target_url — http://mocktarget.apigee.net/user?user=Dude .

Обратите внимание, что URL-адрес также можно переопределить во время обработки прокси-сервера API с помощью переменной потока target.url .

При цепочке прокси и при использовании целевых объектов сценария (Node.js) target_url в вызывающем прокси имеет значение null.

Список IP-адресов в заголовке X-Forwarded-For .

Чтобы определить исходный IP-адрес клиента, доступный через измерение ax_resolved_client_ip , Edge использует измерения ax_true_client_ip и x_forwarded_for_ip .

Основано на 24-часовом формате, двузначном часе, в течение которого были сделаны вызовы API. Например, для вызовов API, сделанных в период с 22:00 до 23:00, значение ax_hour_of_day будет равно 22.

Значение времени указано в формате UTC.