Diese Seite wurde von der Cloud Translation API übersetzt.

500 Interner Serverfehler – Streaming aktiviert

<ph type="x-smartling-placeholder"></ph> Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur Apigee X-Dokumentation. Weitere Informationen

Symptom

Die Clientanwendung empfängt den HTTP-Antwortstatuscode 500 mit Für API-Aufrufe wird die Meldung Internal Server Error angezeigt.

Fehlermeldungen

Die Client-Anwendungen erhalten möglicherweise eine der folgenden Fehlermeldungen:

HTTP/1.1 500 Internal Server Error

Darauf kann eine Fehlermeldung wie die folgende angezeigt werden:

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

OR

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

Mögliche Ursachen

Der interne Serverfehler 500 kann verschiedene Ursachen haben. Dieses Playbook konzentriert sich auf den internen Serverfehler 500, der durch den Zugriff auf die Anfrage/Antwort verursacht wurde. Nutzlast beim Streaming aktiviert ist.

Ursache	Beschreibung	Wer kann die Schritte zur Fehlerbehebung durchführen?
Zugriff auf Nutzlast mit Streaming aktiviert	Ein Fehler ist aufgetreten, da auf die Anfrage-/Antwortnutzlast zugegriffen wird, wenn Streaming aktiviert ist.	Private und öffentliche Edge-Cloud-Nutzer

Ursache: Zugriff auf Nutzlast mit aktiviertem Streaming

Diagnose

Verfahren Nr. 1: Trace verwenden

Trace aktivieren -Sitzung und führen Sie den API-Aufruf aus, um das Problem zu reproduzieren – „500 Internal Server Error“.
Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
Durchlaufen Sie die verschiedenen Phasen des Trace und finden Sie heraus, wo der Fehler aufgetreten ist.
Dieser Fehler kann aufgetreten sein, während eine Richtlinie die Anfrage-/Antwortnutzlast parst.
Hier ist ein Beispiel-Trace-Screenshot mit dem JSONThreatProtection- policy fehlgeschlagen und der Fehler "Expecting } at line 1" ausgegeben wird:

Notieren Sie sich die folgenden Informationen aus der Trace-Ausgabe (siehe oben). Screenshot:

Failing Policy : JSONThreatProtection

Ablauf:Proxy-Anfrage

Prüfen Sie die fehlerhafte Richtliniendefinition und die Nutzlast, die geparst wird.

Untersuchen Sie im Beispielszenario die JSONThreatProtection-Richtlinie namens Fehlgeschlagener JSON-Threat-Protection und prüft das Element <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>

Das Element <Source> verweist auf request.. Fehler beim Parsen der Anfragenutzlast.

Ermitteln Sie den Typ der Nutzlast, die geparst wird, indem Sie die API-Anfrage prüfen.

Sie können den Inhalt der Anfragenutzlast und des Content-Type-Headers in der API-Anfrage. Im folgenden curl-Beispielbefehl wird eine JSON-Nutzlast verwendet.

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

Sie können auch die fehlerhafte Richtlinie prüfen und den Typ der Nutzlast ermitteln, geparst. Im obigen Beispielszenario schlägt die JSON-Bedrohungsschutzrichtlinie fehl. Das gibt an, dass die Nutzlast im JSON-Format vorliegen muss.

Prüft, ob die Nutzlast das richtige Format hat. Wenn die Nutzlast ungültig ist, wird dieser Fehler ausgegeben.

Hinweis : Wenn die Nutzlast groß ist, können Sie die Daten mit einem beliebigen Onlineformatierer validieren. Format der Nutzlast.
Wenn die Nutzlast gültig ist, aber trotzdem Fehler angezeigt werden, die in der Fehlermeldungen, sehen Sie sich die Ursache für diese Fehler an. dass auf die Nutzlast zugegriffen wird, wenn Streaming aktiviert ist.

Abhängig von der Nutzlast, die von der Richtlinie geparst wird (wie in Schritt 6 festgelegt), Prüfen Sie den Nutzlastinhalt im Trace-Tool in der entsprechenden Phase.

Im Beispielszenario wird die Anfragenutzlast geparst. Untersuchen Sie daher die "Request Received from Client" im Trace und prüfen Sie den Inhalte anfordern:

Wenn das Feld „Request Content“ leer ist (siehe Screenshot oben), obwohl eine gültige Nutzlast gesendet wurde, bedeutet dies, dass die wahrscheinliche Ursache dieses Problems Anfragestreaming ist aktiviert.

Das liegt daran, dass die Anfragenutzlast bei aktiviertem Streaming nicht im Trace angezeigt wird.

Wenn die Nutzlast der Antwort beim Auftreten des Fehlers geparst wird, überprüfen Sie das Tag Antwortinhalt in der Phase "ResponseReceived from target server" (Antwort vom Zielserver erhalten)
Prüfen Sie als Nächstes die Proxy- und Zielendpunktdefinitionen, je nachdem, wo der fehlerhafte im API-Proxy-Ablauf verwendet wird. Prüfen Sie, ob Streaming aktiviert wurde.

Im Beispielszenario wurde die fehlerhafte Richtlinie im Ablauf der Proxyanfrage ausgeführt. (wie in Schritt 5 oben festgelegt); Prüfen Sie daher den Proxy-Endpunkt:
```
<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>
```
Wie im Beispiel oben zu sehen ist, wurde das Anfragestreaming aktiviert, Eigenschaft "request.streaming.enabled" auf "true" gesetzt.

Die Ursache des Fehlers ist daher die Verwendung der JSONThreatProtection-Richtlinie im API-Proxy die auf die Anfragenutzlast zugreift, wenn Streaming aktiviert ist. Dies führt zu Fehlern, löst die Zwischenspeicherung im API-Proxy aus und verwirft den Zweck der Verwendung von Streaming in Apigee Edge.

Bei kleineren Nutzlasten tritt dieser Fehler möglicherweise nicht auf. Wenn Sie jedoch größere Nutzlasten verwenden, diese Fehler sehen können.
Sie können überprüfen, ob der Fehler 500 durch die Richtlinie verursacht wird, indem Sie den Wert von "X-Apigee-fault-source" in "AX" (Analytics Data Recorded) Phase im Trace mit den folgenden Schritten: <ph type="x-smartling-placeholder">
1. Klicken Sie auf die Phase "AX" (aufgezeichnete Analytics-Daten). wie im folgenden Screenshot dargestellt:
2. Scrollen Sie in den Phasendetails nach unten zu "Error Headers" und bestimmen Sie die Werte von X-Apigee-Fehlercode. "X-Apigee-fault-source" und „X-Apigee-Flut-policy“ wie unten gezeigt:
3. Wenn der Wert von "X-Apigee-fault-source" "policy" ist wie gezeigt im Bild oben ist, bedeutet das, dass der Fehler durch eine Richtlinie verursacht wird, die auf den Nutzlast, wenn Streaming aktiviert ist.

Auflösung

Der Zugriff auf die Nutzlast bei aktiviertem Streaming ist ein Anti-Pattern, das im Abschnitt Antipattern: Auf die Anfrage-/Antwortnutzlast zugreifen, wenn Streaming aktiviert ist

Wenn Sie die Nutzlast verarbeiten möchten, müssen Sie Streaming im Proxy/Ziel deaktivieren. Endpunkt, indem Sie die Attribute "request.streaming.enabled" and "response.streaming.enabled" entfernen, wie im folgenden Beispiel für ProxyEndpoint gezeigt:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
ODER
Wenn Sie Streaming für Ihre API-Proxys verwenden möchten, verwenden Sie keine Richtlinien in der API-Proxy, der auf die Anfrage-/Antwortnutzlast zugreift.

Hinweis:

In diesem Playbook wurde die JSONThreatProtection-Richtlinie verwendet, um die Nutzlast der Anfrage mit Streaming im Beispielszenario aktiviert. Dies führte zu „500 Internal Server Error“ mit verschiedenen Fehlern.
Diese Fehler können auch bei Richtlinien wie JSONToXML und XMLToJSON auftreten, die Nutzlasten von Anfragen oder Antworten senden, wenn Streaming aktiviert ist.
Es wird dringend empfohlen, solche Richtlinien nicht in Proxys zu verwenden, die Zugriff auf Payloads, wenn Streaming aktiviert ist.
Dies ist ein Anti-Pattern, wie in den Antipattern: Auf die Anfrage-/Antwortnutzlast zugreifen, wenn Streaming aktiviert ist

Probleme mithilfe von API-Überwachung diagnostizieren

Wenn Sie ein Private Cloud-Nutzer sind, überspringen Sie diesen Vorgang.

Mit der API-Überwachung können Sie Problembereiche schnell isolieren, um Fehler-, Leistungs- und Latenzprobleme sowie deren Ursache zu diagnostizieren, z. B. Entwickler-Apps, API-Proxys, Back-End-Ziele oder die API-Plattform.

Schritt durch ein Beispielszenario, das zeigt, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API-Monitoring beheben. Beispielsweise können Sie festlegen, dass Sie benachrichtigt werden, wenn die Anzahl der 500 Fehler einen bestimmten Grenzwert überschreitet.

Wenn Sie benachrichtigt werden möchten, wenn eine 500-Fehlerantwort von der Richtlinie ausgelöst wird, müssen Sie die Benachrichtigung für den 500-Statuscode mit der Fehlerquelle als Proxy einrichten.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem trotz Befolgen der obigen Anweisungen weiterhin besteht, holen Sie die folgenden Diagnoseinformationen zusammen. Teilen Sie sie dem Apigee-Support mit.

Wenn Sie ein Nutzer der öffentlichen Cloud sind, geben Sie die folgenden Informationen an:

Name der Organisation
Name der Umgebung
API-Proxy-Name
Führen Sie den curl-Befehl zusammen mit der Nutzlast der Anfrage (falls vorhanden) aus, um den Fehler 500 zu reproduzieren.
Ablaufverfolgungsdatei mit den Anfragen mit dem Fehler 500 (Interner Serverfehler)
Wenn die 500-Fehler derzeit nicht auftreten, geben Sie den Zeitraum mit den Zeitzoneninformationen an, für den 500-Fehler in der Vergangenheit aufgetreten sind.

Wenn Sie ein Nutzer der Private Cloud sind, geben Sie die folgenden Informationen an:

Vollständige Fehlermeldung für fehlgeschlagene Anfragen
Organisation, Umgebungsname und API-Proxy-Name, bei denen Sie 500-Fehler beobachten
API-Proxy-Bundle
In der Anfrage verwendete Nutzlast (falls vorhanden)
Ablaufverfolgungsdatei mit den Anfragen mit dem Fehler 500 (Interner Serverfehler)
NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Der Zeitraum mit den Zeitzoneninformationen, in dem die 500-Fehler aufgetreten sind.