Errore interno del server 500: server di backend

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

Video

Video Descrizione
500 Errore interno del server, causato dal backend Mostra un valore 500 Internal Server Error in tempo reale causato dal server di backend, oltre alla procedura per risolvere l'errore.

Sintomo

L'applicazione client riceve un codice di stato HTTP 500 con il messaggio Internal Server Error come risposta per le chiamate API.

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

L'applicazione client riceve il seguente codice di risposta:

HTTP/1.1 500 Internal Server Error

Inoltre, potrebbe essere visualizzato un messaggio di errore simile a quello mostrato di seguito:

Esempio 1

Esempio di risposta del server di backend n. 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Esempio 2

Esempio di risposta del server di backend n. 2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

Possibili cause

Il server di backend potrebbe restituire 500 Internal Server Error a causa di una serie di cause. Questo playbook spiega come risolvere i problemi utilizzando i passaggi più comuni e risolvere l'errore indipendentemente dalla sua causa.

Le possibili cause di questo problema sono le seguenti:

Causa Descrizione Istruzioni per la risoluzione dei problemi applicabili a
Errore del server di backend Il server di backend potrebbe restituire un errore per qualche motivo. Utenti di cloud privato e pubblico Edge

Passaggi di diagnosi più comuni

Utilizza uno dei seguenti strumenti/tecniche per diagnosticare questo errore:

Monitoraggio delle API

Procedura 1: utilizzo del monitoraggio delle API

Per diagnosticare l'errore utilizzando il monitoraggio delle API:

  1. Accedi alla UI di Apigee Edge come utente con un ruolo appropriato.
  2. Passa all'organizzazione in cui vuoi esaminare il problema.

  3. Vai alla pagina Analizza > Monitoraggio API > Esamina.
  4. Seleziona il periodo di tempo specifico in cui hai riscontrato gli errori.
  5. Traccia Codice di errore su Ora.

  6. Seleziona una cella con il codice di errore messaging.adaptors.http.flow.ErrorResponseCode come mostrato di seguito:

    ( visualizza immagine ingrandita)

  7. Le informazioni sul codice di errore messaging.adaptors.http.flow.ErrorResponseCode vengono visualizzate come mostrato di seguito:

    ( visualizza immagine ingrandita)

  8. Fai clic su Visualizza log ed espandi la riga della richiesta non riuscita.

    ( visualizza immagine ingrandita)

  9. Nella finestra Log, prendi nota dei seguenti dettagli:
    • ID messaggio di richiesta
    • Codice di stato: 500
    • Origine errore: target
    • Codice di errore: messaging.adaptors.http.flow.ErrorResponseCode

Traccia

Procedura 2: utilizzo dello strumento Trace

Per diagnosticare l'errore utilizzando lo strumento Trace:

  1. Abilita la sessione di traccia e
    • Attendi che si verifichi l'errore 500 Internal Server Error con il codice di errore messaging.adaptors.http.flow.ErrorResponseCode oppure
    • Se riesci a riprodurre il problema, esegui la chiamata API per riprodurlo 500 Internal Server Error
  2. Assicurati che l'opzione Mostra tutte le FlowInfos sia abilitata:

  3. Seleziona una delle richieste non riuscite ed esamina la traccia.
  4. Naviga tra le diverse fasi della traccia e individua il punto in cui si è verificato l'errore.
  5. In genere, l'errore si verifica in un flusso successivo alla fase Risposta ricevuta dal server di destinazione, come mostrato di seguito:

    ( visualizza immagine ingrandita)

  6. Vai alla fase AX (Analytics Data Recorded) della traccia e fai clic.
  7. Scorri verso il basso fino alla sezione Intestazioni della risposta ai dettagli della fase e determina i valori di X-Apigee-fault-code, X-Apigee-fault-source e X-Apigee-Message-ID, come mostrato di seguito:

    ( visualizza immagine ingrandita)

  8. Prendi nota dei valori di X-Apigee-fault-code, X-Apigee-fault-source e X-Apigee-Message-ID:
  9. Intestazioni della risposta Valore
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Procedura 3: utilizzo dei log degli accessi di NGINX

Per diagnosticare l'errore utilizzando i log degli accessi di NGINX:

  1. Se sei un utente Private Cloud, puoi utilizzare i log degli accessi di NGINX per determinare le informazioni chiave su HTTP 500 Internal Server Error.
  2. Controlla i log degli accessi di NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Cerca per vedere se si sono verificati errori 500 con il codice di errore messaging.adaptors.http.flow.ErrorResponseCode durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non funzionare con 500.
  4. Se riscontri errori 500 con X-Apigee-fault-code corrispondente al valore di X-Apigee-fault-code , determina il valore di X-Apigee-fault-code

    Esempio di errore 500 dal log degli accessi di NGINX:

    ( visualizza immagine ingrandita)

    La voce di esempio sopra riportata dal log degli accessi di NGINX ha i seguenti valori per X-Apigee-fault-code e X-Apigee-fault-source:

    Intestazioni Valore
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Causa: errore nel server di backend

Diagnostica

La risposta 500 Internal Server Error dal server di backend può essere causata da diversi motivi. Dovrai diagnosticare ogni situazione in modo indipendente.

  1. Determina il codice di errore, l'origine del guasto per l'errore osservato utilizzando il monitoraggio delle API, lo strumento Trace o i log degli accessi NGINX, come spiegato nella sezione Passaggi comuni di diagnosi.
  2. Se l'Origine dell'errore è target e il Codice di errore è messaging.adaptors.http.flow.ErrorResponseCode, ciò indica che l'errore viene restituito dal server di backend.
  3. Puoi eseguire uno dei seguenti passaggi per diagnosticare la causa del problema:

    Traccia

    Utilizzo di Trace:

    Se è disponibile una sessione di traccia per l'errore, segui questi passaggi:

    1. In Trace, seleziona la richiesta API non riuscita con 500 Internal Server Error.
    2. Seleziona la fase Risposta ricevuta dal server di destinazione dalla richiesta API in errore, come mostrato nella figura seguente:

      ( visualizza immagine ingrandita)

    3. Scorri verso il basso fino alla sezione Dettagli fase e controlla il Contenuto della risposta,che contiene la risposta del server di backend.

      Esempio di contenuti della risposta:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
         <Body>
            <Error>
               <code>500</code>
               <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
            </Error>
         </Body>
      </Envelope>
      

      Nella risposta precedente, tieni presente che il messaggio di errore del server di backend è Non autorizzato. Questo indica che l'utente potrebbe aver trasmesso credenziali non valide ed è per questo che riceve questo errore.

    Chiama server di backend

    Chiamata diretta al server di backend:

    Puoi effettuare una chiamata diretta al server di backend e:

    • Verifica se stai ricevendo la stessa risposta 500 Internal Server Error ricevuta quando la richiesta è stata effettuata tramite Apigee Edge
    • Controlla il messaggio di errore (risposta) ricevuto dal server di backend

    Per effettuare la chiamata diretta al server di backend, segui questi passaggi:

    1. Assicurati di disporre di tutte le intestazioni, dei parametri di query e di tutte le credenziali che devono essere trasmesse al server di backend nell'ambito della richiesta.
    2. Se il servizio di backend è accessibile pubblicamente, puoi utilizzare il comando curl, Postman o qualsiasi altro client REST e richiamare direttamente l'API del server di backend.
    3. Se il server di backend è accessibile solo dai processori di messaggi, puoi utilizzare il comando curl, Postman o qualsiasi altro client REST e richiamare l'API del server di backend direttamente dal processore di messaggi.

    4. Verifica se il servizio di backend restituisce effettivamente 500 Internal Server Error e controlla il messaggio di errore (risposta) restituito dal server di backend e determina la causa dell'errore.

    Log del server di backend

    Utilizzare i log del server di backend

    1. Esamina i log del server di backend e prova a ottenere maggiori dettagli sull'errore e sulla causa.
    2. Se possibile, abilita la modalità di debug sul server di backend per ottenere ulteriori dettagli sull'errore e sulla causa.
  4. Verifica se stai utilizzando il concatenamento del proxy nell'endpoint di destinazione specifico del proxy API con errori, ovvero se l'endpoint del server/target di destinazione sta richiamando un altro proxy in Apigee Edge. Per determinarlo:

    1. Se disponi della traccia per la richiesta non riuscita, vai alla fase Richiesta inviata al server di destinazione e fai clic su Mostra Curl.

    2. Si apre la finestra Curl per la richiesta inviata al server di destinazione da cui puoi determinare l'alias host del server di destinazione.
    3. Esamina l'endpoint di destinazione del proxy API e controlla se l'URL del server di backend o il nome host nel server di destinazione punta a un altro proxy o al tuo server di backend.
    4. Se l'alias dell'host del server di destinazione rimanda a un alias host virtuale, si tratta di un concatenamento di proxy. In questo caso, devi ripetere tutti i passaggi precedenti per il proxy concatenato fino a determinare la causa effettiva di 500 Internal Server Error. In questi casi, 500 Internal Server Error potrebbe verificarsi anche in altri proxy concatenati in altre fasi, che possono essere diagnosticati e risolti utilizzando le istruzioni fornite in questo playbook o nel playbook 500 Internal Server Error.
    5. Se l'alias dell'host del server di destinazione rimanda al tuo server di backend, vai alla sezione Risoluzione.

Risoluzione

Se hai la certezza che l'errore 500 proviene dal server di backend, collabora con il team del tuo server di backend per risolvere il problema in modo appropriato.

Nell'esempio discusso sopra, per risolvere il problema potresti dover richiedere agli utenti di passare credenziali valide.

Punti chiave da considerare

  1. Il messaggio di errore effettivo restituito dal server di backend per 500 Internal Server Error può essere visualizzato solo se hai acquisito la sessione di traccia per le richieste con errori.
  2. Per motivi di sicurezza, la risposta del server di backend non verrà registrata nei log di API Monitoring, NGINX Access Logs o Message Processor.
  3. Puoi esaminare i log del server di backend o attivare la modalità di debug sul backend per ottenere maggiori dettagli su 500 Internal Server Error e/o visualizzare il messaggio di errore restituito dal server di backend.

Devi raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee Edge.

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

  • Nome dell'organizzazione.
  • Nome ambiente
  • Nome proxy API
  • Completa il comando curl per riprodurre l'errore 500
  • File di traccia contenente le richieste con 500 Internal Server Error
  • Se al momento gli errori 500 non si verificano, fornisci il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati 500 errori in passato.

Se sei un utente Private Cloud, fornisci le seguenti informazioni:

  • Messaggio di errore completo osservato per le richieste non riuscite
  • Organizzazione, nome dell'ambiente e nome del proxy API per i quali stai osservando 500 errore
  • Bundle di proxy API
  • File di traccia contenente le richieste con 500 Internal Server Error
  • Log degli accessi NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Dove: ORG, ENV e PORT# vengono sostituiti con valori effettivi.

  • Log di sistema del processore di messaggi /opt/apigee/var/log/edge-message-processor/logs/system.log
  • Il periodo di tempo con le informazioni sul fuso orario nel momento in cui si sono verificati gli errori 500.