Errore interno del server 500 - Streaming abilitato

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

Sintomo

L'applicazione client riceve un codice di stato della risposta HTTP 500 con il messaggio Errore interno del server per le chiamate API.

Messaggi di errore

Le applicazioni client potrebbero ricevere una risposta di errore come illustrato di seguito: 

HTTP/1.1 500 Internal Server Error

Potrebbe essere seguito da un messaggio di errore simile al seguente: 

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

Possibili cause

L'errore 500 interno del server può verificarsi per diverse cause. Questo playbook è incentrato sul 500 errore interno del server causato dall'accesso alla richiesta/risposta durante lo flussi di dati sia abilitato.

Causa Descrizione Chi può eseguire la procedura di risoluzione dei problemi
Accesso al payload con Streaming abilitato Si è verificato un errore perché si accede al payload di richiesta/risposta quando è abilitato il flusso di dati. Utenti periferici di cloud privati e pubblici

Causa: accesso al payload con streaming abilitato

Diagnosi

Procedura n. 1: utilizzo di Trace

  1. Attiva la traccia sessione ed effettuare la chiamata API per riprodurre il problema - 500 Errore interno del server.
  2. Seleziona una delle richieste non riuscite ed esamina la traccia.
  3. Naviga attraverso le varie fasi della traccia e individua dove si è verificato l'errore.
  4. Questo errore potrebbe essersi verificato durante l'analisi del payload di richiesta/risposta da parte di un criterio.
  5. Ecco uno screenshot di traccia di esempio che mostra il file JSONThreatProtection criterio non riuscito con l'errore "Expecting } alla riga 1":

    alt_text

    Prendi nota delle seguenti informazioni dall'output della traccia, come mostrato in precedenza screenshot:

    Criterio in stato di errore: JSONThreatProtection

    Flow: richiesta proxy

  6. Esamina la definizione del criterio con errori e controlla il payload che viene analizzato.

    Nello scenario di esempio, esamina il criterio JSONThreatProtection denominato JSON-Threat-Protection con errore e controlla l'elemento <Source>. 

    <JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

    Nota che l'elemento <Source> rimanda a request.. Ciò significa che si è verificato l'errore durante l'analisi del payload della richiesta.

  7. Determinare il tipo di payload da analizzare controllando la richiesta API.

    8. Puoi controllare i contenuti del payload della richiesta e dell'intestazione Content-Type in la richiesta API. Nel comando curl di esempio seguente viene utilizzato un payload JSON. 

    curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

    Puoi anche controllare il criterio che non funziona e determinare il tipo di payload che viene analizzato. Nello scenario di esempio riportato sopra, il criterio JSON-Threat-Protection non funziona. Questo indica che il payload deve essere in formato JSON.

  8. Verifica che il payload sia nel formato corretto. Se il payload non è valido, puoi visualizzare questo errore.

  9. Se il payload è valido, ma continui a ricevere errori come elencato nella Messaggi di errore, specifica la causa. è che si accede al payload quando è abilitato il flusso di dati.

    A seconda del payload che viene analizzato dal criterio (come determinato nel passaggio 6), esaminare i contenuti del payload nello strumento Trace nella fase appropriata.

    Nello scenario di esempio, il payload della richiesta viene analizzato, quindi esamina la fase "Richiesta ricevuta dal cliente" della traccia e controllare Contenuti della richiesta.

    alt_text

    Se il contenuto della richiesta risulta vuoto come mostrato nello screenshot sopra, anche se hai inviato un payload valido, indica che la probabile causa del problema è il flusso di richieste sia abilitato.

    Questo perché, quando è abilitato il flusso di dati, il payload della richiesta non verrà visualizzato nella traccia.

    Analogamente, se il payload della risposta viene analizzato quando si verifica l'errore, controlla la contenuti della risposta nella fase "Risposta ricevuta dal server di destinazione".

  10. Quindi, esamina le definizioni degli endpoint proxy e di destinazione a seconda di dove si è verificato l'errore viene usato nel flusso proxy API. Verifica che il flusso di dati sia stato abilitato.

    Nello scenario di esempio, il criterio con errori è stato eseguito nel flusso di richieste proxy (come stabilito nel precedente passaggio 5). esamina quindi l’endpoint proxy: 

    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>

    Come si vede nell'esempio precedente, il flusso di richieste è stato abilitato come indicato proprietà "request.streaming.enabled" impostata su true.

    Di conseguenza, la causa dell'errore è l'utilizzo del criterio JSONThreatProtection nel proxy API che accede al payload della richiesta quando è abilitato il flusso di dati. Questo causa errori attiva il buffering nel proxy API e rifiuta lo scopo di utilizzare l'utilizzo di flussi di dati in Apigee Edge.

    Questo errore potrebbe non essere visualizzato con payload più piccoli, ma quando utilizzi payload più grandi, puoi vedere questi errori.

  11. Puoi verificare che l'errore 500 sia causato dal criterio controllando il valore di &quot;X-Apigee-fault-source&quot; nel campo "AX" (Dati di Analytics registrati) Fase di analisi seguendo i passaggi riportati di seguito:
      .
    1. Fai clic sulla fase "AX" (dati di Analytics registrati) come mostrato nello screenshot di seguito:

      alt_text

    2. Scorri i dettagli della fase fino alla sezione "Intestazioni degli errori". e determinare i valori di "X-Apigee-fault-code", &quot;X-Apigee-fault-source&quot; e "X-Apigee-fault-policy" come illustrato di seguito:

      alt_text

    3. Se il valore di &quot;X-Apigee-fault-source&quot; è "policy" come mostrato nell'immagine riportata sopra, indica che l'errore è causato dall'accesso da parte dei criteri quando è abilitato il flusso di dati.

Risoluzione

L'accesso al payload con la modalità flusso abilitato è un anti-pattern, come spiegato in Antipattern: consente di accedere al payload di richiesta/risposta quando è abilitato il flusso di dati.

  1. Se desideri elaborare il payload, devi disabilitare il flusso di dati nel proxy/target Endpoint rimuovendo le proprietà "request.streaming.enabled" and "response.streaming.enabled" come mostrato nell'esempio del ProxyEndpoint riportato di seguito: 
    <ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>

    OPPURE

  2. Se vuoi utilizzare l'accesso in modalità flusso per i proxy API, non utilizzare alcun criterio nella Proxy API che accedono al payload di richiesta/risposta.

Nota

  • In questo playbook, è stato utilizzato il criterio JSONThreatProtection per elaborare il payload della richiesta con mentre nello scenario di esempio è abilitato il flusso di dati. Questo ha generato 500 errori interni del server con errori diversi.
  • Questi errori possono essere visualizzati anche in criteri come JSONToXML e XMLToJSON, che elaborano payload di richiesta o risposta quando è abilitato il flusso di dati.
  • Consigliamo vivamente di non utilizzare questi criteri nei proxy che richiedono l'accesso a quando è abilitato il flusso di dati.
  • Questo è un anti-pattern, come documentato Antipattern: consente di accedere al payload di richiesta/risposta quando è abilitato il flusso di dati.

Diagnosticare i problemi utilizzando il monitoraggio delle API

Se sei un utente del cloud privato, salta questa procedura.

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 backend o 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 errori supera una determinata soglia.

Se vuoi ricevere una notifica quando viene generata una risposta di errore 500 dal criterio, devi configurare l'avviso per il codice di stato 500 con l'origine dell'errore come proxy.

Raccogliere informazioni diagnostiche

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

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

  • Nome dell'organizzazione
  • Nome ambiente
  • Nome proxy API
  • Completa il comando curl con il payload della richiesta (se presente) per riprodurre l'errore 500.
  • File di traccia contenente le richieste con errore interno del server 500
  • Se al momento gli errori 500 non si verificano, indica il periodo di tempo con le informazioni relative al fuso orario in cui si sono verificati errori 500 nel passato.

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

  • Messaggio di errore completo osservato per le richieste non riuscite
  • Organizzazione, Nome ambiente e Nome proxy API per i quali si verificano errori 500
  • Bundle proxy API
  • Payload utilizzato nella richiesta (se presente)
  • File di traccia contenente le richieste con errore interno del server 500
  • Log di accesso NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  • Log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  • Il periodo di tempo con le informazioni sul fuso orario in cui si sono verificati gli errori 500.