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

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

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)

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)

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)

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)

Durée (moyenne, minimale ou maximale), en millisecondes qu’il prend Edge pour traiter les requêtes entrantes. L'heure commence lorsque la requête atteint Edge et se termine lorsqu'Edge transmet la demande 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)

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

Syntaxe de l'API : avg(request_size)

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)

Durée (moyenne, minimale ou maximale), en millisecondes qu'il faut 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 de la charge utile de réponse renvoyée au client, en octets.

Syntaxe de l'API : max(response_size)

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)

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)

La durée (somme, moyenne, minimum ou maximum), en millisecondes, entre le moment où Edge reçoit une requête d'un client et le moment 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)

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)

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 en savoir plus, consultez 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é 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 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.

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.

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 en savoir plus, consultez 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)".

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 Pour en savoir plus, consultez 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 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 le développeur l'application. Pour en savoir plus, consultez 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 unique généré par Edge sous la forme de 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 en savoir plus, consultez 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)".

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

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.

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.

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.

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.

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.

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 véritables adresses IP des clients, l'adresse IP du client est transmise à Edge dans l'en-tête HTTP True-Client-IP, qui est puis 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 contiennent tous les deux uniquement des adresses IP locales, définissez ax_resolved_client_ip sur première adresse IP locale dans 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).

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 à 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 est l'adresse IP Edge reçue lors de la dernière poignée de main 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.

Lorsque vous utilisez des produits de routage tels qu’Akamai pour capturer les véritables adresses IP des clients, les adresses IP des clients 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 ax_resolved_client_ip , Edge utilise les paramètres ax_true_client_ip et x_forwarded_for_ip dimensions.

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.

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.

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

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.

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.

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 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 proxy l'enchaînement et lors de l'utilisation de scripts cibles (Node.js), la valeur target_url du proxy appelant est nulle.

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

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

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.