Diese Seite wurde von der Cloud Translation API übersetzt.

500 Interner Serverfehler – Streaming aktiviert

Sie sehen die Dokumentation zu Apigee Edge.
Zur Apigee X-Dokumentation weitere Informationen

Symptom

Die Clientanwendung empfängt den HTTP-Antwortstatuscode 500 mit der Meldung Interner Serverfehler für API-Aufrufe.

Fehlermeldungen

Die Client-Anwendungen erhalten möglicherweise eine Fehlerantwort, wie unten dargestellt:

HTTP/1.1 500 Internal Server Error

Im Anschluss kann eine Fehlermeldung wie diese 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-Nutzlast bei aktiviertem Streaming verursacht wird.

Ursache	Beschreibung	Wer kann die Schritte zur Fehlerbehebung ausführen?
Bei aktiviertem Streaming auf Nutzlast zugreifen	Ein Fehler ist aufgetreten, da bei aktiviertem Streaming auf die Nutzlast der Anfrage/Antwort zugegriffen wird.	Private Edge-Nutzer und Nutzer öffentlicher Clouds

Ursache: Zugriff auf Nutzlast bei aktiviertem Streaming

Diagnose

Verfahren 1: Trace verwenden

Aktivieren Sie die Trace-Sitzung und führen Sie den API-Aufruf aus, um das Problem zu reproduzieren (Interner Serverfehler 500).
Wählen Sie eine der fehlgeschlagenen Anfragen aus und prüfen Sie den Trace.
Gehen Sie die verschiedenen Phasen des Trace durch und ermitteln Sie, wo der Fehler aufgetreten ist.
Dieser Fehler ist möglicherweise aufgetreten, während eine Richtlinie die Nutzlast der Anfrage/Antwort parst.
Der folgende Trace-Beispiel-Screenshot zeigt, dass die JSONThreatProtection -RichtlinieJSONThreatProtection mit dem Fehler JSONThreatProtection fehlschlägt:

Notieren Sie sich die folgenden Informationen aus der Trace-Ausgabe, wie im Screenshot oben dargestellt:

Richtlinienverstoß : JSONThreatProtection

Ablauf:Proxyanfrage

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

Untersuchen Sie im Beispielszenario die fehlgeschlagene JSONThreatProtection-Richtlinie JSON-Threat-Protection und prüfen Sie 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.. Dies bedeutet, dass der Fehler beim Parsen der Nutzlast der Anfrage aufgetreten ist.

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

Sie können den Inhalt der Anfragenutzlast und den Content-Type-Header in der API-Anfrage prüfen. 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 Richtlinie prüfen, die fehlschlägt, und den Typ der zu analysierenden Nutzlast ermitteln. Im obigen Beispielszenario schlägt die JSON-Threat-Protection-Richtlinie fehl. Das bedeutet, dass die Nutzlast im JSON-Format vorliegen muss.

Prüfen Sie, ob die Nutzlast das richtige Format hat. Wenn die Nutzlast ungültig ist, kann dieser Fehler angezeigt werden.

Hinweis : Wenn die Nutzlast groß ist, können Sie ein beliebiges Onlineformatierungstool verwenden, um das Format der Nutzlast zu validieren.
Wenn die Nutzlast gültig ist, aber weiterhin Fehler auftreten, die im Abschnitt Fehlermeldungen aufgeführt sind, liegt die Ursache für diese Fehler darin, dass auf die Nutzlast zugegriffen wird, wenn das 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 Nutzlast der Anfrage geparst. Untersuchen Sie daher die Phase Vom Client empfangene Anfrage im Trace und prüfen Sie den Wert von Anfrageinhalt.

Wenn sich herausstellt, dass der Anfrageinhalt leer ist (siehe Screenshot oben), obwohl Sie eine gültige Nutzlast gesendet haben, deutet dies darauf hin, dass die wahrscheinliche Ursache dieses Problems darin besteht, dass das Anfragestreaming aktiviert ist.

Dies liegt daran, dass die Nutzlast der Anfrage bei aktiviertem Streaming nicht im Trace angezeigt wird.

Wenn die Antwortnutzlast beim Auftreten des Fehlers geparst wird, prüfen Sie den Antwortinhalt in der Phase Antwort vom Zielserver erhalten.
Untersuchen Sie als Nächstes die Definitionen von Proxys und Zielendpunkten, je nachdem, wo die ausgefallene Richtlinie im API-Proxy-Ablauf verwendet wird. Prüfen Sie, ob Streaming aktiviert ist.

Im Beispielszenario wurde die fehlerhafte Richtlinie im Ablauf der Proxyanfrage ausgeführt (wie in Schritt 5 oben ermittelt). Untersuchen Sie daher den Proxyendpunkt:
```
<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 obigen Beispiel gezeigt, wurde das Anfragestreaming aktiviert, wie durch das Attribut "request.streaming.enabled" angegeben, das auf „true“ gesetzt ist.

Die Ursache des Fehlers ist daher die Verwendung der JSONThreatProtection-Richtlinie im API-Proxy, die bei aktiviertem Streaming auf die Nutzlast der Anfrage zugreift. Dies verursacht Fehler, da dies die Pufferung im API-Proxy auslöst und den Zweck der Verwendung von Streaming in Apigee Edge missachtet.

Dieser Fehler tritt bei kleineren Nutzlasten möglicherweise nicht auf, aber wenn Sie größere Nutzlasten verwenden, werden sie möglicherweise angezeigt.
Sie können überprüfen, ob der 500-Fehler durch die Richtlinie verursacht wird. Dazu prüfen Sie den Wert "X-Apigee-fault-source" in der Phase "X-Apigee-fault-source" im Trace. Gehen Sie dazu so vor:
1. Klicken Sie auf "AX" (Aufgezeichnete Analytics-Daten) wie im folgenden Screenshot dargestellt:
2. Scrollen Sie in den Phasendetails nach unten zum Abschnitt Fehlerheader und bestimmen Sie die Werte für X-Apigee-Fehler-Code, X-Apigee-Fehler-Quelle und X-Apigee-Fehler-Richtlinie wie unten dargestellt:
3. Wenn der Wert von "X-Apigee-fault-source" wie im obigen Bild dargestellt "X-Apigee-fault-source" lautet, weist dies darauf hin, dass der Fehler durch die Richtlinie verursacht wird, die auf die Nutzlast zugreift, wenn das Streaming aktiviert ist.

Auflösung

Der Zugriff auf die Nutzlast bei aktiviertem Streaming ist ein Anti-Pattern, wie unter Anti-Muster: Zugriff auf die Anfrage-/Antwortnutzlast, wenn Streaming aktiviert ist erläutert.

Wenn Sie die Nutzlast verarbeiten möchten, müssen Sie das Streaming im Proxy-/Zielendpunkt deaktivieren. Entfernen Sie dazu die Attribute "request.streaming.enabled" and "response.streaming.enabled", wie im folgenden Beispiel für ProxyEndpoint:
```
<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, sollten Sie keine Richtlinien im API-Proxy verwenden, die auf die Nutzlast der Anfrage/Antwort zugreifen.

Hinweis:

In diesem Playbook wurde im Beispielszenario die JSONThreatProtection-Richtlinie verwendet, um die Anfragenutzlast mit aktiviertem Streaming zu verarbeiten. Dies führte zu einem internen Serverfehler mit verschiedenen Fehlern 500.
Diese Fehler treten auch bei Richtlinien wie JSONToXML und XMLToJSON auf, die bei aktiviertem Streaming Nutzlasten von Anfragen oder Antworten verarbeiten.
Wir empfehlen dringend, solche Richtlinien nicht in Proxys zu verwenden, die bei aktiviertem Streaming Zugriff auf Nutzlasten benötigen.
Dies ist ein Anti-Pattern, wie unter Anti-Pattern: Bei aktiviertem Streaming auf die Anfrage-/Antwortnutzlast zugreifen dokumentiert.

Probleme mithilfe der API-Überwachung diagnostizieren

Wenn Sie die private Cloud nutzen, überspringen Sie diesen Vorgang.

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

Arbeiten Sie ein Beispielszenario durch, in dem veranschaulicht wird, wie Sie 5xx-Probleme mit Ihren APIs mithilfe von API Monitoring beheben können. Sie können beispielsweise eine Benachrichtigung einrichten, damit Sie informiert 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 Warnung für den 500-Statuscode mit der Fehlerquelle als Proxy einrichten.

Diagnoseinformationen müssen erfasst werden

Wenn das Problem trotz Befolgen der obigen Anweisungen weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen. Wenden Sie sich an den Apigee-Support und leiten Sie sie weiter.

Wenn Sie die öffentliche Cloud nutzen, 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, in denen die 500-Fehler in der Vergangenheit aufgetreten sind.

Wenn Sie die private Cloud nutzen, geben Sie die folgenden Informationen an:

Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
Organisation, Umgebungsname und API-Proxy-Name, für die 500-Fehler auftreten
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-Protokolle (/opt/apigee/var/log/edge-message-processor/logs/system.log)
Der Zeitraum mit den Zeitzoneninformationen, in dem die 500-Fehler aufgetreten sind.