Richieste API non acquisite nell'UI Edge

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione 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, nella UI di Edge non verrà visualizzato nessun messaggio di errore.

Possibili cause

La tabella seguente mostra le possibili cause di un errore di acquisizione delle richieste API in Edge UI Trace:

Causa: richieste non elaborate dal processore di messaggi

Diagnosi

Per acquisire una richiesta API in una sessione di Trace, questa deve essere elaborata dal componente di elaborazione di messaggi 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, ha esito negativo nel punto di ingresso a Edge (ovvero router) o non riesce prima di essere elaborato dal processore di messaggi, la traccia non può essere acquisita. Ciascuno di questi scenari è descritto più dettagliatamente 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: richieste non riuscite sul router Apigee Edge

• Causa

  In questo scenario, l'errore può essere causato da un errore dell'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

  Per risolvere questi problemi, consulta i seguenti playbook:

  Errori di handshake TLS/SSL

  400 Richiesta non valida - Errore del 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 vedere uno dei seguenti i 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, fai riferimento a questo playbook: 404 missing to unlock proxy for host (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 nell'albero di classificazione, le richieste API inviate a quel proxy specifico non verranno mostrate nelle sessioni di traccia dell'interfaccia utente di Edge.

Per determinare se è il tuo caso:

1. Accedi a ciascuno dei processori di messaggi e verifica che il deployment della revisione specifica dell'API richiesta sia stato eseguito nell'ambiente pertinente del processore di messaggi 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 l'output seguente:

   [ "12" ]
   

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

2. Leggi l'albero di classificazione e verifica l'esistenza del nome del 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 proxy API fornito non è presente nell'albero di classificazione di uno dei processori di messaggi, segui la risoluzione fornita di seguito.

Risoluzione

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

1. Accedi a ciascuno degli host dell'elaboratore di messaggi a cui manca il proxy API specifico nell'albero 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 l'output seguente:

   [ "12" ]
   

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

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

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

   Se il problema persiste, vai alla pagina Raccogliere dati diagnostici.

Raccogliere informazioni diagnostiche

Se il problema persiste dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e condividile con il supporto 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