Errore interno del server (500)

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

Video

Guarda i seguenti video per scoprire di più su come risolvere i 500 errori interni del server.

Video Descrizione
Introduzione Offre un'introduzione agli errori interni del server (500 errori) e alle possibili cause. Illustra inoltre un errore interno 500 del server interno in tempo reale, insieme alla procedura per risolverlo.
Gestire gli errori di Callout di servizio ed Estrai variabili Mostra due errori interni del server 500 causati dai criteri Callout di servizio ed Estrai variabile e mostra come risolvere questi errori.
Gestire gli errori dei criteri JavaScript Mostra un errore interno del server 500 causato da un criterio JavaScript e i passaggi per risolvere l'errore.
Gestire gli errori dei server di backend Mostra un esempio di errore 500 del server interno causato da un errore del server di backend e mostra i passaggi per risolvere gli errori.

Sintomo

L'applicazione client riceve un codice di stato HTTP 500 con il messaggio "Errore interno del server" in risposta alle chiamate API. L'errore interno 500 del server 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 riscontrato una condizione imprevista che ha impedito di soddisfare la richiesta. In genere questo errore viene restituito dal server quando non è adatto 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 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 interno del server potrebbe essere visualizzato a causa di una serie di cause diverse. In Edge, le cause possono essere classificate in due categorie principali in base a dove si è verificato l'errore:

Causa Dettagli Sono forniti passaggi dettagliati per la risoluzione dei problemi
Errore di esecuzione in un criterio perimetrale Un criterio all'interno del proxy API potrebbe non funzionare per qualche motivo. Utenti di cloud privato e pubblico Edge
Errore del server di backend Il server di backend potrebbe restituire un errore per qualche motivo. Utenti di cloud privato e pubblico Edge

Errore di esecuzione in un criterio perimetrale

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

Diagnostica

Passaggi di diagnostica per utenti di cloud privati e pubblici

Se disponi della sessione dell'interfaccia utente di traccia relativa all'errore:

  1. Verifica che l'errore sia stato causato dall'esecuzione di un criterio. Per maggiori dettagli, 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 con 500 errore interno del server nella traccia.
  4. Esamina la richiesta e seleziona il criterio specifico non riuscito o il flusso denominato "Errore" che segue immediatamente il criterio non riuscito nella traccia.
  5. Per maggiori dettagli sull'errore, controlla il campo "Errore" nella sezione Proprietà o il contenuto Errore.
  6. Utilizzando i dettagli dell'errore che hai raccolto, prova a determinarne la causa.

Passaggi di diagnostica solo per gli utenti del cloud privato

Se non hai la sessione dell'interfaccia utente di traccia, procedi nel seguente modo:

  1. Verifica che l'errore si sia verificato durante l'esecuzione di un criterio. Per maggiori dettagli, consulta Determinazione dell'origine del problema.
  2. Se l'errore è stato causato dall'esecuzione dei criteri, continua. 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. Utilizza i log degli accessi NGINX come spiegato in Determinazione dell'origine del problema per determinare il criterio di errore nel proxy API e anche l'ID messaggio di richiesta univoco
  4. Controlla i log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) e cerca l'ID messaggio di richiesta univoco al suo interno.
  5. Se trovi l'ID messaggio di richiesta univoco, prova a ottenere ulteriori informazioni sulla causa dell'errore.

Risoluzione

Se hai stabilito la causa del problema con il criterio, prova a risolverlo correggendo il criterio ed eseguendo nuovamente il deployment del proxy.

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

Se hai bisogno di ulteriore assistenza per risolvere i problemi relativi all'errore interno 500 del server o sospetti che sia un problema all'interno di Edge, contatta l'assistenza Apigee.

Esempio 1: errore nel criterio Callout di servizio a causa di un errore nel server di backend

Se la chiamata al server di backend ha esito negativo nell'ambito del criterio Callout di servizio e restituisce un errore come 4XX o 5XX, verrà considerato un errore interno del server 500.

  1. Ecco un esempio in cui il servizio di backend ha esito negativo con un errore 404 all'interno del criterio Callout di servizio. 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 della traccia mostra il codice di stato 500 causato a causa di un errore nelle norme relative ai callout di servizio:

  3. In questo esempio, la proprietà "error" indica il motivo dell'errore relativo alle norme sui callout di servizio come "ResponseCode 404 is accepted as error". Questo errore può verificarsi se la risorsa a cui si accede tramite l'URL del server di backend nel criterio Callout di servizio non è disponibile.
  4. Verifica la disponibilità della risorsa sul server di backend. Potrebbe non essere disponibile temporaneamente/definitivamente oppure potrebbe essere stato spostato in una posizione diversa.

Esempio 1 di risoluzione

  1. Verifica la disponibilità della risorsa sul server di backend. Potrebbe non essere disponibile temporaneamente/definitivamente oppure potrebbe essere stato spostato in una posizione diversa.
  2. Correggi l'URL del server di backend nel criterio Callout di servizio in modo che rimandi a una risorsa valida ed esistente.
  3. Se la risorsa non è disponibile solo temporaneamente, prova a effettuare la richiesta API quando la risorsa sarà disponibile.

Esempio 2: errore nel criterio di estrazione delle variabili

Esaminiamo ora un altro esempio in cui è causato da un errore interno del server 500 a causa di un errore nel criterio di estrazione delle variabili e vediamo come risolvere il problema.

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

  2. Seleziona il criterio che restituisce errori, scorri verso il basso e controlla la sezione "Contenuti dell'errore" per maggiori dettagli:

  3. Il contenuto dell'errore indica che la variabile "serviceCallout.oamCookieValidationResponse" non è disponibile nel criterio Estrai variabili. Come indica il nome della variabile, deve contenere la risposta del criterio sui callout di servizio precedente.
  4. Seleziona le norme relative al callout di servizio nella traccia e potresti notare che la variabile "serviceCallout.oamCookieValidationResponse" non è stata impostata. Questo indica che la chiamata al servizio di backend non è riuscita, generando una variabile di risposta vuota.
  5. Sebbene il criterio relativo ai callout di servizio non sia riuscito, l'esecuzione dei criteri dopo il criterio callout di servizio continua perché il flag "continueOnError" nelle norme relative ai callout di servizio è 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 "X-Apigee.Message-ID" per questa richiesta API specifica della traccia, come segue:
    1. Seleziona la fase "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 l'ID messaggio univoco annotato nel passaggio 6. È stato osservato il seguente messaggio di errore per la richiesta API specifica: 
    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 Callout di servizio non è riuscito 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 comando telnet al server di backend dai processori di messaggi. Il comando telnet ha restituito l'errore "Sessione di connessione scaduta", 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 processori di messaggi Edge.
    • Se il server di backend non è in ascolto sulla porta specifica.

    Nell'esempio sopra illustrato, anche se il criterio Estrai variabili non è riuscito, la causa effettiva è che Edge non è riuscito a connettersi al server di backend nel criterio Callout del servizio. La causa di questo errore era che il server finale del backend non era configurato per consentire il traffico dai processori di messaggi Edge.

    Il tuo criterio di estrazione delle variabili avrà un comportamento diverso e potrebbe non riuscire per un motivo diverso. Puoi risolvere il problema in modo appropriato a seconda della causa dell'errore del criterio Estrai variabili controllando il messaggio nella proprietà error.

Esempio 2: risoluzione

  1. Correggi la causa dell'errore o dell'errore nel criterio Estrai variabili in modo appropriato.
  2. Nell'esempio sopra riportato, la soluzione consisteva nel correggere la configurazione di rete per consentire il traffico dai processori di messaggi Edge al server di backend. A questo scopo, inserisci gli indirizzi IP dei processori di messaggi nella lista consentita sul server di backend specifico. Ad esempio, su Linux, puoi utilizzare iptables per consentire il traffico dagli indirizzi IP del processore di messaggi sul server di backend.

Esempio 3: errore nel criterio JavaCallout

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

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

  2. Seleziona il flusso denominato "Error" seguito dalle norme sui callout Java non riuscite per ottenere i dettagli dell'errore, come mostrato nella figura di seguito:

  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 dall'interno del criterio JavaCallout. Il tuo callout Java si comporterà in modo diverso e completerà un messaggio diverso nella proprietà error.
  4. Controlla il codice del criterio JavaCallout e verifica la configurazione corretta da utilizzare.

Esempio 3: risoluzione

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

Errore del server di backend

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

Diagnostica

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 Determinazione dell'origine del problema.
  2. Se l'errore è stato causato dal server di backend, continua. Se l'errore si è verificato durante l'esecuzione del criterio, vai a Errore di esecuzione nel criterio Edge.
  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 che il backend sia un server Node.js:

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

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

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

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

  1. Nello strumento Trace, seleziona la richiesta API non riuscita con 500 errore interno del server.
  2. Seleziona la fase "Risposta ricevuta dal server di destinazione" dalla richiesta API con esito negativo, come mostrato nella figura seguente:

  3. Consulta la sezione "Contenuti della risposta" per informazioni dettagliate sull'errore.

  4. In questo esempio, il contenuto della risposta, che è una busta SOAP, mostra la stringa di errore come messaggio "Non autorizzato". La causa più probabile di questo problema è che le credenziali corrette (nome utente/password, token di accesso e così via) non vengono trasmesse al server di backend dall'utente. 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 Node.js per il proxy API specifico nell'interfaccia utente Edge (sia gli utenti di Cloud pubblico che quelli di cloud privato possono controllare i log Node.js). Se sei un utente del cloud privato Edge, puoi anche controllare i log del processore 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 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 correggi il problema, se possibile.
    2. Se l'errore non viene generato dal codice personalizzato o se hai bisogno di assistenza, contatta l'Assistenza Apigee.

Se hai bisogno di ulteriore assistenza per risolvere i problemi relativi all'errore interno 500 del server o sospetti che sia un problema all'interno di Edge, contatta l'assistenza Apigee.

Determinazione dell'origine del problema

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

Utilizzo di Trace nell'interfaccia utente

Nota: i passaggi in questa sezione possono essere eseguiti dagli utenti del cloud pubblico e privato.

  1. Se il problema è ancora attivo, abilita la traccia nell'interfaccia utente 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 controlla quale fase restituisce l'errore interno 500 del server:
    1. Se l'errore viene visualizzato durante l'esecuzione di un criterio, vai alla sezione Errore di esecuzione in un criterio perimetrale.
    2. Se il server di backend ha risposto con 500 Internal Server, passa a Error in the Backend Server.

Utilizzo di API Monitoring

Nota: i passaggi in questa sezione possono essere eseguiti solo dagli 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 relativa origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

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

Utilizzo dei log degli accessi NGINX

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

Puoi anche fare riferimento ai log di NGINX Access per determinare se il codice di stato 500 è stato generato durante l'esecuzione di un criterio nel proxy API o dal server di backend. Questa operazione è 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 degli accessi di NGINX:

  1. Controlla i log degli accessi 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 nella durata specifica.
  3. Se sono presenti errori 500, controlla se l'errore riguarda un criterio o un errore del server di destinazione, come mostrato di seguito:

    Voce di esempio che mostra un errore relativo alle norme

    Esempio di voce che mostra un errore del server di destinazione

  4. Dopo aver identificato se si tratta di un errore del criterio o del server di destinazione:
    1. Se si tratta di un errore del criterio, vai a Errore di esecuzione in un criterio perimetrale.
    2. Vai a Errore nel server di backend se si tratta di un errore del server di destinazione.