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

Среднее количество транзакций (запросов прокси-сервера 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, и понять, что ограничение на скачки трафика для этого прокси-сервера не учитывает увеличение трафика в праздничные дни.

Ошибка правила регистрируется в аналитике только в том случае, если она приводит к сбою прокси 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)

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

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

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

В инструменте трассировки можно нажать на значок кеша ответов в выполненном вызове 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. Подробнее о том, как получать полные данные аналитики…

Если указанные выше критерии не соблюдены, вы увидите значение "(not set)". Также ознакомьтесь со статьей Что означает значение "(not set)" в объекте Аналитики.

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

В инструменте трассировки, когда вы выбираете правило кеширования ответов, которое считывает данные из кеша или записывает их в него, это значение можно увидеть в 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. При регистрации приложений разработчика в Edge им присваиваются ключи API, которые можно использовать для создания токенов OAuth. Подробнее о том, как получать полные данные аналитики…

Если указанные выше критерии не соблюдены, вы увидите значение "(not set)". Также ознакомьтесь со статьей Что означает значение "(not set)" в объекте Аналитики.

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

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

Если указанные выше критерии не соблюдены, вы увидите значение "(not set)". Также ознакомьтесь со статьей Что означает значение "(not set)" в объекте Аналитики.

Адрес электронной почты разработчика, зарегистрированного в Edge, чье приложение выполнило вызовы API.

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

Если указанные выше критерии не соблюдены, вы увидите значение "(not set)". Также ознакомьтесь со статьей Что означает значение "(not set)" в объекте Аналитики.

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

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

Если указанные выше критерии не соблюдены, вы увидите значение "(not set)". Также ознакомьтесь со статьей Что означает значение "(not set)" в объекте Аналитики.

Код ошибки. Пример: 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.

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

Значение также сохраняется в 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  – нулевое значение, задайте для 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.

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

Например, в целевом объекте http://mocktarget.apigee.net из примера Apigee есть несколько ресурсов, в том числе ресурс /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 переменной потока.

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

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

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

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

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