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

Среднее количество транзакций, то есть запросов к 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, а политика «Арест пиковых нагрузок» выдает ошибку, если количество вызовов API превышает лимит, определенный в политике. Поэтому этот показатель полезен для выявления потенциальных проблемных мест в ваших API. Например, метрики policy_error, сгруппированные по параметру developer_app, могут помочь вам обнаружить, что срок действия ключа API или токена OAuth для данного приложения истек; или вы можете обнаружить, что определенный API-прокси выдает много ошибок Spike Arrest, что приведет к выводу, что лимит Spike Arrest этого прокси не учитывает увеличение трафика в праздничные дни.

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

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

Ошибка целевого объекта (например, 404 или 503) не считается ошибкой политики. Такие ошибки учитываются как ошибки API-прокси (is_error).

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

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

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

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

Время (среднее, минимальное или максимальное) в миллисекундах , необходимое 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 КБ.

В инструменте трассировки , при выборе политики кэширования ответов, это значение можно увидеть в переменной потока 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) настраивается в ProxyEndpoint API-прокси. Базовый путь не включает домен и порт из 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 .

Если параметр pathsuffix не указан, значение пустое.

Это значение также сохраняется в переменной потока 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 не равен null и не содержит локальный 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 равны null, установите 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-адресов, то это последний из них.

При использовании маршрутизирующих устройств, таких как 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 , request_path будет равен /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>

В этом примере target_basepath равен /user .

Если бы целью было следующее:

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

Параметр target_basepath будет равен null.

В инструменте «Трассировка» при выборе значка 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-часового формата времени, значение ax_hour_of_day будет равно 22 (двузначное число). Например, для вызовов API, совершенных в промежутке между 22:00 и 23:00, значение ax_hour_of_day будет равно 22.

Время указано в формате UTC.