Questions fréquentes

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

Vous trouverez ci-dessous des questions fréquentes:

Apigee recommande les approches suivantes:

  1. Commencez par configurer des alertes pour n'importe quel proxy d'API avec un seuil spécifique. Par exemple, un taux d'erreur 4xx de 10% pendant 5 minutes. Configurez les notifications et consultez la page Historique des alertes pour surveiller les alertes déclenchées. Configurez des alertes et des notifications supplémentaires pour des proxys d'API et des services cibles spécifiques. Continuez à affiner les alertes et les notifications en fonction de vos observations.
  2. Demandez aux équipes chargées du développement des API de recommander des seuils de taux d'erreur et de latence à l'équipe chargée des opérations en charge de la configuration des alertes.

Quels rôles peuvent accéder à la surveillance des API ?

Voir À propos des rôles de surveillance de l'API.

Pourquoi tous les proxys d'API ne sont-ils pas répertoriés sur la page récente ?

Le tableau de bord Récent affiche uniquement les mandataires d'API ayant eu du trafic dans un passé récent. Il n'affiche pas tous les proxys d'API de votre organisation. Le tableau de bord Timeline vous permet d'afficher les données de tous les proxys d'API.

Pourquoi ne vois-je pas de graphiques de latence dans la chronologie ?

Les graphiques de latence ne s'affichent dans la chronologie que si vous sélectionnez une région et un proxy d'API, et si la période sélectionnée ne dépasse pas 7 jours.

Les journaux sont utiles pour identifier les codes d'état qui provoquent des erreurs, mais comment identifier les ID de développeur qui génèrent les appels ?

Les ID de développeur ne sont pas inclus dans les journaux de surveillance de l'API. Pour récupérer les ID de développeur, vous pouvez générer un rapport personnalisé.

Puis-je surveiller une chaîne de proxy ?

Vous pouvez utiliser un proxy d'API comme point de terminaison cible d'un autre proxy d'API, connectant ainsi les deux proxys dans une chaîne de proxy. Cependant, API Monitoring enregistre uniquement les requêtes au premier proxy de la chaîne, et non au proxy API utilisé comme cible. Pour en savoir plus, consultez la section Enchaîner des proxys d'API.

Pourquoi vois-je « non défini » dans les tableaux de bord ?

Si le proxy de l'API, la source d'erreur, le code d'erreur ou la politique d'erreur n'a pas de valeur ou ne peut pas être déterminé, le tableau de bord affichera "non défini" comme origine. Voici quelques exemples de scénarios pouvant entraîner la non-définition de la valeur "not set" :

  • Erreurs liées au client
  • Codes d'erreur HTTP remplacés par la réponse de réussite
  • Codes d'état HTTP 2xx (car ils ne génèrent généralement pas de codes d'erreur)

Pour plus d'informations sur "non défini", consultez Que signifie une valeur d'entité d'analyse "(non définie)" ?

La surveillance des API est-elle disponible dans l'interface utilisateur classique ou Edge pour le cloud privé ?

La surveillance des API Apigee est actuellement disponible uniquement pour les clients Apigee Edge Cloud utilisant la nouvelle interface utilisateur Edge.

La surveillance de l'API Apigee n'est pas disponible dans l'interface utilisateur Classic Edge ni dans Edge for Private Cloud.

Qu'est-ce qu'un playbook ?

Lorsque vous configurez une alerte, dans le champ "Playbook", vous fournissez une brève description des actions recommandées pour résoudre les alertes lorsqu'elles se déclenchent. Vous pouvez également indiquer un lien vers votre wiki ou la page de votre communauté sur laquelle vous référencez les bonnes pratiques. Les informations contenues dans ce champ seront incluses dans la notification.

Comment gérer les codes d’erreur HTTP 429 ?

La règle de quota Edge et la règle SpikeArrest émettent toutes deux un code d'erreur HTTP 429 lorsqu'un quota est dépassé (règle de quota) ou que la limite de débit est dépassée (règle SpikeArrest).

Cependant, dans le tableau de bord des alertes, vous ne pouvez pas définir une alerte pour un code d'erreur HTTP 429. À la place, vous devez définir une condition d'alerte de type Règle de gestion du trafic > Quota > Violation de quota, comme indiqué ci-dessous, ou Règle de gestion du trafic > Arrêt des pics > Violation de SpikeArrest:

violation de quota