Questions fréquentes

Vous consultez la documentation d'Apigee Edge.
Accédez à la documentation sur Apigee X. info

Vous trouverez ci-dessous les 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 cinq minutes. Configurez des 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 de développer les API de recommander des seuils de taux d'erreur et de latence à l'équipe chargée des opérations, qui est chargée de configurer des alertes.

Quels rôles peuvent accéder à l'API Monitoring ?

Consultez la section À propos des rôles API Monitoring.

Pourquoi tous les proxys d'API ne sont-ils pas listés sur la page "Récent" ?

Le tableau de bord Récents n'affiche que les proxys d'API ayant eu du trafic récemment. Elle n'affiche pas tous les proxys d'API de votre organisation. Le tableau de bord Chronologie vous permet d'afficher les données de tous les proxys d'API.

Pourquoi les graphiques de latence ne s'affichent-ils pas dans Vos trajets ?

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 sept jours.

Les journaux sont utiles pour identifier les codes d'état qui génèrent 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 exécuter un rapport personnalisé.

Puis-je surveiller une chaîne de proxys ?

Vous pouvez utiliser un proxy d'API comme point de terminaison cible d'un autre proxy d'API, en associant efficacement les deux proxys dans une chaîne de proxy. Toutefois, la surveillance de l'API ne consigne que les requêtes envoyées au premier proxy de la chaîne, et non au proxy d'API utilisé comme cible. Pour en savoir plus, consultez la section Associer des proxys d'API en chaîne.

Pourquoi la mention "non défini" apparaît-elle dans les tableaux de bord ?

Si le proxy d'API, la source d'erreur, le code d'erreur ou la règle d'erreur n'ont pas de valeur ou ne peuvent pas être déterminés, le tableau de bord affichera "non défini" comme origine. Voici des exemples de scénarios pouvant entraîner la valeur "non défini" :

  • Erreurs liées au client
  • Codes d'erreur HTTP ignoré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 en savoir plus sur la valeur "not set", consultez la section Signification d'une valeur d'entité d'analyse "(not set)".

API Monitoring est-il disponible dans l'UI classique ou dans Edge pour Private Cloud ?

Apigee API Monitoring n'est actuellement disponible que pour les clients Apigee Edge Cloud Enterprise qui utilisent la nouvelle interface utilisateur Edge.

La surveillance des API Apigee n'est pas disponible dans l'interface utilisateur Edge classique ni dans Edge pour 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 et la règle SpikeArrest d'Edge génèrent 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).

Toutefois, dans le tableau de bord des alertes, vous ne pouvez pas définir d'alerte pour un code d'erreur HTTP 429. Vous devez plutôt définir une condition d'alerte sur Règle de gestion du trafic > Quota > Violation de quota, comme illustré ci-dessous, ou sur Règle de gestion du trafic > Spike Arrest > Violation de SpikeArrest:

non-respect des quotas