Cette page s'applique à Apigee et à Apigee hybrid.
Consultez la documentation d'Apigee Edge.
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.
- Vous verrez les noms d'interface utilisateur lorsque vous créez et gérez des rapports personnalisés.
- Utilisez les noms spécifiques à l'API pour obtenir des métriques, créer une définition de rapport ou mettre à jour une définition de rapport.
Métriques
Vous trouverez ci-dessous les métriques d'API que vous pouvez récupérer dans les rapports personnalisés et les appels d'API Apigee.
Métrique | Nom à utiliser dans l'API Apigee | Functions | 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 : |
Succès de cache (hit) | cache_hit |
sum (somme) |
Nombre de requêtes d'API réussies utilisant le Syntaxe de l'API : |
Nombre d'éléments de cache L1 | ax_cache_l1_count |
moy, min, max |
Nombre d'éléments dans le cache L1 (en mémoire) par transaction sur une période donnée. Par exemple, si vous choisissez Syntaxe de l'API : |
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 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 La dimension du nom de la règle produisant une erreur ( Une défaillance de cible (telle que Syntaxe de l'API : |
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 La dimension Proxy ( Syntaxe de l'API : |
Latence de traitement des requêtes | request_processing_latency |
moy, min, max |
Durée (moyenne, minimale ou maximale) en millisecondes nécessaires à Apigee pour prendre en charge le traitement des requêtes entrantes. Cette durée commence lorsque la demande est soumise à Apigee et se termine lorsque Apigee 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 : |
Taille d'une requête | request_size |
somme, moyenne, min, max |
Taille de la charge utile de la demande reçue par Apigee, en octets. Syntaxe de l'API : |
Cache de réponse exécuté | ax_cache_executed |
sum (somme) |
Nombre total d'exécutions d'une règle Étant donné que la règle Toutefois, l'exécution du cache de réponse est égale à 0 si l'élément Dans l'outil Debug, vous pouvez cliquer sur l'icône Syntaxe de l'API : |
Latence de traitement des réponses | response_processing_latency |
moy, min, max |
Durée (moyenne, minimale ou maximale) en millisecondes nécessaire à Apigee 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 : |
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 : |
Erreurs de cible | target_error |
sum (somme) |
Nombre total de réponses Syntaxe de l'API : |
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. Cette durée commence lorsqu'Apigee transmet une requête au service cible et se termine lorsque Apigee reçoit la réponse. Sachez que si un appel d'API renvoie une réponse du cache (à l'aide de la règle Syntaxe de l'API : |
Temps de réponse total | total_response_time |
somme, moyenne, min, max |
Durée (somme, moyenne, minimale ou maximale ) en millisecondes entre la réception de la requête par Apigee et le renvoi de 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 : |
Trafic | message_count |
sum (somme) |
Nombre total d'appels d'API traités par Apigee 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 : |
Monétisation | |||
Frais | fees |
somme, moyenne, min, max |
Montant représentant les frais de configuration, les frais récurrents ou les crédits prépayés. Syntaxe de l'API : |
Part des revenus du développeur | x_apigee_mintng_dev_share |
somme, moyenne, min, max |
Part du développeur dans les revenus associés à une transaction. Apigee ne calcule la part du développeur que si vous avez activé le partage des revenus dans votre plan tarifaire. La part du développeur est calculée à l'aide de la formule suivante : x_apigee_mintng_dev_share = revShareGrossPrice * (share percentage)
La valeur correspondant au pourcentage de sa part est extraite de votre plan tarifaire. Syntaxe de l'API : |
Prix de monétisation | x_apigee_mintng_price |
somme, moyenne, min, max |
Revenu total d'une transaction.
Le revenu d'une transaction est défini sur la valeur de la variable de monétisation Syntaxe de l'API : |
Multiplicateur de prix d'API | x_apigee_mintng_price_multiplier |
somme, moyenne, min, max |
Facteur (multiplicateur) par lequel le coût par transaction est multiplié. Le coût par transaction est spécifié dans les frais basés sur la consommation du plan tarifaire. Syntaxe de l'API : |
Taux de monétisation | x_apigee_mintng_rate |
somme, moyenne, min, max |
Taux facturé pour une transaction. Le taux facturé pour une transaction est calculé à l'aide de la formule suivante : x_apigee_mintng_rate = (consumption-based pricing rate) * perUnitPriceMultiplier value
La valeur du taux de tarification basée sur la consommation est extraite de votre plan tarifaire. La valeur Syntaxe de l'API : |
Variables
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.
Dimension | Nom à utiliser dans l'API Apigee | Description |
---|---|---|
Jeton d'accès | access_token |
Jeton d'accès OAuth de l'utilisateur final de l'application. |
Produit d'API | api_product |
|
Clé du cache | ax_cache_key |
Clé contenant la valeur du Dans l'outil de débogage, lorsque vous sélectionnez une règle |
Nom du cache | ax_cache_name |
Nom du cache contenant les clés/valeurs utilisées par la règle Dans l'outil de débogage, lorsque vous sélectionnez une règle |
Source du cache | ax_cache_source |
Niveau de cache (base de données L1 ou L2 en mémoire) à partir duquel Dans l'outil de débogage, lorsque vous sélectionnez la règle Pour plus d'informations sur les niveaux de cache, reportez-vous à la section Composants internes du cache. |
ID client | client_id |
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éveloppeur obtiennent des clés API, qui peuvent être utilisées pour générer des jetons OAuth, lorsque les applications sont enregistrées dans Apigee. Pour en savoir plus, consultez l'article Générer des données d'analyse complètes. Si les critères ci-dessus ne sont pas remplis, la valeur |
Application de développeur | developer_app |
Application de développeur enregistrée dans Apigee 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 de développeur. Pour plus d'informations, consultez l'article Générer des données d'analyse complètes. Si les critères ci-dessus ne sont pas remplis, la valeur |
Adresse e-mail du développeur | developer_email |
|
ID de développeur | developer |
ID de développeur unique généré par Apigee sous la forme 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 l'article Générer des données d'analyse complètes. Si les critères ci-dessus ne sont pas remplis, la valeur |
Environnement | environment |
Environnement Apigee de déploiement des proxys API. 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 : |
Nom du flux en cas d'erreur | ax_execution_fault |
Nom du flux dans un proxy d'API qui a généré une erreur. Par exemple, Notez que le nom complet à utiliser dans l'API Apigee est Si aucune erreur ne s'est produite, la valeur |
Ressource de flux | flow_resource |
Utilisation avec Apigee uniquement. Consultez l'article Comment utiliser la dimension "Flux de ressources" dans Analytics si vous êtes curieux. |
État du flux en cas d'erreur | ax_execution_fault |
Non des états de flux de proxy d'API qui ont généré des erreurs, comme Notez que le nom complet à utiliser dans l'API Apigee est |
ID de flux de passerelle | gateway_flow_id |
Lorsque les appels d'API passent par Apigee, chaque appel reçoit 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 | organization |
Organisation Apigee de déploiement des proxys d'API. |
Nom de la règle en cas d'erreur | ax_execution_fault |
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 Apigee est Si une règle génère une erreur, mais que l'attribut racine de la règle |
Proxy | apiproxy |
Nom de la machine (et non le 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 La valeur est également stockée dans la variable de flux |
Type de déploiement du proxy | proxy_deployment_type |
Type de proxy d'API pour les proxys déployés. La spécification d'un type de proxy limite les résultats à ce type de proxy. Cette dimension ne s'applique qu'aux utilisateurs du paiement à l'usage et de l'abonnement 2024, qui utilisent des types de proxys. Les valeurs potentielles sont |
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 Si aucun La valeur est également stockée dans la variable de flux |
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 compter plusieurs révisions déployées tant que les révisions disposent chemins de base différents, comme décrit dans la section Déployer des proxys. |
Adresse IP client résolue | ax_resolved_client_ip |
Adresse IP du client d'origine. La valeur de la dimension Sachez 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 à Apigee dans l'en-tête HTTP La valeur de la dimension
|
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 Apigee, le code d'état de la réponse de la cible peut être écrasé par des règles telles que la règle d'attribution de message et celle de génération d'erreur, et 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 auquel l'appel d'API a été effectué. Pour en savoir plus, consultez la section À propos des environnements et des groupes d'environnements. |
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 Tablet ou Smartphone . |
Famille d'OS | ax_ua_os_family |
Famille de 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 de l'utiliser comme deuxième dimension détaillée avec la famille du système d'exploitation (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 |
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, les adresses IP client sont transmises à Apigee dans l'en-tête HTTP Pour déterminer l'adresse IP du client d'origine, accessible via la dimension |
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 |
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 |
Demander un verbe | request_verb |
Verbe de requête HTTP dans les requêtes d'API, tel que GET, POST, PUT, DELETE. |
User-agent | useragent |
Nom de l'user-agent ou du software-agent utilisé pour effectuer l'appel d'API. Par exemple :
|
Famille d'user-agent | ax_ua_agent_family |
Famille de l'user-agent, tel que Chrome Mobile ou curl . |
Type d'user-agent | ax_ua_agent_type |
Type d'user-agent, tel que Browser , Mobile Browser , Library , 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 | ||
Cible | target |
Point de terminaison cible qui a traité la requête. Par exemple, default . |
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 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 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 de débogage, lorsque vous sélectionnez l'icône AX à la fin du schéma de flux, la variable de flux |
Nom du service gRPC | x_apigee_grpc_service_name |
Applicable uniquement lorsque le service cible est un service gRPC. Nom du service gRPC. Pour en savoir plus sur les proxys gRPC, consultez la page Créer des proxys d'API gRPC. |
État gRPC | x_apigee_grpc_status |
Applicable uniquement lorsque le service cible est un service gRPC. État de la requête gRPC. Pour en savoir plus sur les proxys gRPC, consultez la page Créer des proxys d'API gRPC. |
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 Une valeur Cette méthode est différente de la dimension Code d'état de la réponse (response_status_code). |
Nom du RPC gRPC | x_apigee_grpc_rpc_name |
Applicable uniquement lorsque le service cible est un service gRPC. Nom du RPC. Pour en savoir plus sur les proxys gRPC, consultez la page Créer des proxys d'API gRPC. |
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 Notez que l'URL peut également être remplacée lors du traitement du proxy d'API avec la variable de flux Dans Chaînage de proxy, l'URL cible du proxy appelant est nulle. |
X-Forwarded-For IP | x_forwarded_for_ip |
Liste des adresses IP de l'en-tête Pour déterminer l'adresse IP du client d'origine, accessible via la dimension |
X-Forwarded-For Proto | x_forwarded_proto |
Protocole utilisé par le client pour se connecter au routeur. Les valeurs valides incluent |
Time | ||
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. |
Fuseau horaire | ax_geo_timezone |
Noms communs des fuseaux horaires d'appels d'API, tels que America/New_York et Europe/Dublin . |
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 (Emplacement) | ||
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. |
Country (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 STATE-COUNTRY . Par exemple, WA-US pour Washington-États-Unis. |
Region (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 | ||
Création | created |
Actuellement disponible dans les organisations Apigee, mais pas dans les organisations Apigee hybrid. Horodatage Unix lorsque le barème des frais a été ajouté pour le développeur d'applications et le produit d'API. |
Type de frais | fees_type |
Type de frais. Il peut s'agir de frais de configuration, de frais récurrents ou de crédits prépayés. Cette valeur n'est renseignée que si vous avez sélectionné la métrique Fees . |
Devise du revenu | x_apigee_mintng_currency |
|
Identifiant du plan tarifaire | x_apigee_mintng_rate_plan_id |
Actuellement disponible dans les organisations Apigee, mais pas dans les organisations Apigee hybrid Plan de taux de monétisation pour le développeur d'applications. |
Réussite de la transaction | x_apigee_mintng_tx_success |
L'état de monétisation de la transaction est défini sur la valeur de la variable de monétisation transactionSuccess capturée dans votre règle DataCapture. |
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 des 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)
Renvoie les métriques des appels d'API qui n'ont pas renvoyé de réponses null
:
filter=(response_status_code isnot null)
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 |
is |
Utilisez response_status_code is null pour filtrer les réponses dont le code d'état est null . |
isnot |
Utilisez response_status_code isnot null pour filtrer les réponses dont le code d'état est différent de null . |
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 OR pour évaluer différentes expressions de filtre possibles. Le filtre inclut des données qui répondent à au moins une des conditions. |