Vous consultez la documentation Apigee Edge.
Accédez à la
documentation**Apigee X**. info
Problème constaté
Les tableaux de bord Analytics (Performances des proxys, Performances des cibles, etc.) n'affichent aucune donnée dans l'interface utilisateur Edge. Tous les tableaux de bord affichent le message suivant :
No traffic in the selected date range
Messages d'erreur
Ce problème n'entraîne pas d'erreurs observables.
Causes possibles
Le tableau suivant répertorie les causes possibles de ce problème :
| Cause | Pour |
|---|---|
| Aucun trafic d'API pour l'organisation-environnement | Utilisateurs d'Edge pour le cloud privé |
| Données disponibles dans la base de données Postgres, mais ne s'affichent pas dans l'interface utilisateur | Utilisateurs d'Edge pour le cloud privé |
| Données Analytics non envoyées à la base de données Postgres | Utilisateurs d'Edge pour le cloud privé |
| Déploiement Analytics incorrect | Utilisateurs d'Edge pour le cloud privé |
| UUID de serveur Analytics obsolètes | Utilisateurs d'Edge pour le cloud privé |
Aucun trafic d'API pour l'organisation-environnement
Diagnostic
- Vérifiez s'il existe du trafic pour les proxys d'API sur l'organisation-environnement spécifique pour
la durée spécifique pour laquelle vous essayez d'afficher les données Analytics à l'aide de l'une des méthodes suivantes :
- Activez la trace pour l'une de vos API actuellement utilisée par vos utilisateurs et vérifiez si vous pouvez obtenir des requêtes dans la trace.
- Affichez les journaux d'accès NGINX
(
/opt/apigee/var/log/edge-router/nginx/logs/access.log)et vérifiez s'il existe de nouvelles entrées pour les proxys d'API pour la durée spécifique. - Si vous enregistrez des informations provenant de proxys d'API sur un serveur de journaux tel que Syslog, Splunk, Loggly, etc., vous pouvez vérifier s'il existe des entrées dans ces serveurs de journaux pour les proxys d'API pour la durée spécifique.
- S'il n'y a pas de trafic (aucune requête API) pour la durée spécifique, les données Analytics ne sont pas disponibles. Le message "Aucun trafic dans la plage de dates sélectionnée" s'affiche dans le tableau de bord Analytics.
Solution
- Effectuez des appels vers un ou plusieurs proxys d'API dans l'organisation-environnement spécifique.
- Attendez quelques secondes, puis affichez les tableaux de bord Analytics dans l'onglet "Heure" et vérifiez si les données s'affichent.
- Si le problème persiste, passez à la section Données disponibles dans la base de données Postgres mais ne s'affichent pas dans l'interface utilisateur.
Données disponibles dans la base de données Postgres, mais ne s'affichent pas dans l'interface utilisateur
Problème constaté
Commencez par déterminer la disponibilité des dernières données Analytics dans la base de données Postgres.
Pour vérifier si les dernières données Analytics sont disponibles dans le nœud maître Postgres node:
- Connectez-vous à chacun des serveurs Postgres et exécutez la commande suivante pour vérifier si vous vous trouvez
sur le nœud maître Postgres :
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
- Sur le nœud maître Postgres, connectez-vous à PostgreSQL :
psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
- Vérifiez si la table existe pour votre organisation-environnement à l'aide de la requête SQL suivante dans la base de données Postgres
database :
\d analytics."orgname.envname.fact"
- Vérifiez si les dernières données sont disponibles dans la base de données Postgres à l'aide de la requête SQL
query suivante :
select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
- Si le dernier timestamp est très ancien (ou nul), cela indique que les données ne sont pas disponibles dans la base de données Postgres. La cause probable de ce problème est que les données ne sont pas envoyées du serveur Qpid à la base de données Postgres. Passez à la section Données Analytics non envoyées à la base de données Postgres.
- Si les dernières données sont disponibles dans la base de données Postgres sur le nœud maître, suivez les étapes ci-dessous pour diagnostiquer pourquoi les données ne s'affichent pas dans l'interface utilisateur Edge.
Diagnostic
- Activez les outils de développement
dans votre navigateur Chrome et obtenez l'API utilisée à partir de l'un des tableaux de bord Analytics en procédant comme suit :
- Sélectionnez l'onglet "Network" (Réseau) dans les outils de développement.
- Démarrez l'enregistrement.
- Actualisez le tableau de bord Analytics.
- Dans le panneau de gauche des outils de développement, sélectionnez la ligne contenant "apiproxy?_optimized...".
- Dans le panneau de droite des outils de développement, sélectionnez l'onglet "Headers" (En-têtes) et notez l' URL de la requête.
- Voici un exemple de résultat des outils de développement :
Exemple de résultat montrant l'API utilisée dans le tableau de bord "Performances des proxys" à partir de l'onglet "Network" (Réseau) des outils de développement pour le tableau de bord "Performances des proxys"

- Exécutez directement l'appel d'API de gestion et vérifiez si vous obtenez des résultats. Voici un exemple d'appel d'API
pour l'onglet "Jour" du tableau de bord "Performances des proxys" :
curl -u username:password "http://management_server_IP_address:8080/v1/organizations/ org_name/environments/env_name/stats/apiproxy?limit=14400& select=sum(message_count),sum(is_error),avg(total_response_time), avg(target_response_time)&sort=DESC&sortby=sum(message_count),sum(is_error), avg(total_response_time),avg(target_response_time)&timeRange=08%2F9%2F2017+ 18:00:00~08%2F10%2F2017+18:00:00&timeUnit=hour&tsAscending=true"
- Si vous voyez une réponse positive, mais sans aucune donnée, cela indique que le serveur de gestion ne parvient pas à extraire les données du serveur Postgres en raison de problèmes de connectivité réseau.
- Vérifiez si vous pouvez vous connecter au serveur Postgres à partir du serveur de gestion :
telnet Postgres_server_IP_address 5432
- Si vous ne parvenez pas à vous connecter au serveur Postgres, vérifiez s'il existe des restrictions de pare-feu restrictions sur le port 5432.
- Si des restrictions de pare-feu sont en place, cela peut être la cause de l'incapacité du serveur de gestion à extraire les données du serveur Postgres.
Solution
- S'il existe des restrictions de pare-feu, supprimez-les afin que le serveur de gestion puisse communiquer avec le serveur Postgres.
- S'il n'y a pas de restrictions de pare-feu, ce problème peut être dû à un problème réseau.
- Si un problème réseau s'est produit sur le serveur de gestion, le redémarrage peut résoudre le problème.
- Redémarrez tous les serveurs de gestion un par un à l'aide de la commande ci-dessous :
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
- Vérifiez si vous pouvez voir les données Analytics dans l'interface utilisateur Edge.
Si vous ne voyez toujours pas les données, contactez l'assistance Apigee Edge.
Données Analytics non envoyées à la base de données Postgres
Diagnostic
Si les données ne sont pas envoyées du serveur Qpid à la base de données Postgres, comme indiqué dans la section Données disponibles dans la base de données Postgres, mais ne s'affichent pas dans l'interface utilisateur, procédez comme suit :
- Vérifiez si chaque serveur Qpid est opérationnel en exécutant la commande ci-dessous :
/opt/apigee/apigee-service/bin edge-qpid-server status
- Si un serveur Qpid est arrêté, redémarrez-le. Sinon, passez à l'étape 5.
/opt/apigee/apigee-service/bin edge-qpid-server restart
- Attendez un moment, puis vérifiez à nouveau si les dernières données sont disponibles dans la base de données Postgres.
- Connectez-vous à PostgreSQL :
psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
- Exécutez la requête SQL ci-dessous pour vérifier si les dernières données sont disponibles :
select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
- Connectez-vous à PostgreSQL :
- Si les dernières données sont disponibles, ignorez les étapes suivantes et passez à la dernière étape de la section Solution. Si les dernières données ne sont pas disponibles, procédez comme suit étapes.
- Vérifiez si les messages des files d'attente du serveur Qpid sont envoyés à la base de données Postgres.
- Exécutez le
qpid-stat -q commandet vérifiez les msgIn et msgOut valeurs de colonne. - Voici un exemple de résultat montrant que msgIn et msgOut ne sont pas égaux. Cela indique
que les messages ne sont pas envoyés du serveur Qpid à la base de données Postgres.

- Exécutez le
- S'il existe une différence entre les colonnes msgIn et msgOut, consultez les journaux du serveur Qpid
Server
/opt/apigee/var/log/edge-qpid-server/system.loget vérifiez s'il existe des erreurs. - Vous pouvez voir des messages d'erreur tels que "Probably PG is still down" (Probablement que PG est toujours arrêté) ou
"FATAL: sorry, too many clients already" (FATAL : désolé, trop de clients déjà) comme illustré dans la figure ci-dessous :
2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3 WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be retriable - . Error observed while trying to connect to jdbc:postgresql://PG_IP_address:5432/apigee Initial referenced UUID when execution started in this thread was a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d Probably PG is still down. PG set used - [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d] 2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3 WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection; nested exception is org.postgresql.util.PSQLException: FATAL: sorry, too many clients already 2017-07-28 09:56:53,617 pool-7-thread-1 WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be retriable - . Error observed while trying to connect to jdbc:postgresql://PG_IP_address:5432/apigee Initial referenced UUID when execution started in this thread was a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d Probably PG is still down. PG set used - [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d] 2017-07-28 09:56:53,617 pool-7-thread-1 WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection; nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create PoolableConnectionFactory (FATAL: sorry, too many clients already)
Cela peut se produire si le serveur Postgres exécute trop de requêtes SQL ou si le processeur est fortement sollicité et ne peut donc pas répondre au serveur Qpid.
Solution
- Redémarrez le serveur Postgres et PostgreSQL comme indiqué ci-dessous :
/opt/apigee/bin/apigee-service edge-postgres-server restart
/opt/apigee/bin/apigee-service apigee-postgresql restart
- Ce redémarrage garantit que toutes les requêtes SQL précédentes sont arrêtées et devrait autoriser de nouvelles connexions à la base de données Postgres.
- Actualisez les tableaux de bord Analytics et vérifiez si les données Analytics s'affichent.
Si le problème persiste, contactez l'assistance Apigee Edge.
Déploiement Analytics incorrect
Diagnostic
- Obtenez l'état du déploiement Analytics à l'aide de l'appel d'API suivant :
curl -u user_email:password http://management_server_host:port /v1/organizations/orgname/environments/envname/provisioning/axstatus
- Vérifiez l'état des serveurs Qpid et Postgres à partir des résultats de l'appel d'API.
- Si l'état des serveurs Qpid et Postgres est "SUCCESS" (SUCCÈS), cela indique que les serveurs Analytics sont correctement connectés. Passez à la section UUID de serveur Analytics obsolètes.
- Si l'état des serveurs Qpid/Postgres est "UNKNOWN" (INCONNU) ou "FAILURE" (ÉCHEC), cela
indique un problème avec le serveur correspondant.
Par exemple, le scénario suivant montre l'état des serveurs Postgres comme "UNKNOWN" (INCONNU) :

Cela peut se produire en cas d'échec lors de l'intégration d'Analytics. Cet échec empêche les messages des serveurs de gestion d'atteindre les serveurs Postgres.
Solution
Ce problème peut généralement être résolu en redémarrant les serveurs qui affichent "FAILURE" (ÉCHEC) ou "UNKNOWN" (INCONNU).
- Redémarrez chacun des serveurs dont l'état de connexion Analytics indique "FAILURE" (ÉCHEC) ou "UNKNOWN" (INCONNU)
à l'aide de la commande suivante :
/opt/apigee/apigee-service/bin/apigee-service component restart
- Par exemple, .
- Si le problème se produit sur les serveurs Qpid, redémarrez-les :
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
- Si le problème se produit sur les serveurs Postgres, redémarrez les nœuds de serveur Postgres maître et esclave
:
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
- Si le problème se produit sur les serveurs Qpid, redémarrez-les :
- Dans l'exemple ci-dessus, le message "UNKNOWN" (INCONNU) s'affiche pour les serveurs Postgres. Vous devez donc
redémarrer les serveurs Postgres maître et esclave :
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
UUID de serveur Analytics obsolètes
Diagnostic
- Obtenez la configuration Analytics à l'aide de l'appel d'API suivant :
curl -u user_email:password http://management-server-host:port/v1/analytics/groups/ax
Voici un exemple de résultat de l'API ci-dessus :
[ { "name" : "axgroup001", "properties" : { "consumer-type" : "ax" }, "scopes" : [ "myorg~prod", "myorg~test" ], "uuids" : { "aries-datastore" : [ ], "postgres-server" : [ "6777...2db14" ], "dw-server" : [ ], "qpid-server" : [ "774e...fb23", "29f3...8c11" ] }, "consumer-groups" : [ { "name" : "consumer-group-001", "consumers" : [ "774e...8c11" ], "datastores" : [ "6777...db14" ], "properties" : { } } ], "data-processors" : { } } ]
- Assurez-vous que les informations suivantes dans le résultat sont correctes :
- Noms d'organisation-environnement listés dans l'élément "scopes".
- UUID des serveurs Postgres et des serveurs Qpid.
- Obtenez les UUID du serveur Postgres en exécutant la commande suivante sur chacun des
nœuds du serveur Postgres :
curl 0:8084/v1/servers/self/uuid
- Obtenez les UUID du serveur Qpid en exécutant la commande suivante sur chacun des nœuds du serveur Qpid
:
curl 0:8083/v1/servers/self/uuid
- Obtenez les UUID du serveur Postgres en exécutant la commande suivante sur chacun des
nœuds du serveur Postgres :
- Si toutes les informations sont correctes, passez à la section Données Analytics non envoyées à la base de données Postgres.
- Si les UUID des serveurs Postgres et/ou Qpid sont incorrects, il est possible que les serveurs de gestion fassent référence à des UUID obsolètes.
Solution
Pour supprimer les UUID obsolètes et ajouter les UUID corrects des serveurs, contactez l'assistance Apigee Edge.