Stai visualizzando la documentazione di Apigee Edge.
Consulta la
documentazione di Apigee X. info
Sintomo
Le dashboard di analisi (Rendimento proxy, Rendimento target e così via) non mostrano dati nella nuova UI di Edge. Tutte le dashboard mostrano il seguente messaggio:
No traffic in the selected date range
Messaggi di errore
Questo problema non genera errori osservabili.
Possibili cause
La tabella seguente elenca le possibili cause di questo problema:
| Causa | Per |
|---|---|
| Nessun traffico API per l'organizzazione-ambiente | Utenti di Edge for Private Cloud |
| Dati disponibili nel database Postgres, ma non visualizzati nella nuova UI di Edge | Utenti di Edge for Private Cloud |
| Dati di analisi non inviati al database Postgres | Utenti di Edge for Private Cloud |
| Deployment di Analytics non corretto | Utenti di Edge for Private Cloud |
| UUID del server di analisi obsoleti | Utenti di Edge for Private Cloud |
Nessun traffico API per l'organizzazione-ambiente
Diagnosi
- Controlla se è presente traffico per i proxy API nell'organizzazione-ambiente specifica per
la durata specifica per cui stai tentando di visualizzare i dati di analisi utilizzando uno dei seguenti
metodi:
- Attiva la traccia per una delle API attualmente utilizzate dagli utenti e verifica se riesci a ottenere richieste nella traccia.
- Visualizza i log di accesso NGINX
(
/opt/apigee/var/log/edge-router/nginx/logs/access.log)e verifica se sono presenti nuove voci per i proxy API per la durata specifica. - Se registri le informazioni dei proxy API in un server di log come Syslog, Splunk, Loggly, e così via, puoi verificare se sono presenti voci in questi server di log per i proxy API per la durata specifica.
- Se non è presente traffico (nessuna richiesta API) per la durata specifica, i dati di analisi non sono disponibili. Nella dashboard di analisi verrà visualizzato il messaggio "Nessun traffico nell'intervallo di date selezionato".
Risoluzione
- Effettua alcune chiamate a uno o più proxy API nell'organizzazione-ambiente specifica.
- Attendi qualche secondo, quindi visualizza le dashboard di analisi nella scheda Ora e verifica se i dati vengono visualizzati.
- Se il problema persiste, vai a Dati disponibili nel database Postgres Database, ma non visualizzati nella nuova UI di Edge.
Dati disponibili nel database Postgres, ma non visualizzati nella nuova UI di Edge
Sintomo
Innanzitutto, determina la disponibilità degli ultimi dati di analisi nel database Postgres.
Per verificare se gli ultimi dati di analisi sono disponibili nel nodo master Postgres node:
- Accedi a ciascuno dei server Postgres ed esegui il seguente comando per verificare se ti trovi
nel nodo master Postgres:
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
- Nel nodo master Postgres, accedi a PostgreSQL:
psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
- Verifica se la tabella esiste per la tua organizzazione-ambiente utilizzando la seguente query SQL nel database Postgres
database:
\d analytics."orgname.envname.fact"
- Verifica se gli ultimi dati sono disponibili nel database Postgres utilizzando la seguente query SQL
query:
select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
- Se l'ultimo timestamp è molto vecchio (o nullo), significa che i dati non sono disponibili nel database Postgres. La causa probabile di questo problema è che i dati non vengono inviati dal server Qpid al database Postgres. Vai a Dati di analisi non inviati al database Postgres.
- Se gli ultimi dati sono disponibili nel database Postgres sul nodo master, segui questi passaggi per diagnosticare il motivo per cui i dati non vengono visualizzati nella nuova UI di Edge.
Diagnosi
- Attiva gli Strumenti per sviluppatori
nel browser Chrome e recupera l'API utilizzata da una delle dashboard di analisi seguendo questi passaggi:
- Seleziona la scheda Rete dagli Strumenti per sviluppatori.
- Avvia la registrazione.
- Ricarica la dashboard di analisi.
- Nel riquadro a sinistra degli Strumenti per sviluppatori, seleziona la riga con "apiproxy?_optimized...".
- Nel riquadro a destra degli Strumenti per sviluppatori, seleziona la scheda "Intestazioni" e prendi nota dell' "URL della richiesta".
- Di seguito è riportato un output di esempio degli Strumenti per sviluppatori:
Output di esempio che mostra l'API utilizzata nella Performance Dashboard Rendimento proxy dalla scheda Rete degli Strumenti per sviluppatori per la Performance Dashboard Rendimento proxy

- Esegui direttamente la chiamata all'API di gestione e verifica se ottieni i risultati. Di seguito è riportata una chiamata API
di esempio per la scheda Giorno nella dashboard Rendimento proxy:
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"
- Se visualizzi una risposta positiva ma senza dati, significa che il server di gestione non è in grado di recuperare i dati dal server Postgres a causa di problemi di connettività di rete.
- Verifica se riesci a connetterti al server Postgres dal server di gestione:
telnet Postgres_server_IP_address 5432
- Se non riesci a connetterti al server Postgres, verifica se sono presenti restrizioni del firewall sulla porta 5432.
- Se sono presenti restrizioni del firewall, potrebbe essere il motivo per cui il server di gestione non è in grado di estrarre i dati dal server Postgres.
Risoluzione
- Se sono presenti restrizioni del firewall, rimuovile in modo che il server di gestione possa comunicare con il server Postgres.
- Se non sono presenti restrizioni del firewall, il problema potrebbe essere dovuto a un problema di rete.
- Se si è verificato un problema di rete sul server di gestione, il riavvio potrebbe risolvere il problema.
- Riavvia tutti i server di gestione uno alla volta utilizzando il seguente comando:
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
- Verifica se riesci a visualizzare i dati di analisi nella nuova UI di Edge.
Se ancora non vedi i dati, contatta l'assistenza Apigee Edge.
Dati di analisi non inviati al database Postgres
Diagnosi
Se i dati non vengono inviati dal server Qpid al database Postgres come stabilito in Dati disponibili nel database Postgres, ma non visualizzati nella nuova UI di Edge, esegui i seguenti passaggi:
- Verifica se ogni server Qpid è attivo ed è in esecuzione eseguendo il seguente comando:
/opt/apigee/apigee-service/bin edge-qpid-server status
- Se un server Qpid è inattivo, riavvialo. In caso contrario, vai al passaggio 5.
/opt/apigee/apigee-service/bin edge-qpid-server restart
- Attendi qualche tempo, quindi controlla di nuovo se gli ultimi dati sono disponibili nel database Postgres.
- Accedi a PostgreSQL:
psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
- Esegui la seguente query SQL per verificare se gli ultimi dati sono disponibili:
select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
- Accedi a PostgreSQL:
- Se gli ultimi dati sono disponibili, salta i passaggi seguenti e vai all'ultimo passaggio della sezione Risoluzione. Se gli ultimi dati non sono disponibili, procedi con i passaggi seguenti passi.
- Verifica se i messaggi delle code del server Qpid vengono inviati al database Postgres.
- Esegui il
qpid-stat -q commande controlla i valori delle colonne msgIn e msgOut. - Di seguito è riportato un output di esempio che mostra che msgIn e msgOut non sono uguali. Ciò indica
che i messaggi non vengono inviati dal server Qpid al database Postgres.

- Esegui il
- Se le colonne msgIn e msgOut non corrispondono, controlla i log del server Qpid
Server
/opt/apigee/var/log/edge-qpid-server/system.loge verifica se sono presenti errori. - Potresti visualizzare messaggi di errore come "Probably PG is still down" o
"FATAL: sorry, too many clients already" come mostrato nella figura seguente:
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)
Questo potrebbe accadere se il server Postgres esegue troppe query SQL o se la CPU è in esecuzione elevata e quindi non è in grado di rispondere al server Qpid.
Risoluzione
- Riavvia il server Postgres e PostgreSQL come mostrato di seguito:
/opt/apigee/bin/apigee-service edge-postgres-server restart
/opt/apigee/bin/apigee-service apigee-postgresql restart
- Questo riavvio garantisce che tutte le query SQL precedenti vengano arrestate e dovrebbe consentire nuove connessioni al database Postgres.
- Ricarica le dashboard di analisi e verifica se i dati di analisi vengono visualizzati.
Se il problema persiste, contatta l'assistenza Apigee Edge.
Deployment di Analytics non corretto
Diagnosi
- Recupera lo stato del deployment di Analytics utilizzando la seguente chiamata API:
curl -u user_email:password http://management_server_host:port /v1/organizations/orgname/environments/envname/provisioning/axstatus
- Controlla lo stato dei server Qpid e Postgres dai risultati della chiamata API.
- Se lo stato dei server Qpid e Postgres è "SUCCESS", significa che i server di analisi sono collegati correttamente. Vai a UUID del server di analisi obsoleti.
- Se lo stato dei server Qpid/Postgres è "UNKNOWN" o "FAILURE", allora
indica un problema con il server corrispondente.
Ad esempio, lo scenario seguente mostra lo stato dei server Postgres come "UNKNOWN":

Questo può accadere se si verifica un errore durante l'onboarding di Analytics. Questo errore impedisce ai messaggi dei server di gestione di raggiungere i server Postgres.
Risoluzione
In genere, questo problema può essere risolto riavviando i server che hanno mostrato "FAILURE" o "UNKNOWN".
- Riavvia ciascuno dei server il cui stato di collegamento di analisi indica "FAILURE" o "UNKNOWN"
utilizzando il seguente comando:
/opt/apigee/apigee-service/bin/apigee-service component restart
- Ad esempio:
- Se riscontri il problema sui server Qpid, riavvia i server Qpid:
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
- Se riscontri il problema sui server Postgres, riavvia i nodi del server Postgres master e slave:
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
- Se riscontri il problema sui server Qpid, riavvia i server Qpid:
- Nell'esempio precedente, il messaggio "UNKNOWN" viene visualizzato per i server Postgres, quindi devi
riavviare sia il server Postgres master che quello slave:
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
UUID del server di analisi obsoleti
Diagnosi
- Recupera la configurazione di analisi utilizzando la seguente chiamata API:
curl -u user_email:password http://management-server-host:port/v1/analytics/groups/ax
Di seguito è riportato un output di esempio dell'API precedente:
[ { "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" : { } } ]
- Assicurati che le seguenti informazioni nell'output siano corrette:
- Nomi dell'organizzazione-ambiente elencati nell'elemento "scopes".
- UUID dei server Postgres e dei server Qpid.
- Recupera gli UUID del server Postgres eseguendo il seguente comando su ciascuno dei
nodi del server Postgres:
curl 0:8084/v1/servers/self/uuid
- Recupera gli UUID del server Qpid eseguendo il seguente comando su ciascuno dei nodi del server Qpid:
curl 0:8083/v1/servers/self/uuid
- Recupera gli UUID del server Postgres eseguendo il seguente comando su ciascuno dei
nodi del server Postgres:
- Se tutte le informazioni sono corrette, vai a Dati di analisi non inviati al database Postgres.
- Se gli UUID dei server Postgres e/o Qpid non sono corretti, è possibile che i server di gestione facciano riferimento a UUID obsoleti.
Risoluzione
Per rimuovere gli UUID obsoleti e aggiungere gli UUID corretti dei server, contatta l'assistenza Apigee Edge.