Richieste API non acquisite nell'UI Edge

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Sintomo

L'immagine seguente mostra che le richieste API non vengono acquisite nella UI Edge quando viene avviata una sessione di traccia:

Messaggio di errore

Quando si verifica questo problema, non verrà visualizzato alcun messaggio di errore nell'interfaccia utente Edge.

Possibili cause

La tabella seguente mostra le possibili cause di un errore nell'acquisizione delle richieste API nella traccia dell'interfaccia utente perimetrale:

Causa: richieste non elaborate dal processore di messaggi

Diagnosi

Per acquisire una richiesta API in una sessione di traccia, la richiesta API deve essere elaborata dal processore di messaggi del componente di Edge. Esistono diversi motivi per cui una richiesta API potrebbe non essere acquisita in una transazione Trace.

Ad esempio, se una richiesta API non riesce a raggiungere Apigee Edge, l'operazione non riesce nel punto di ingresso a Edge (ovvero router) o non riesce prima che venga elaborata dal processore di messaggi, quindi non è possibile acquisire la traccia. Ciascuno di questi scenari è descritto in maggiore dettaglio di seguito.

Scenario 1: le richieste non raggiungono Apigee Edge

• Causa

  In questo scenario, l'errore potrebbe essere causato da un problema di risoluzione DNS o di connettività di rete. In questo caso, potresti visualizzare il seguente errore durante l'esecuzione di questo comando:

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• Risoluzione

  Puoi verificare la configurazione DNS con il seguente comando:

  dig hostName

  Puoi verificare la connettività di rete con il seguente comando:

  telnet hostName port

Scenario 2: le richieste non vanno a buon fine sul router Apigee Edge

• Causa

  In questo scenario, l'errore potrebbe essere causato da un errore di handshake TLS/SSL. In questo caso, potresti visualizzare uno dei seguenti errori:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  Potresti anche visualizzare un errore relativo al certificato SSL.

• Risoluzione

  Consulta i seguenti playbook per risolvere questi problemi:

  Errori di handshake TLS/SSL

  400 Richiesta non valida - Errore certificato SSL

Scenario 3: le richieste non possono essere elaborate dal processore di messaggi

• Causa

  In questo scenario, il processore di messaggi Apigee non riesce a trovare il proxy API per l'host virtuale e il percorso specificati. Di conseguenza, potresti visualizzare uno dei seguenti errori:

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• Risoluzione

  Per risolvere e risolvere il problema, consulta il seguente playbook: 404 Impossibile identificare il proxy per l'host.

Causa: proxy API non trovato nell'albero di classificazione

Diagnosi

Se un processore di messaggi non riesce a trovare un proxy API nel suo albero di classificazione, le richieste API a quel proxy specifico non verranno mostrate nelle sessioni di Trace nell'interfaccia utente Edge.

Per determinare se è così, segui i passaggi riportati di seguito:

1. Accedi a ciascuno dei processori di messaggi e controlla se nell'ambiente pertinente del processore di messaggi è stato eseguito il deployment della revisione specifica dell'API richiesta utilizzando il seguente comando:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Output di esempio:

   Il comando riportato sopra restituirà un elenco delle revisioni di cui è stato eseguito il deployment. Ad esempio, se viene eseguito il deployment della revisione 12, vedrai il seguente output:

   [ "12" ]
   

   A meno che non si verifichino errori HTTP 404 intermittenti, è probabile che sia stato eseguito il deployment della revisione specifica.

2. Leggi l'albero di classificazione e verifica l'esistenza del nome proxy API utilizzando il seguente comando:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. Ripeti i passaggi 1 e 2 per ciascun processore di messaggi. Se il nome del proxy API fornito non è presente nell'albero di classificazione di uno qualsiasi dei processori di messaggi, segui la risoluzione indicata di seguito.

Risoluzione

Per risolvere il problema, procedi nel seguente modo. Assicurati di prendere tutte le precauzioni necessarie per evitare interruzioni della produzione che potrebbero verificarsi a seguito del riavvio dei processori di messaggi durante il caricamento di richieste elevate.

1. Accedi a ciascuno degli host del processore di messaggi a cui manca il proxy API specifico nella struttura di classificazione e utilizza il comando seguente per riavviare il processore di messaggi:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. Dopo il riavvio, utilizza il comando seguente per attendere che diventi attivo:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. Quando il processore di messaggi è pronto, verifica la disponibilità del proxy API utilizzando il seguente comando:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   Output di esempio:

   Il comando riportato sopra restituirà un elenco delle revisioni di cui è stato eseguito il deployment. Ad esempio, se viene eseguito il deployment della revisione 12, vedrai il seguente output:

   [ "12" ]
   

   A meno che non si verifichino errori HTTP 404 intermittenti, è probabile che sia stato eseguito il deployment della revisione specifica.

4. Leggi l'albero di classificazione e verifica l'esistenza del nome proxy API utilizzando il seguente comando:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   Se il problema persiste, vai alla pagina Devi raccogliere informazioni diagnostiche.

È necessario raccogliere informazioni diagnostiche

Se il problema persiste dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni di diagnostica e condividile con l'assistenza Apigee Edge:

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree