Questions fréquentes

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

Voici les réponses aux questions fréquentes:

Apigee recommande les approches suivantes:

  1. Commencez par configurer des alertes pour tout 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 taux d'erreur et des seuils de latence à l'équipe chargée des opérations, qui est chargée de configurer les 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 que la période sélectionnée ne dépasse pas 7 jours.

Les journaux sont utiles pour identifier les codes d'état qui génèrent des erreurs, mais comment puis-je 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, en connectant efficacement 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 plus d'informations, voir Chaînage de proxys d'API.

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

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

  • 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", voir 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 puis-je gérer les codes d'erreur HTTP 429 ?

La règle de quota Edge et la règle SpikeArrest émettent 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 Règle de gestion du trafic > Quota > Violation de quota, comme indiqué ci-dessous, ou Règle de gestion du trafic > Arest de pics > Violation de SpikeArrest:

violation de quota