500 Internal Server Error

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Video

Guarda i seguenti video per saperne di più sulla risoluzione degli errori 500 Internal Server Error.

Sintomo

L'applicazione client riceve un codice di stato HTTP 500 con il messaggio "Internal Server Error" come risposta alle chiamate API. L'errore 500 Internal Server Error potrebbe essere causato da un errore durante l'esecuzione di una policy in Edge o da un errore sul server di destinazione/backend.

Il codice di stato HTTP 500 è una risposta di errore generica. Significa che il server ha riscontrato una condizione imprevista che gli ha impedito di soddisfare la richiesta. Questo errore viene in genere restituito dal server quando non è adatto nessun altro codice di errore.

Messaggi di errore

Potresti ricevere il seguente messaggio di errore:

HTTP/1.1 500 Internal Server Error

In alcuni casi, potresti visualizzare un altro messaggio di errore con maggiori dettagli. Ecco un esempio di messaggio di errore:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Possibili cause

L'errore 500 Internal Server Error potrebbe essere generato per una serie di motivi diversi. In Edge, le cause possono essere classificate in due categorie principali in base a dove si è verificato l'errore:

Errore di esecuzione in una policy Edge

Una policy all'interno del proxy API potrebbe non riuscire per qualche motivo. Questa sezione spiega come risolvere il problema se si verifica l'errore 500 Internal Server Error durante l'esecuzione di una policy.

Diagnosi

Passaggi di diagnostica per gli utenti di Private Cloud e Public Cloud

Se hai la sessione dell'interfaccia utente di Trace per l'errore:

1. Verifica che l'errore sia stato causato dall'esecuzione di una policy. Per maggiori dettagli, consulta la sezione Determinare l'origine del problema.
2. Se l'errore si è verificato durante l'esecuzione della policy, continua. Se l'errore è stato causato dal server di backend, vai a Errore nel server di backend.
3. Seleziona la richiesta API che non riesce con l'errore 500 Internal Server Error nella traccia.
4. Esamina la richiesta e seleziona la policy specifica che non è riuscita o il flusso denominato "Errore" che segue immediatamente la policy non riuscita nella traccia.
5. Per maggiori dettagli sull'errore, controlla il campo "error" nella sezione Proprietà o il contenuto dell'errore.
6. Utilizzando i dettagli raccolti sull'errore, prova a determinarne la causa.

Passaggi di diagnostica solo per gli utenti di Private Cloud

Se non hai la sessione dell'interfaccia utente di Trace:

1. Verifica che l'errore si sia verificato durante l'esecuzione di una policy. Per maggiori dettagli, consulta la sezione Determinare l'origine del problema.
2. Se l'errore è stato causato dall'esecuzione della policy, continua. Se l'errore si è verificato durante l'esecuzione della policy, continua. Se l'errore è stato causato dal server di backend, vai a Errore nel server di backend.
3. Utilizza i log di accesso NGINX come spiegato in Determinare l'origine del problema per determinare la policy non riuscita nel proxy API e anche l' ID univoco del messaggio di richiesta.
4. Controlla i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) e cerca l' ID univoco del messaggio di richiesta.
5. Se trovi l'ID univoco del messaggio di richiesta, vedi se riesci a ottenere maggiori informazioni sulla causa dell'errore.

Risoluzione

Se hai determinato la causa del problema con la policy, prova a correggerlo modificando la policy e ridistribuendo il proxy.

I seguenti esempi illustrano come determinare la causa e la risoluzione per diversi tipi di problemi.

Se hai bisogno di ulteriore assistenza per la risoluzione dei problemi relativi all'errore 500 Internal Server Error o sospetti che si tratti di un problema in Edge, contatta l'assistenza Apigee.

Esempio 1: errore nella policy Service Callout a causa di un errore nel backend server

Se la chiamata al server di backend non riesce all'interno della policy Service Callout con un errore qualsiasi come 4XX o 5XX, verrà trattata come errore 500 Internal Server Error.

1. Ecco un esempio in cui il servizio di backend non riesce con un errore 404 all'interno della policy Service Callout. Il seguente messaggio di errore viene inviato all'utente finale:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. La seguente sessione dell'interfaccia utente di Trace mostra il codice di stato 500 causato da un errore nella policy Service Callout:

   

3. In questo esempio, la proprietà "error" elenca il motivo dell'errore della policy Service Callout come "ResponseCode 404 is treated as error". Questo errore potrebbe verificarsi se la risorsa a cui si accede tramite l'URL del server di backend nella policy Service Callout non è disponibile.
4. Verifica la disponibilità della risorsa sul server di backend. Potrebbe non essere disponibile temporaneamente/in modo permanente o potrebbe essere stata spostata in un'altra posizione.

Esempio 1: risoluzione

1. Verifica la disponibilità della risorsa sul server di backend. Potrebbe non essere disponibile temporaneamente/in modo permanente o potrebbe essere stata spostata in un'altra posizione.
2. Correggi l'URL del server di backend nella policy Service Callout in modo che punti a una risorsa valida ed esistente.
3. Se la risorsa non è disponibile solo temporaneamente, prova a effettuare la richiesta API una volta che la risorsa è disponibile.

Esempio 2: errore nella policy Extract Variables

Ora esaminiamo un altro esempio, in cui l'errore 500 Internal Server Error è causato da un errore nella policy Extract Variables e vediamo come risolvere il problema.

1. La seguente traccia nella sessione dell'interfaccia utente mostra il codice di stato 500 a causa di un errore nella policy Extract Variables:

   

2. Seleziona la policy Extract Variables non riuscita, scorri verso il basso e consulta la sezione "Error Content" per maggiori dettagli:
   
   
3. Il contenuto dell'errore indica che la"serviceCallout.oamCookieValidationResponse" variabile non è disponibile nella policy Extract Variables. Come indica il nome della variabile, dovrebbe contenere la risposta della policy Service Callout precedente.
4. Seleziona la policy Service Callout nella traccia e potresti scoprire che la "serviceCallout.oamCookieValidationResponse" variabile non è stata impostata. Ciò indica che la chiamata al servizio di backend non è riuscita, generando una variabile di risposta vuota.
5. Sebbene la policy Service Callout non sia riuscita, l'esecuzione delle policy dopo la policy Service Callout continua perché il flag "continueOnError" nella policy Service Callout è impostato su true, come mostrato di seguito:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. Prendi nota dell'ID univoco del messaggio "X-Apigee.Message-ID" per questa richiesta API specifica dalla traccia, come segue:
   1. Seleziona la fase "Analytics Data Recorded" dalla richiesta.
   2. Scorri verso il basso e prendi nota del valore di X-Apigee.Message-ID.

   

7. Visualizza il log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/system.log) e cerca l'ID univoco del messaggio annotato nel passaggio 6. Per la richiesta API specifica è stato osservato il seguente messaggio di errore:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   L'errore precedente indica che la policy Service Callout non è riuscita a causa di un errore di timeout della connessione durante la connessione al server di backend.

8. Per determinare la causa dell'errore di timeout della connessione, esegui il telnet comando sul server di backend dai processori di messaggi. Il comando telnet ha restituito l'errore "Connection timed out" (Timeout della connessione), come mostrato di seguito:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   In genere, questo errore si verifica nelle seguenti circostanze:

   • Quando il server di backend non è configurato per consentire il traffico dai Message Processors di Edge.
   • Se il server di backend non è in ascolto sulla porta specifica.

   Nell'esempio illustrato sopra, sebbene la policy Extract Variables non sia riuscita, la causa effettiva era che Edge non riusciva a connettersi al server di backend nella policy Service Callout La causa di questo errore era che il server di backend non era configurato per consentire il traffico dai Message Processor di Edge.

   La tua policy Extract Variables si comporterà in modo diverso e potrebbe non riuscire per un motivo diverso. Puoi risolvere il problema in modo appropriato a seconda della causa dell'errore della policy Extract Variables controllando il messaggio nella error proprietà.

Esempio 2: risoluzione

1. Correggi la causa dell'errore o dell'errore nella policy Extract Variables in modo appropriato.
2. Nell'esempio illustrato sopra, la soluzione consisteva nel correggere la configurazione di rete per consentire il traffico dai Message Processor di Edge al server di backend. A questo scopo, gli indirizzi IP dei Message Processor sono stati inseriti nella lista consentita sul server di backend specifico. Ad esempio, su Linux puoi utilizzare iptables per consentire il traffico dagli indirizzi IP del Message Processor sul server di backend.

Esempio 3: errore nella policy JavaCallout

Ora esaminiamo un altro esempio, in cui l'errore 500 Internal Server Error è causato da un errore nella policy Java Callout e vediamo come risolvere il problema.

1. La seguente traccia dell'interfaccia utente mostra il codice di stato 500 a causa di un errore nella policy Java Callout:

   

2. Seleziona il flusso denominato "Error" seguito dalla policy Java Callout non riuscita per visualizzare i dettagli dell'errore, come mostrato nella figura seguente:

   

3. In questo esempio, la proprietà "error" nella sezione Proprietà rivela che l'errore è dovuto all'utilizzo di una password scaduta durante la connessione al database Oracle dalla policy JavaCallout. La tua callout Java si comporterà in modo diverso e inserirà un messaggio diverso nella proprietà error.
4. Controlla il codice della policy JavaCallout e conferma la configurazione corretta da utilizzare.

Esempio 3: risoluzione

Correggi il codice o la configurazione del callout Java in modo appropriato per evitare l'eccezione di runtime. Nell'esempio di errore di callout Java illustrato sopra, per risolvere il problema è necessario utilizzare la password corretta per la connessione al database Oracle.

Errore nel server di backend

Un errore 500 Internal Server Error potrebbe anche avere origine dal server di backend. Questa sezione spiega come risolvere il problema se l'errore proviene dal server di backend.

Diagnosi

Passaggi di diagnostica per tutti gli utenti

La causa di altri errori di backend può variare notevolmente. Dovrai diagnosticare ogni situazione in modo indipendente.

1. Verifica che l'errore sia stato causato dal server di backend. Per maggiori dettagli, consulta la sezione Determinare l'origine del problema.
2. Se l'errore è stato causato dal server di backend, continua. Se l'errore si è verificato durante l'esecuzione della policy, vai a Errore di esecuzione nella policy Edge.
3. Segui i passaggi riportati di seguito a seconda che tu abbia o meno accesso a una sessione di Trace per l'API non riuscita o se il backend è un server Node.js:

Se non hai una sessione di Trace per la chiamata API non riuscita:

1. Se la traccia dell'interfaccia utente non è disponibile per la richiesta non riuscita, controlla i log del server di backend per visualizzare i dettagli dell'errore.
2. Se possibile, attiva la modalità di debug sul server di backend per visualizzare maggiori dettagli sull' errore e sulla causa.

Se hai una sessione di Trace per la chiamata API non riuscita:

Se hai una sessione di Trace, i seguenti passaggi ti aiuteranno a diagnosticare il problema.

1. Nello strumento Trace, seleziona la richiesta API che non è riuscita con l'errore 500 Internal Server Error.
2. Seleziona la fase "Response received from target server" (Risposta ricevuta dal server di destinazione) dalla richiesta API non riuscita come mostrato nella figura seguente:

   

3. Controlla la sezione "Response Content" (Contenuto della risposta) per visualizzare i dettagli dell'errore.

   

4. In questo esempio, il contenuto della risposta, che è un SOAP Envelope, mostra la stringa di errore come "Not Authorized" messaggio. La causa più probabile di questo problema è che l'utente non ha passato le credenziali corrette (nome utente/password, token di accesso e così via) al server di backend. Questo problema può essere risolto passando le credenziali corrette al server di backend.

Se il backend è un server Node.js:

1. Se il backend è un server di backend Node.js, controlla i log di Node.js per il proxy API specifico nell'interfaccia utente di Edge (sia gli utenti di Public Cloud sia quelli di Private Cloud possono controllare i log di Node.js). Se sei un utente di Edge Private Cloud, puoi anche controllare i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per maggiori dettagli sull'errore.
   
   

   Opzione Log NodeJS nell'interfaccia utente di Edge - Scheda Panoramica del proxy API

   

Risoluzione

1. Una volta identificata la causa dell'errore, correggi il problema nel server di backend.
2. Se si tratta di un server di backend Node.js:
   1. Controlla se l'errore viene generato dal tuo codice personalizzato e, se possibile, correggi il problema.
   2. Se l'errore non viene generato dal tuo codice personalizzato o se hai bisogno di assistenza, contatta l'assistenza Apigee.

Se hai bisogno di ulteriore assistenza per la risoluzione dei problemi relativi all'errore 500 Internal Server Error o sospetti che si tratti di un problema in Edge, contatta l'assistenza Apigee.

Determinare l'origine del problema

Utilizza una delle seguenti procedure per determinare se l'errore 500 Internal Server Error è stato generato durante l'esecuzione di una policy all'interno del proxy API o dal server di backend.

Utilizzare Trace nell'interfaccia utente

Nota: i passaggi descritti in questa sezione possono essere eseguiti sia dagli utenti di Public Cloud sia da quelli di Private Cloud.

1. Se il problema è ancora attivo, attiva la traccia nell'interfaccia utente per l'API interessata.
2. Una volta acquisita la traccia, seleziona la richiesta API che mostra il codice di risposta come 500.
3. Esamina tutte le fasi della richiesta API non riuscita e controlla quale fase restituisce l'errore 500 Internal Server Error:
   1. Se l'errore viene generato durante l'esecuzione di una policy, vai a Errore di esecuzione in una policy Edge.
   2. Se il server di backend ha risposto con l'errore 500 Internal Server Error, vai a Errore nel server di backend.

Utilizzare il monitoraggio delle API

Nota: i passaggi descritti in questa sezione possono essere eseguiti solo dagli utenti di Public Cloud.

Il monitoraggio delle API ti consente di isolare rapidamente le aree problematiche per diagnosticare problemi di errore, prestazioni e latenza e la loro origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Esamina uno scenario di esempio che mostra come risolvere i problemi 5xx con le API utilizzando il monitoraggio delle API. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di codici di stato 500 o di errori steps.servicecallout.ExecutionFailed supera una determinata soglia.

Utilizzare i log di accesso NGINX

Nota: i passaggi descritti in questa sezione sono destinati solo agli utenti di Edge Private Cloud only.

Puoi anche fare riferimento ai log di accesso NGINX per determinare se il codice di stato 500 è stato generato durante l'esecuzione di una policy all'interno del proxy API o dal server di backend. Questo è particolarmente utile se il problema si è verificato in passato o se è intermittente e non riesci ad acquisire la traccia nell'interfaccia utente. Segui questi passaggi per determinare queste informazioni dai log di accesso NGINX:

1. Controlla i log di accesso NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
2. Cerca eventuali errori 500 per il proxy API specifico durante la durata specifica durata.
3. Se sono presenti errori 500, controlla se si tratta di un errore di policy o di un server di destinazione, come mostrato di seguito:

   Esempio di voce che mostra un errore di policy

   

   Esempio di voce che mostra un errore del server di destinazione

   

4. Una volta identificato se si tratta di un errore di policy o di un server di destinazione:
   1. Se si tratta di un errore di policy, vai a Errore di esecuzione in una policy Edge.
   2. Se si tratta di un errore del server di destinazione, vai a Errore nel server di backend.