Documentation de référence sur les métriques, les dimensions et les filtres d'Analytics

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X.
en savoir plus

Cet article est une documentation de référence sur les métriques, les dimensions et les filtres d'analyse. Pour obtenir plus de contexte sur leur utilisation, voir Présentation des données analytiques sur l'API.

Cette page présente les noms des métriques et des dimensions tels qu'ils apparaissent dans l'interface utilisateur et leur utilisation dans des appels d'API.

Métriques

Vous trouverez ci-dessous les métriques d'API que vous pouvez récupérer dans des rapports personnalisés et des appels d'API de gestion.

Nom des rapports personnalisés Nom à utiliser dans l'API de gestion distantes Description
Nombre moyen de transactions par seconde tps Aucun

Nombre moyen de transactions, c'est-à-dire de requêtes de proxy d'API, par seconde. Sachez que si vous comptez un nombre relativement faible de transactions sur la période, le nombre moyen de transactions par seconde peut sembler égal à zéro dans les rapports personnalisés d'interface utilisateur lorsque le nombre est inférieur à deux décimales.

Syntaxe de l'API : tps

Succès de cache (hit) cache_hit sum (somme)

Nombre de requêtes d'API réussies utilisant le cache réponse au lieu de la réponse du service cible.

Syntaxe de l'API : sum(cache_hit)

Nombre d'éléments de cache L1 ax_cache_l1_count moy, min, max

Renvoie le nombre d'éléments dans le cache L1 (en mémoire) par transaction sur une période donnée. Par exemple, si vous choisissez max pour la période d'une journée et que le nombre d'éléments en cache le plus élevé est de 12 pour une transaction spécifique, le nombre sera de 12. Pour avg, s'il y a trois transactions dans la période que vous interrogez et que leur nombre de caches est de 5, 6 et 7, la moyenne est de 6. Le cache L1 est un cache en mémoire, contrairement au cache de base de données L2, comme décrit dans la section Composants internes du cache.

Syntaxe de l'API : avg(ax_cache_l1_count)

Erreurs liées aux règles policy_error sum (somme)

Nombre total d'erreurs liées aux règles sur la période spécifiée.

Les erreurs liées aux règles se produisent généralement en raison de leur conception. Par exemple, la règle de vérification des clés API génère une erreur lorsqu'une clé API non valide est transmise dans la requête, et une règle Spike Arrest génère une erreur si le nombre d'appels d'API dépasse la limite définie dans la règle. Cette métrique est donc utile pour détecter les éventuels problèmes dans vos API. Par exemple, les métriques policy_error, regroupées par dimension developer_app, peuvent vous aider à découvrir l'expiration d'une clé API ou d'un jeton OAuth pour une application donnée. Vous constaterez peut-être qu'un proxy d'API génère de nombreuses erreurs Spike Arrest, et réaliserez donc que la limite de ce proxy ne tient pas compte d'une augmentation du trafic en période de vacances.

Une erreur liée aux règles est uniquement journalisée dans les analyses si elle entraîne un échec du proxy de l'API. Par exemple, si l'attribut continueOnError d'une stratégie est défini sur true, le proxy d'API continue à traiter une requête, même en cas d'échec de la règle. Dans ce cas, les erreurs liées aux règles ne sont pas journalisées dans les analyses.

La dimension du nom de la règle produisant une erreur (ax_execution_fault_nom_policy) sert à regrouper les erreurs liées aux règles par nom.

Une défaillance de cible (telle que 404 ou 503) ne compte pas pour un échec de règle, mais plutôt comme un échec de proxy d'API (is_error).

Syntaxe de l'API : sum(policy_error)

Erreurs de proxy is_error sum (somme)

Nombre total de fois où les proxys d'API ont échoué sur la période spécifiée. L'échec de proxy peut survenir en cas d'échec d'une règle ou d'exécution, telle qu'un code 404 ou 503 renvoyé par le service cible.

La dimension Proxy (apiproxy) est utile pour regrouper les erreurs de proxy d'API par proxy.

Syntaxe de l'API : sum(is_error)

Latence de traitement de la demande request_processing_latency moy, min, max

Temps (moyenne, minimale ou maximale), en millisecondes, nécessaire à Edge pour traiter les requêtes entrantes. L'heure commence lorsque la requête atteint Edge et se termine lorsque Edge transmet la requête au service cible.

À l'aide des différentes dimensions, vous pouvez examiner les latences de traitement des requêtes par proxy d'API, application de développeur, région, etc.

Syntaxe de l'API : max(request_processing_latency)

Taille d'une requête request_size somme, moyenne, min, max

La taille de la charge utile de la requête reçue par Edge, en octets.

Syntaxe de l'API : avg(request_size)

Cache de réponse exécuté ax_cache_executed sum (somme)

Nombre total d'exécutions d'une règle de cache de réponse au cours de la période donnée.

Étant donné que la règle de cache de réponse est associée à deux emplacements d'un proxy d'API (dans la demande et fois dans la réponse), elle s'exécute généralement deux fois dans un appel d'API. Un cache "get" et un cache "put" comptent chacun pour une exécution.

Toutefois, l'exécution du cache de réponse est égale à 0 si l'élément <SkipCacheLookup> de la règle renvoie la valeur true (dans la requête) et 0 si l'élément <SkipCachePopulation> de la règle renvoie valeur true (dans la réponse).

Dans l'outil Trace, vous pouvez cliquer sur l'icône de cache de réponse dans un appel d'API exécuté et afficher la variable de flux responsecache.executed pour vérifier l'exécution de cache (valeur de 1).

Syntaxe de l'API : sum(ax_cache_executed)

Latence de traitement de la réponse response_processing_latency moy, min, max

Temps (moyenne, minimale ou maximale), en millisecondes, nécessaire à Edge pour traiter les réponses de l'API. Cette durée commence lorsque le proxy d'API reçoit la réponse du service cible et se termine lorsque Apigee transmet la réponse à l'appelant d'origine.

À l'aide des différentes dimensions, vous pouvez examiner les latences de traitement de réponse par proxy d'API, région, etc.

Syntaxe de l'API : min(response_processing_latency)

Taille d'une réponse response_size somme, moyenne, min, max

Taille de la charge utile de réponse renvoyée au client, en octets.

Syntaxe de l'API : max(response_size)

Erreurs de cible target_error sum (somme)

Nombre total de réponses 5xx du service cible. Ce sont des erreurs de service cible non causées par Apigee.

Syntaxe de l'API : sum(target_error)

Temps de réponse cible target_response_time somme, moyenne, min, max

Durée (somme, moyenne, minimale ou maximale) en millisecondes, pendant laquelle le serveur cible répond à un appel. Cette métrique vous indique les performances des serveurs cibles. L'heure commence lorsque Edge transmet une demande au service cible et se termine lorsque Edge reçoit la réponse.

Sachez que si un appel d'API renvoie une réponse du cache (à l'aide de la règle de réponse du cache, par exemple), l'appel n'atteindra jamais le service cible et aucune métrique de temps de réponse cible n'est journalisée.

Syntaxe de l'API : avg(target_response_time)

Temps de réponse total total_response_time somme, moyenne, min, max

Temps (somme, moyenne, minimum ou maximum), en millisecondes, entre le moment où Edge reçoit une requête d'un client et celui où Edge renvoie la réponse au client. La durée comprend la surcharge du réseau (temps nécessaire aux équilibreurs de charge et aux routeurs), la latence de traitement des requêtes, la latence de traitement des réponses et le temps de réponse cible (si la réponse est émise par le service cible au lieu du cache).

À l'aide des différentes dimensions, vous pouvez examiner les latences de traitement par proxy d'API, application de développeur, région, etc.

Syntaxe de l'API : avg(total_response_time)

Trafic message_count pondérée

Nombre total d'appels d'API traités par Edge au cours de la période spécifiée.

Utilisez les dimensions pour regrouper le comptage du trafic de la manière qui vous convient le mieux.

Syntaxe de l'API : sum(message_count)

Dimensions

Les dimensions vous permettent d'afficher les métriques dans des groupes pertinents. Par exemple, le comptage total du trafic devient bien plus efficace lorsque vous l'affichez pour chaque application de développeur ou proxy d'API.

Voici les dimensions prêtes à l'emploi qu'Apigee fournit. En outre, vous pouvez créer vos propres dimensions, comme décrit dans l'article Analyser le contenu du message de l'API à l'aide d'analyses personnalisées.

Nom des rapports personnalisés Nom à utiliser dans l'API de gestion Description
Entités Apigee
Jeton d'accès access_token Jeton d'accès OAuth de l'utilisateur final de l'application.
Produit d'API api_product

Nom du produit d'API contenant les proxys d'API appelés. Pour obtenir cette dimension, les applications de développeur qui effectuent les appels doivent être associées à un ou plusieurs produits d'API contenant les proxys d'API, et les proxys appelés doivent rechercher une clé API ou un jeton OAuth transmis avec l'appel d'API. La clé ou le jeton est associé à un produit d'API. Pour plus d'informations, voir Tout d'abord: comment générer des données d'analyse complètes.

Si les critères ci-dessus ne sont pas remplis, la valeur "(not set)" s'affiche. Voir également la section Signification d'une valeur d'entité d'analyse "(not set)".

Clé du cache ax_cache_key

Clé contenant la valeur du cache de réponse consulté. Pour plus d'informations sur la construction de la clé pour le cache de réponse, consultez l'article Règle de réponse du cache.

Dans l'outil Trace, lorsque vous sélectionnez une règle de réponse de cache lue ou écrite dans le cache, vous pouvez voir cette valeur dans la variable de flux responsecache.cachekey.

Nom du cache ax_cache_name

Nom du cache contenant les clés/valeurs utilisées par la règle Response Cache, précédé du préfixe orgName__envName__. Par exemple, si l'organisation est "foo", l'environnement est "test", et le nom du cache est "myCache", ax_cache_name est foo__test__myCache.

Dans l'outil Trace, lorsque vous sélectionnez une règle de cache de réponse, vous pouvez voir cette valeur dans la variable de flux responsecache.cachename.

Source du cache ax_cache_source

Niveau de cache (base de données "L1" ou "L2 en mémoire") à partir duquel le cache de réponse a été récupéré. Cette dimension indique également "CACHE_MISS" lorsque la réponse a été envoyée par la cible au lieu du cache (le cache de la réponse a été actualisé avec la réponse de la cible) ou lorsqu'une clé de cache de la requête n'est pas valide. Les clés de cache sont limitées à 2 Ko.

Dans l'outil Trace, lorsque vous sélectionnez la règle de cache de réponse, vous pouvez voir cette valeur dans la variable de flux responsecache.cachesource.

Pour plus d'informations sur les niveaux de cache, reportez-vous à la section Composants internes du cache.

ID client client_id

La clé client (clé API) de l'application de développeur qui effectue les appels d'API, qu'elle soit transmise dans la requête en tant que clé API ou incluse dans les jetons OAuth.

Pour obtenir cette dimension, les proxys recevant des appels doivent être configurés pour rechercher une clé API ou un jeton OAuth valide. Les applications de développement obtiennent des clés API, qui peuvent être utilisées pour générer des jetons OAuth, lorsque les applications sont enregistrées dans Edge. Pour plus d'informations, voir Tout d'abord: comment générer des données d'analyse complètes.

Si les critères ci-dessus ne sont pas remplis, la valeur "(not set)" s'affiche. Voir également la section Signification d'une valeur d'entité d'analyse "(not set)".

Application de développeur developer_app

L'application de développement enregistrée par Edge effectuant des appels d'API.

Pour obtenir cette dimension, les applications doivent être associées à un ou plusieurs produits d'API contenant les proxys d'API appelés, puis les proxys doivent rechercher une clé API ou un jeton OAuth envoyé avec l'appel d'API. La clé ou le jeton identifie l'application du développeur. Pour plus d'informations, consultez la section Tout d'abord: Comment générer des données d'analyse complètes.

Si les critères ci-dessus ne sont pas remplis, la valeur "(not set)" s'affiche. Voir également la section Signification d'une valeur d'entité d'analyse "(not set)".

Adresse e-mail du développeur developer_email

E-mail des développeurs enregistrés par Edge dont l'application a effectué les appels d'API.

Pour obtenir cette dimension, les développeurs doivent associer les applications à un ou plusieurs produits d'API contenant les proxys d'API appelés, puis les proxys doivent rechercher une clé API ou un jeton OAuth envoyé avec l'appel d'API. La clé ou le jeton identifie l'application du développeur. Pour plus d'informations, consultez la section Tout d'abord: Comment générer des données d'analyse complètes.

Si les critères ci-dessus ne sont pas remplis, la valeur "(not set)" s'affiche. Voir également la section Signification d'une valeur d'entité d'analyse "(not set)".

ID de développeur développeur

ID de développeur unique généré par Edge sous la forme org_name@@@unique_id.

Pour obtenir cette dimension, les développeurs doivent associer les applications à un ou plusieurs produits d'API qui contiennent les proxys d'API appelés, puis les proxys doivent rechercher une clé API ou un jeton OAuth envoyé avec les appels d'API. La clé ou le jeton identifie le développeur. Pour plus d'informations, voir Tout d'abord: comment générer des données d'analyse complètes.

Si les critères ci-dessus ne sont pas remplis, la valeur "(not set)" s'affiche. Voir également la section Signification d'une valeur d'entité d'analyse "(not set)".

Environnement de production Environnement périphérique dans lequel les proxys d'API sont déployés. Par exemple, "test" ou "prod".
Code d'erreur de l'erreur ax_edge_execution_fault_code

Le code d'erreur de l'erreur. Par exemple : messaging.adaptors.http.flow.GatewayTimeout

Nom du flux en cas d'erreur ax_execution_fault
  _flow_name

Le flux nommé dans un proxy d'API qui a généré une erreur. Par exemple, "PreFlow", "PostFlow" ou le nom d'un flux conditionnel que vous avez créé.

Notez que le nom complet à utiliser dans l'API de gestion est ax_execution_fault_flow_name, sans saut de ligne.

Si aucune erreur ne s'est produite, la valeur "(not set)" s'affiche.

Ressource de flux flow_resource Utilisation avec Apigee uniquement. Si vous êtes curieux, consultez ce post destiné à la communauté.
État du flux en cas d'erreur ax_execution_fault
  _flow_state

Non des états de flux de proxy d'API qui ont généré des erreurs, comme "PROXY_REQ_FLOW" ou "TARGET_RESP_FLOW".

Notez que le nom complet à utiliser dans l'API de gestion est ax_execution_fault_flow_state, sans saut de ligne.

ID de flux de passerelle gateway_flow_id Lorsque les appels d'API se déplacent dans Edge, chaque appel obtient son propre ID de flux de passerelle. Exemple : rrt329ea-12575-114653952-1. L'ID de flux de passerelle est utile pour distinguer les métriques en cas de nombre élevé de tâches par seconde, lorsque d'autres dimensions telles que l'organisation, l'environnement et l'horodatage sont identiques entre les appels.
Organisation organisation Organisation Edge dans laquelle les proxys d'API sont déployés.
Nom de la règle en cas d'erreur ax_execution_fault
  _policy_name

Nom de la règle qui a généré une erreur et entraîné l'échec de l'appel d'API.

Notez que le nom complet à utiliser dans l'API de gestion est ax_execution_fault_policy_name, sans saut de ligne.

Si une règle génère une erreur, mais que l'attribut racine de la règle continueOnError est défini sur true, le flux du proxy d'API se poursuit sans échec, et l'échec de la règle n'est pas comptabilisé dans cette dimension.

Proxy apiproxy Nom de la machine (et non du nom à afficher) d'un proxy d'API.
Chemin de base du proxy proxy_basepath

Chemin de base configuré sur le proxy d'API ProxyEndpoint. Le chemin de base n'inclut pas la partie correspondant au domaine et au port de l'URL du proxy d'API. Par exemple, si l'URL de base d'un proxy d'API est https://apigeedocs-test.apigee.net/releasenotes/, le chemin de base est /releasenotes.

La valeur est également stockée dans la variable de flux proxy.basepath.

Suffixe du chemin de proxy proxy_pathsuffix

Chemin d'accès à la ressource ajouté au chemin de base du proxy d'API. Par exemple, si l'URL de base d'un proxy d'API est https://apigeedocs-test.apigee.net/hello/ et qu'un appel est effectué vers https://apigeedocs-test.apigee.net/hello/json, le suffixe de chemin est /json.

Si aucun suffixe de chemin n'est utilisé, la valeur est vide.

La valeur est également stockée dans la variable de flux proxy.pathsuffix.

Révision du proxy apiproxy_revision Numéro de révision du proxy d'API ayant géré les appels d'API. Cela ne signifie pas nécessairement la dernière révision d'un proxy d'API. Si un proxy d'API comporte 10 révisions, la 8e révision peut actuellement être déployée. En outre, une API peut avoir plusieurs révisions déployées tant que les révisions ont des chemins de base différents, comme décrit dans Déployer des proxys dans l'interface utilisateur.
Adresse IP client résolue ax_resolved_client_ip

Contient l'adresse IP du client d'origine. La valeur de la dimension ax_resolved_client_ip est calculée à partir des valeurs des dimensions ax_true_client_ip et x_forwarded_for_ip.

Notez que lorsque vous utilisez des produits de routage tels qu'Akamai pour capturer les adresses IP réelles des clients, l'adresse IP du client est transmise à Edge dans l'en-tête HTTP True-Client-IP, qui est ensuite utilisée pour définir la dimension ax_true_client_ip.

La valeur de la dimension ax_resolved_client_ip est calculée comme suit :

  1. Si ax_true_client_ip n'est pas nul et ne contient pas d'adresse IP locale, définissez ax_resolved_client_ip sur ax_true_client_ip.
  2. Sinon, définissez ax_resolved_client_ip sur la première adresse IP non locale de x_forwarded_for_ip.
  3. Si ax_true_client_ip et x_forwarded_for_ip ne contiennent que des adresses IP locales, définissez ax_resolved_client_ip sur la première adresse IP locale de x_forwarded_for_ip.
  4. Si ax_true_client_ip et x_forwarded_for_ip sont tous deux nuls, définissez ax_resolved_client_ip sur (not set).
  5. Si ax_true_client_ip est une adresse IP locale et que x_forwarded_for_ip est nul, définissez ax_resolved_client_ip sur (not set).
Code d'état de la réponse response_status_code Code d'état de la réponse HTTP transmis d'Apigee au client, tel que 200, 404, 503, etc. Dans Edge, le code d'état de la réponse de la cible peut être remplacé par des stratégies telles que Assign Message et Aware Fault, c'est pourquoi cette dimension peut différer du code de réponse cible (target_response_code).
Hôte virtuel virtual_host Nom de l'hôte virtuel vers lequel l'appel d'API a été effectué. Par exemple, les organisations disposent de deux hôtes virtuels par défaut: default (http) et secure (https).
Entrant/client
Adresse IP du client client_ip Adresse IP du système qui atteint le routeur, tel que le client d'origine (proxy_client_ip) ou un équilibreur de charge. Lorsqu'il existe plusieurs adresses IP dans l'en-tête X-Forwarded-For, il s'agit de la dernière adresse IP répertoriée.
Catégorie d'appareil ax_ua_device_category Type d'appareil à partir duquel l'appel API a été effectué, tel que "Tablette" ou "Smartphone".
Famille d'OS ax_ua_os_family La famille du système d'exploitation de l'appareil effectuant l'appel, telle que "Android" ou "iOS".
Version d'OS ax_ua_os_version

Version du système d'exploitation de l'appareil effectuant l'appel.

Il est utile d'utiliser cet élément comme deuxième dimension détaillée avec la famille d'OS (ax_ua_os_family) pour afficher les versions des systèmes d'exploitation.

Adresse IP du client proxy proxy_client_ip

Adresse IP du client à l'origine de l'appel, stockée dans la variable de flux proxy.client.ip. Il s'agit souvent de l'adresse X-Forwarded-For de l'appel entrant, qui correspond à l'adresse IP Edge reçue lors du dernier handshake TCP externe. Il peut s'agir du client à l'origine de l'appel ou d'un équilibreur de charge. Lorsqu'il existe plusieurs adresses IP dans l'en-tête X-Forwarded-For, il s'agit de la dernière adresse IP répertoriée.

Adresse IP du client référée ax_true_client_ip

Lorsque vous utilisez des produits de routage tels qu'Akamai pour capturer les adresses IP réelles des clients, ces adresses sont transmises à Edge dans l'en-tête HTTP True-Client-IP. Cette dimension capture les adresses IP réelles à partir de cet en-tête.

Pour déterminer l'adresse IP du client d'origine, accessible via la dimension ax_resolved_client_ip, Edge utilise les dimensions ax_true_client_ip et x_forwarded_for_ip.

Chemin de requête request_path

Chemin d'accès à la ressource (hors domaine) du service cible, à l'exclusion des paramètres de requête.

Par exemple, l'exemple de cible Apigee http://mocktarget.apigee.net comprend plusieurs ressources, dont /user, qui renvoie un message d'accueil. Quelle que soit la manière dont votre proxy d'API appelle http://mocktarget.apigee.net/user, le chemin de requête est /user.

URI de la requête request_uri

Chemin d'accès à la ressource (hors domaine) du service cible, y compris les paramètres de requête.

Par exemple, l'exemple de cible http://mocktarget.apigee.net Apigee comprend plusieurs ressources, telles que la ressource /user?user={name} et le paramètre de requête, qui permettent de renvoyer un message d'accueil personnalisé au nom spécifié. Quelle que soit la manière dont votre proxy d'API appelle http://mocktarget.apigee.net/user?user=Dude, l'URI de la demande est /user?user=Dude.

Demander un verbe request_verb Verbe de requête HTTP dans les requêtes d'API, tel que GET, POST, PUT, DELETE.
User-agent User-agent

Nom de l'user-agent ou du software-agent utilisé pour effectuer l'appel d'API. Exemples :

  • Un pixel XL effectuant un appel via 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
  • Un iPad effectuant un appel via 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 depuis un terminal : curl/7.51.0
Famille d'user-agent ax_ua_agent_family Famille de l'user-agent, telle que "Chrome Mobile" ou "cURL".
Type d'user-agent ax_ua_agent_type Type d'user-agent, tel que "Navigateur", "Navigateur mobile", "Bibliothèque", etc.
Version d'user-agent ax_ua_agent_version

Version de l'user-agent.

Il est utile d'utiliser cet élément comme deuxième dimension détaillée avec la famille d'user-agent (ax_ua_agent_family) pour afficher la version de la famille d'agent.

Sortant/cible
Chemin de base cible target_basepath

Chemin d'accès à la ressource (hors domaine) du service cible, à l'exclusion des paramètres de requête, défini dans le <TargetEndpoint> du proxy.

Par exemple, supposons qu'un proxy d'API appelle la cible suivante :

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

Dans cet exemple, la valeur du chemin de base cible est /user.

Si la cible était la suivante :

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

la valeur du chemin de base serait nulle.

Dans l'outil Trace, lorsque vous sélectionnez l'icône AX à la fin du schéma de flux, la variable de flux target.basepath est mappée à la dimension du chemin d'accès cible.

Hôte cible target_host Hôte du service cible. Par exemple, si un proxy d'API appelle http://mocktarget.apigee.net/help, l'hôte cible est mocktarget.apigee.net.
Adresse IP cible target_ip Adresse IP du service cible renvoyant la réponse au proxy d'API.
Code de réponse cible target_response_code

Code d'état de la réponse HTTP renvoyé par le service cible au proxy d'API, tel que 200, 404, 503, etc.

Une valeur "null" signifie que la requête n'a jamais atteint le service cible. Cela se produit lorsque la réponse est diffusée par la règle de réponse du cache ou en cas d'échec du traitement de la requête.

Cette méthode est différente de la dimension Code d'état de la réponse (response_status_code).

URL cible target_url

URL complète du service cible défini dans le TargetEndpoint d'un proxy d'API.

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

Dans cet exemple, l'url cible est http://mocktarget.apigee.net/user?user=Dude.

Notez que l'URL peut également être remplacée lors du traitement du proxy d'API avec la variable de flux target.url.

Dans le chaînage de proxy et lors de l'utilisation de cibles de script (Node.js), le champ target_url du proxy appelant est nul.

X Forwarded For x_forwarded_for_ip

Liste des adresses IP de l'en-tête X-Forwarded-For.

Pour déterminer l'adresse IP du client d'origine, accessible via la dimension ax_resolved_client_ip, Edge utilise les dimensions ax_true_client_ip et x_forwarded_for_ip.

Heure
Jour de la semaine ax_day_of_week Abréviation à trois lettres du jour durant lequel les appels d'API ont été effectués. Par exemple, lun., mar., mer.
Mois ax_month_of_year Mois numérique durant duquel les appels d'API ont été effectués. Par exemple, "03" pour le mois de mars.
Heure de la journée ax_hour_of_day

Heure (format 24 heures) à 2 chiffres à laquelle les appels d'API ont été effectués. Par exemple, pour les appels d'API effectués entre 22h00 et 23h00, ax_hour_of_day indique 22.

La valeur temporelle est exprimée en UTC.

Time Zone ax_geo_timezone Noms communs des fuseaux horaires d'appels d'API, tels que Amérique/New_York et Europe/Paris
Semaine du mois ax_week_of_month Semaine numérique du mois. Par exemple, pour les appels d'API effectués au cours de la troisième semaine d'un mois, ax_week_of_month est égal à 3.
Location
Ville ax_geo_city Ville à partir de laquelle les appels d'API ont été effectués.
Continent ax_geo_continent Code à deux lettres du continent à partir duquel les appels API ont été effectués. Par exemple, NA pour l'Amérique du Nord.
Pays ax_geo_country Code à deux lettres du pays à partir duquel les appels API ont été effectués. Par exemple, US pour les États-Unis.
Région géographique ax_geo_region Le code composé pour la région géographique, sous le format ÉTAT-PAYS. Par exemple, Wa-US pour Washington-États-Unis.
Région ax_dn_region Nom du centre de données Apigee sur lequel des proxys d'API sont déployés, tel que us-east-1.
Monétisation
Message d'omission de la transaction de frappe x_apigee_mint_tx_ignoreMessage Indicateur spécifiant si les messages concernant la monétisation doivent être ignorés. Défini sur false pour toutes les organisations de monétisation.
État de la transaction x_apigee_mint_tx_status État d'une demande de monétisation (par exemple, succès, échec, invalide ou aucun).

Filtres

Les filtres vous permettent de limiter les résultats à des métriques présentant des caractéristiques spécifiques. Voici quelques exemples de filtres. Utilisez des noms de type API et de dimension lors de la définition des filtres

Renvoie les métriques des proxys d'API avec le nom du livre ou de la musique :

filter=(apiproxy in 'books','music')

Renvoie les métriques des proxys d'API dont le nom commence par "m" :

filter=(apiproxy like 'm%')

Renvoie les métriques des proxys d'API dont le nom ne commence pas par "m" :

filter=(apiproxy not like 'm%')

Renvoie les métriques pour les appels d'API avec un code d'état de réponse compris entre 400 et 599 :

filter=(response_status_code ge 400 and response_status_code le 599)

Renvoie des métriques pour les appels d'API avec un code d'état de réponse de 200 et un code de réponse cible de 404 :

filter=(response_status_code eq 200 and target_response_code eq 404)

Renvoie des métriques pour les appels d'API avec un code d'état de réponse de 500 :

filter=(response_status_code eq 500)

Renvoie les métriques des appels d'API qui n'ont pas entraîné d'erreur :

filter=(is_error eq 0)

Vous trouverez ci-dessous des opérateurs que vous pouvez utiliser pour créer des filtres de rapport.

Opérateur Description
in Inclure dans la liste
notin Exclure de la liste
eq Égal à, ==
ne Différent de, !=
gt Supérieur à, >
lt Inférieur à, <
ge Supérieur ou égal à, >=
le Inférieur ou égal à, <=
like Renvoie true si le modèle de chaîne correspond au modèle fourni.
not like Renvoie false si le modèle de chaîne correspond au modèle fourni.
similar to Renvoie true ou false selon la correspondance du modèle à la chaîne donnée. Il est semblable à like, sauf qu'il interprète le modèle à l'aide de la définition d'une expression régulière donnée par le standard SQL.
not similar to Renvoie false ou true selon la correspondance du modèle à la chaîne donnée. Il est semblable à not like, sauf qu'il interprète le modèle à l'aide de la définition d'une expression régulière donnée par le standard SQL.
and Vous permet d'utiliser "and" pour inclure plus d'une expression de filtre. Le filtre inclut des données qui répondent à toutes les conditions.
or Vous permet d'utiliser "our" pour évaluer différentes expressions de filtre possibles. Le filtre inclut des données qui répondent à au moins une des conditions.