Errore interno del server (500)

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

Video

Guarda i video che seguono per scoprire di più sulla risoluzione dei problemi relativi alla risoluzione 500 di errori interni del server.

Video Descrizione
Introduzione Fornisce un'introduzione alla lettura di 500 errori interni del server e delle possibili cause. Dimostra anche un errore interno del server 500 in tempo reale, insieme ai passaggi per la risoluzione dei problemi e l'errore.
Gestire gli errori di tipo callout di servizio ed estrazione delle variabili Mostra due errori interni del server 500 causati dai criteri di callout del servizio e di estrazione delle variabili e mostra come risolvere e risolvere questi errori.
Gestire gli errori dei criteri JavaScript Mostra un errore interno del server 500 causato da un criterio JavaScript e dai passaggi per individuare e correggere l'errore.
Gestire gli errori dei server di backend Mostra l'esempio 500 di errori interni del server causati da un errore del server di backend e i passaggi. risolvere gli errori.

Sintomo

L'applicazione client riceve un codice di stato HTTP 500 con il messaggio "Errore interno del server" come risposta alle chiamate API. Server interno 500 l'errore potrebbe essere causato da un errore durante l'esecuzione di qualsiasi criterio 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 rilevato una condizione imprevista che gli ha impedito di soddisfare la richiesta. Questo errore di solito è restituito dal server quando non è idoneo nessun altro codice di errore.

Messaggi di errore

Potresti visualizzare il seguente messaggio di errore:

HTTP/1.1 500 Internal Server Error

In alcuni casi, potresti notare un altro messaggio di errore con ulteriori dettagli. Ecco un esempio 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 interno del server potrebbe essere generato a causa di diverse cause. In Edge, le cause possono essere classificate in due categorie principali in base a dove si è verificato l'errore:

Causa Dettagli Sono disponibili procedure dettagliate per la risoluzione dei problemi
Errore di esecuzione in un criterio perimetrale A Norme all'interno del proxy API potrebbe non riuscire per qualche motivo. Utenti Edge di cloud privato e pubblico
Errore nel server di backend Il server di backend potrebbe non riuscire per qualche motivo. Utenti Edge di cloud privato e pubblico

Errore di esecuzione in un criterio Edge

Un criterio entro il proxy API potrebbe non riuscire per qualche motivo. Questa sezione spiega come risolvere il problema se l'errore 500 interno del server si verifica durante l'esecuzione di un criterio.

Diagnosi

Passaggi diagnostici per gli utenti del cloud privato e pubblico

Se disponi della sessione dell'interfaccia utente di traccia per l'errore, procedi come segue:

  1. Verifica che l'errore sia stato causato dall'esecuzione di un criterio. Per informazioni dettagliate, consulta Determinazione dell'origine del problema.
  2. Se l'errore si è verificato durante l'esecuzione del criterio, 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 e restituisce 500 errore interno del server nella traccia.
  4. Esamina la richiesta e seleziona il criterio specifico che non ha avuto esito positivo o il flusso denominato "Errore" che segue immediatamente il criterio con errori nella traccia.
  5. Per maggiori dettagli sull'errore, controlla "l'errore" nella sezione Proprietà o il contenuto dell'errore.
  6. Cerca di capire la causa dell'errore utilizzando i dettagli che hai raccolto.

Passaggi diagnostici solo per utenti del cloud privato

Se non vedi la sessione dell'interfaccia utente di traccia, procedi come segue:

  1. Verifica che l'errore si sia verificato durante l'esecuzione di un criterio. Per informazioni dettagliate, consulta Determinazione dell'origine del problema.
  2. Se l'errore è stato causato dall'esecuzione del criterio, continua. Se l'errore si è verificato durante l'applicazione del criterio dell'esecuzione, continua. Se l'errore è stato causato dal server di backend, vedi Errore nel server di backend.
  3. Usa i log di accesso NGINX come spiegato in Determinazione l'origine del problema per determinare il criterio di errore nel proxy API e anche il ID messaggio di richiesta univoco
  4. Controllare i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) e cerca il univoco del messaggio di richiesta.
  5. Se trovi l'ID univoco del messaggio di richiesta, verifica se riesci a ottenere ulteriori informazioni sull' causa dell'errore.

Risoluzione

Se hai stabilito la causa del problema relativo alle norme, prova a risolverlo nel correggere il criterio ed eseguire nuovamente il deployment del proxy.

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

Se occorre ulteriore assistenza per la risoluzione dell'errore interno del server 500 o si sospetta che si tratta di un problema di Edge, contatta Apigee assistenza.

Esempio 1: errore nel criterio relativo al callout del servizio a causa di un errore nel backend server web

Se la chiamata al server di backend non va a buon fine all'interno del criterio callout di servizio e si verificano errori come come 4XX o 5XX, verrà trattato come 500 errore interno del server.

  1. Ecco un esempio in cui il servizio di backend non funziona e viene restituito un errore 404 all'interno del servizio Norme sui callout. All'utente finale viene inviato il seguente messaggio di errore: 
    {
"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 traccia mostra il codice di stato 500 causato da un errore nel servizio Norme sui callout:

  3. In questo esempio, l'errore elenca il motivo della norma relativa ai callout di servizio errore in quanto "ResponseCode 404 viene considerato come un errore". Questo errore può verificarsi se la risorsa a cui si accede tramite l'URL del server di backend nel criterio callout di servizio non è disponibili.
  4. Verifica la disponibilità della risorsa sul server di backend. Potrebbe non essere disponibile in modo temporaneo/definitivo o potrebbe essere stato spostato in un'altra posizione.

Esempio di risoluzione 1

  1. Verifica la disponibilità della risorsa sul server di backend. Potrebbe non essere disponibile in modo temporaneo/definitivo o potrebbe essere stato spostato in un'altra posizione.
  2. Correggi l'URL del server di backend nel criterio relativo al callout di servizio in modo che rimandi a un indirizzo valido ed esistente risorsa.
  3. Se la risorsa è temporaneamente non disponibile, prova a effettuare la richiesta API dopo e la risorsa è disponibile.

Esempio 2: errore nel criterio di estrazione delle variabili

Vediamo ora un altro esempio in cui 500 errore interno del server è causato da un errore. nel criterio Estrai variabili e scopri come risolvere il problema.

  1. La seguente traccia nella sessione UI mostra il codice di stato 500 a causa di un errore in Estrai Criterio variabili:

  2. Seleziona il criterio di estrazione delle variabili con errori, scorri verso il basso e osserva l'"Errore "Contenuti" per ulteriori dettagli:

  3. Il contenuto dell'errore indica che la variabile "serviceCallout.oamCookieValidationResponse" non è disponibile in il criterio Estrai variabili. Come indica il nome della variabile, questa deve contenere la stringa del precedente criterio relativo ai callout di servizio.
  4. Se selezioni il criterio callout di servizio nella traccia, potresti notare che "serviceCallout.oamCookieValidationResponse" non è stata impostata. Questo indica che la chiamata al servizio di backend non è riuscita, generando una risposta vuota .
  5. Sebbene il criterio relativo al callout del servizio non sia andato a buon fine, l'esecuzione dei criteri dopo il servizio Le norme sui callout continuano perché l'errore "continueOnError" in un criterio relativo ai callout di servizio sia 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 messaggio univoco &quot;X-Apigee.Message-ID&quot; per questa API specifica. richiesta dalla traccia, come segue:
      .
    1. Seleziona i "Dati di Analytics registrati" dalla richiesta.
    2. Scorri verso il basso e nota il 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 il valore l'ID messaggio indicato nel passaggio 6. È stato osservato il seguente messaggio di errore per l'API specifica richiesta: 
    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 riportato sopra indica che il criterio relativo al callout del servizio non è riuscito a causa di una connessione errore di timeout durante la connessione al server di backend.

  8. Per determinare la causa dell'errore di timeout della connessione, è stato eseguito il comando telnet al server di backend dai processori di messaggi. Telnet ha restituito il messaggio "Connection timed out" (Timeout 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 dal messaggio Edge Processori.
    • Se il server di backend non è in ascolto sulla porta specifica.

    Nell'esempio illustrato sopra, sebbene il criterio di estrazione delle variabili non sia andato a buon fine, i valori effettivi è che Edge non è riuscito a connettersi al server di backend nel callout di servizio . La causa di questo errore è che il server finale di backend non è stato configurato consentire il traffico dai processori di messaggi Edge.

    Il tuo criterio di estrazione delle variabili avrà un comportamento diverso e potrebbe non funzionare per un altro perché. Puoi risolvere il problema in modo appropriato in base alla causa dell'errore di il criterio Estrai variabili controllando il messaggio nell'errore proprietà.

Esempio di risoluzione 2

  1. Correggi in modo appropriato la causa dell'errore o dell'errore nel criterio Estrai variabili.
  2. Nell'esempio illustrato sopra, la soluzione era rettificare la configurazione di rete in consentire il traffico dai processori di messaggi Edge al tuo server di backend. Questo è stato fatto nella lista consentita dei processori di messaggi indirizzi IP sullo specifico server di backend. Ad esempio: su Linux, potresti usare iptables per consentire il traffico Indirizzi IP del processore di messaggi sul server di backend.

Esempio 3: errore nel criterio di callout Java

Vediamo ora un altro esempio in cui 500 errore interno del server è causato da un errore. nelle norme relative ai callout Java e scopri come risolvere il problema.

  1. La seguente traccia dell'interfaccia utente mostra il codice di stato 500 a causa di un errore nelle norme sui callout Java:

  2. Seleziona il flusso denominato "Error" seguito dal criterio callout Java non riuscito. per ottenere i dettagli dell'errore, come illustrato 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 dal criterio JavaCallout. Il tuo callout Java si comporterà in modo diverso inserire un messaggio diverso nella proprietà error.
  4. Controlla il codice dei criteri JavaCallout e conferma la corretta configurazione necessaria in uso.

Esempio di risoluzione 3

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

Errore nel server di backend

Un errore interno del server 500 potrebbe anche provenire dal server di backend. Questa sezione spiega come risolvere il problema se l'errore proviene dal server di backend.

Diagnosi

Procedura diagnostica per tutti gli utenti

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

  1. Verifica che l'errore sia stato causato dal server di backend. Per informazioni dettagliate, consulta Determinazione dell'origine del problema.
  2. Se l'errore è stato causato dal server di backend, continua. Se l'errore si è verificato durante dell'esecuzione dei criteri, vai a Errore di esecuzione in Edge Norme.
  3. Segui i passaggi riportati di seguito a seconda che tu abbia accesso o meno a una sessione di Trace per l'API non riuscita o se il backend è un server Node.js:

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

  1. Se la traccia UI non è disponibile per la richiesta non riuscita, controlla il server di backend. per ottenere i dettagli dell'errore.
  2. Se possibile, abilita la modalità di debug sul server di backend per avere maggiori dettagli e la causa.

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

Se è presente una sessione Trace, i passaggi che seguono ti aiuteranno a diagnosticare il problema.

  1. Nello strumento Trace, seleziona la richiesta API che non ha avuto esito positivo con 500 server interni Errore.
  2. Seleziona la fase "Risposta ricevuta dal server di destinazione" dall'errore Richiesta API come illustrato nella figura seguente:

  3. Controlla la sezione "Contenuti della risposta" per ottenere i dettagli dell'errore.

  4. In questo esempio, il contenuto della risposta, che è una busta SOAP, mostra la stringa di errore come Messaggio "Non autorizzata". La causa più probabile è il problema è che le credenziali corrette (nome utente/password, token di accesso ecc.) non vengono passate al server di backend dall'utente. Questo problema può essere risolto trasmettendo le credenziali corrette a il 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 lo specifico proxy API nella UI perimetrale (gli utenti del cloud pubblico e privato possono controlla i log di Node.js). Se sei un utente di Edge Private Cloud, Controlla anche i log dell'elaboratore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per ulteriori dettagli sull'errore.

    Opzione Log NodeJS nella UI Edge - Scheda Panoramica del proxy API

Risoluzione

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

Se occorre ulteriore assistenza per la risoluzione dell'errore interno del server 500 o si sospetta che si tratta di un problema di Edge, contatta Apigee assistenza.

Determinazione dell'origine del problema

Utilizza una delle seguenti procedure per determinare se è stato generato l'errore 500 interno del server durante l'esecuzione di un criterio nel proxy API o dal server di backend.

Utilizzo di Trace nella UI

Nota: i passaggi in questa sezione possono essere eseguiti sia dal pubblico che dal pubblico Utenti del cloud privato.

  1. Se il problema è ancora attivo, abilita la traccia nella UI per l'API interessata.
  2. Dopo aver acquisito la traccia, seleziona la richiesta API che mostra il codice di risposta come 500.
  3. Naviga attraverso tutte le fasi della richiesta API non riuscita e verifica quale fase restituisce l'errore 500 interno del server:
    1. Se viene generato un errore durante l'esecuzione di un criterio, vai a Errore di esecuzione in un criterio perimetrale.
    2. Se il server di backend ha risposto con un errore di tipo 500 Internal Server, passa alla sezione Errore nel server di backend.

Utilizzo del monitoraggio delle API

Nota: i passaggi in questa sezione possono essere eseguiti solo da utenti del cloud pubblico.

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

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

Utilizzo dell'accesso NGINX Log

Nota: i passaggi di questa sezione sono per gli utenti di Edge Private Cloud .

Puoi anche fare riferimento ai log di accesso NGINX per determinare se è stato generato il codice di stato 500 durante l'esecuzione di un criterio nel proxy API o dal server di backend. Questo è particolarmente utile se il problema si è verificato in passato o se il problema è intermittente e tu non sono in grado di acquisire la traccia nell'interfaccia utente. Per determinare queste informazioni: Log di accesso NGINX:

  1. Controlla i log di accesso di NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
  2. Cerca se sono presenti 500 errori per il proxy API specifico in quel determinato durata massima.
  3. Se sono presenti errori 500, verifica se l'errore riguarda un criterio o un errore del server di destinazione. come mostrato di seguito:

    Voce di esempio che mostra un errore di criterio

    Voce di esempio che mostra un errore del server di destinazione

  4. Dopo aver identificato se si tratta di un errore relativo a un criterio o a un errore del server di destinazione:
    1. Passa a Errore di esecuzione in un criterio Edge se si tratta di un errore relativo alle norme.
    2. Passa a Errore nel server di backend se è una destinazione del server.