500 Interner Serverfehler

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

Videos

Sehen Sie sich die folgenden Videos an, um mehr über das Beheben von 500-internen Serverfehlern zu erfahren.

Video Beschreibung
Einführung Bietet eine Einführung zu 500 internen Serverfehlern und möglichen Ursachen. Zeigt außerdem einen Echtzeitfehler vom Typ 500 (Interner Serverfehler) zusammen mit Schritten zur Fehlerbehebung.
Fehler vom Typ „Service Callout“ und „Variable extrahieren“ beheben Veranschaulicht zwei interne Serverfehler vom Typ „500“, die durch „Service Callout“- und „Variable extrahieren“-Richtlinien verursacht werden, und zeigt, wie diese Fehler behoben und behoben werden können.
JavaScript-Richtlinienfehler beheben Zeigt einen internen Serverfehler des Typs 500, der durch eine JavaScript-Richtlinie verursacht wird, sowie die Schritte zur Fehlerbehebung.
Fehler auf Back-End-Servern beheben Zeigt Beispiele für interne Serverfehler 500, die durch einen Back-End-Serverfehler verursacht wurden, sowie Schritte zur Fehlerbehebung.

Symptom

Die Clientanwendung erhält als Antwort auf API-Aufrufe den HTTP-Statuscode 500 mit der Meldung "Internal Server Error". Der Fehler 500 Internal Server könnte durch einen Fehler während der Ausführung einer Richtlinie in Edge oder durch einen Fehler auf dem Ziel-/Back-End-Server verursacht werden.

Der HTTP-Statuscode 500 ist eine allgemeine Fehlerantwort. Der Server ist auf eine unerwartete Bedingung gestoßen, die die Verarbeitung der Anfrage verhindert hat. Dieser Fehler wird normalerweise vom Server zurückgegeben, wenn kein anderer Fehlercode geeignet ist.

Fehlermeldungen

Sie erhalten möglicherweise die folgende Fehlermeldung:

HTTP/1.1 500 Internal Server Error

In einigen Fällen wird möglicherweise eine weitere Fehlermeldung mit weiteren Details angezeigt. Hier ein Beispiel für eine Fehlermeldung:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Mögliche Ursachen

Der Fehler 500 (Interner Serverfehler) kann verschiedene Ursachen haben. In Edge können die Ursachen in zwei Hauptkategorien unterteilt werden, je nachdem, wo der Fehler aufgetreten ist:

Ursache Details Sie finden detaillierte Schritte zur Fehlerbehebung.
Ausführungsfehler in einer Edge-Richtlinie Eine Policy innerhalb des API-Proxys kann aus irgendeinem Grund fehlschlagen. Nutzer von Edge Private und Public Cloud
Fehler im Back-End-Server Der Back-End-Server kann aus irgendeinem Grund ausfallen. Nutzer von Edge Private und Public Cloud

Ausführungsfehler in einer Edge-Richtlinie

Eine Policy innerhalb des API-Proxys kann aus irgendeinem Grund fehlschlagen. In diesem Abschnitt wird erläutert, wie Sie das Problem beheben können, wenn der interne Serverfehler 500 während der Ausführung einer Richtlinie auftritt.

Diagnose

Diagnoseschritte für Nutzer in privaten und öffentlichen Clouds

Wenn Sie die Trace-UI-Sitzung für den Fehler haben, gehen Sie so vor:

  1. Prüfen Sie, ob der Fehler durch die Ausführung einer Richtlinie verursacht wurde. Weitere Informationen finden Sie unter Ursache des Problems ermitteln.
  2. Wenn der Fehler während der Ausführung der Richtlinie aufgetreten ist, fahren Sie fort. Wenn der Fehler durch den Back-End-Server verursacht wurde, lesen Sie den Abschnitt Fehler auf dem Back-End-Server.
  3. Wählen Sie die API-Anfrage aus, bei der im Trace die Fehler „500 Interner Serverfehler“ angezeigt wird.
  4. Prüfen Sie die Anfrage und wählen Sie die jeweilige fehlgeschlagene Richtlinie oder den Ablauf mit dem Namen „Error“ aus, der sofort auf die fehlgeschlagene Richtlinie im Trace folgt.
  5. Weitere Details zum Fehler finden Sie entweder im Feld „Fehler“ im Bereich „Eigenschaften“ oder im Fehlerinhalt.
  6. Versuchen Sie anhand der Informationen, die Sie zu dem Fehler gesammelt haben, die Ursache zu ermitteln.

Diagnoseschritte nur für Private Cloud-Nutzer

Wenn Sie keine Trace-UI-Sitzung haben, gehen Sie so vor:

  1. Prüfen Sie, ob der Fehler beim Ausführen einer Richtlinie aufgetreten ist. Weitere Informationen finden Sie unter Ursache des Problems ermitteln.
  2. Wenn der Fehler durch die Ausführung der Richtlinie verursacht wurde, fahren Sie fort. Wenn der Fehler beim Ausführen der Richtlinie aufgetreten ist, fahren Sie fort. Wenn der Fehler durch den Back-End-Server verursacht wurde, lesen Sie den Abschnitt Fehler auf dem Back-End-Server.
  3. Verwenden Sie die NGINX-Zugriffslogs, wie unter Ursache des Problems ermitteln erläutert, um die fehlerhafte Richtlinie im API-Proxy sowie die eindeutige Anfragenachrichten-ID zu ermitteln.
  4. Prüfen Sie die Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) und suchen Sie darin nach der eindeutigen Anfragenachrichten-ID.
  5. Wenn Sie die eindeutige ID der Anfragenachricht finden, versuchen Sie, weitere Informationen zur Fehlerursache zu erhalten.

Auflösung

Wenn Sie die Ursache des Problems mit der Richtlinie ermittelt haben, versuchen Sie, das Problem zu beheben, indem Sie die Richtlinie korrigieren und den Proxy noch einmal bereitstellen.

Die folgenden Beispiele veranschaulichen, wie Sie die Ursache und Lösung für verschiedene Arten von Problemen ermitteln können.

Wenn Sie weitere Unterstützung bei der Fehlerbehebung des internen Serverfehlers 500 benötigen oder vermuten, dass es sich um ein Problem in Edge handelt, wenden Sie sich an den Apigee-Support.

Beispiel 1: Fehler in der Service-Callout-Richtlinie aufgrund eines Fehlers auf dem Back-End-Server

Wenn der Aufruf an den Back-End-Server innerhalb der Service-Callout-Richtlinie mit einem Fehler wie 4XX oder 5XX fehlschlägt, wird der Aufruf als 500 Internal Server Error behandelt.

  1. In diesem Beispiel schlägt der Back-End-Dienst mit einem 404-Fehler innerhalb der Service-Callout-Richtlinie fehl. Die folgende Fehlermeldung wird an den Endnutzer gesendet: 
    {
"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. Die folgende Trace-UI-Sitzung zeigt den Statuscode 500, der aufgrund eines Fehlers in der Service-Callout-Richtlinie verursacht wurde:

  3. In diesem Beispiel wird mit der Property "error" der Grund für den Fehler in Bezug auf die Service-Callout-Richtlinie als "ResponseCode 404 is handle as error" aufgelistet. Dieser Fehler kann auftreten, wenn die Ressource, auf die über die Back-End-Server-URL in der Service-Callout-Richtlinie zugegriffen wird, nicht verfügbar ist.
  4. Prüfen Sie die Verfügbarkeit der Ressource auf dem Back-End-Server. Möglicherweise ist sie vorübergehend/dauerhaft nicht verfügbar oder wurde an einen anderen Standort verlegt.

Lösungsbeispiel 1

  1. Prüfen Sie die Verfügbarkeit der Ressource auf dem Back-End-Server. Möglicherweise ist sie vorübergehend/dauerhaft nicht verfügbar oder wurde an einen anderen Standort verlegt.
  2. Korrigieren Sie die Back-End-Server-URL in der Service-Callout-Richtlinie, sodass sie auf eine gültige und vorhandene Ressource verweist.
  3. Wenn die Ressource nur vorübergehend nicht verfügbar ist, stellen Sie die API-Anfrage, sobald die Ressource verfügbar ist.

Beispiel 2: Fehler in der Richtlinie zum Extrahieren von Variablen

Sehen wir uns nun ein weiteres Beispiel an, bei dem der interne Serverfehler 500 aufgrund eines Fehlers in der Richtlinie zum Extrahieren von Variablen verursacht wird. Wir zeigen Ihnen, wie Sie das Problem beheben können.

  1. Der folgende Trace in der UI-Sitzung zeigt den Statuscode 500 aufgrund eines Fehlers in der Richtlinie zum Extrahieren von Variablen:

  2. Wählen Sie die fehlerhafte Richtlinie zum Extrahieren von Variablen aus, scrollen Sie nach unten und sehen Sie sich den Abschnitt Fehlerinhalt an, um weitere Informationen zu erhalten:

  3. Der Fehlerinhalt gibt an, dass die Variable "serviceCallout.oamCookieValidationResponse" in der Richtlinie zum Extrahieren von Variablen nicht verfügbar ist. Wie der Name der Variable angibt, sollte sie die Antwort der vorhergehenden Service-Callout-Richtlinie enthalten.
  4. Wählen Sie die Service-Callout-Richtlinie im Trace aus. Möglicherweise stellen Sie fest, dass die Variable "serviceCallout.oamCookieValidationResponse" nicht festgelegt wurde. Dies weist darauf hin, dass der Aufruf an den Back-End-Dienst fehlgeschlagen ist, was zu einer leeren Antwortvariablen führt.
  5. Obwohl die Service-Callout-Richtlinie fehlgeschlagen ist, wird die Ausführung der Richtlinien nach der Service-Callout-Richtlinie fortgesetzt, da das Flag „continueOnError“ in der Service-Callout-Richtlinie auf „true“ gesetzt ist (siehe unten):

    <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. Notieren Sie die eindeutige Nachrichten-ID "X-Apigee.Message-ID" für diese spezifische API-Anfrage aus dem Trace:
    1. Wählen Sie in der Anfrage die Phase „Aufgezeichnete Analytics-Daten“ aus.
    2. Scrollen Sie nach unten und notieren Sie sich den Wert von X-Apigee.Message-ID.

  7. Rufen Sie das Message Processor-Log (/opt/apigee/var/log/edge-message-processor/system.log) auf und suchen Sie nach der eindeutigen Nachrichten-ID, die Sie sich in Schritt 6 notiert haben. Für die spezifische API-Anfrage wurde die folgende Fehlermeldung angezeigt: 
    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

    Der obige Fehler gibt an, dass die Service-Callout-Richtlinie aufgrund eines Verbindungszeitüberschreitungsfehlers beim Herstellen einer Verbindung zum Back-End-Server fehlgeschlagen ist.

  8. Um die Ursache für den Verbindungszeitüberschreitungsfehler zu ermitteln, führten Sie den Befehl telnet von den Message Processorn an den Back-End-Server aus. Der Telnet-Befehl gab die Fehlermeldung „Zeitüberschreitung bei der Verbindung“ aus (siehe unten): 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    Dieser Fehler tritt normalerweise unter den folgenden Umständen auf:

    • Wenn der Back-End-Server nicht so konfiguriert ist, dass er Traffic von den Edge-Nachrichtenprozessoren zulässt.
    • Wenn der Back-End-Server den bestimmten Port nicht überwacht.

    Obwohl die Richtlinie zum Extrahieren von Variablen im obigen Beispiel fehlgeschlagen ist, war die tatsächliche Ursache, dass Edge keine Verbindung zum Back-End-Server in der Service Callout-Richtlinie herstellen konnte. Die Ursache für diesen Fehler war, dass der Back-End-Endserver nicht so konfiguriert war, dass er Traffic von den Edge Message Processorn zulässt.

    Ihre eigene Richtlinie zum Extrahieren von Variablen verhält sich anders und kann aus einem anderen Grund fehlschlagen. Sie können das Problem je nach Ursache für das Fehlschlagen Ihrer Richtlinie zum Extrahieren von Variablen entsprechend beheben. Prüfen Sie dazu die Meldung im Attribut error.

Lösungsbeispiel 2

  1. Beheben Sie die Fehlerursache in der Richtlinie „Variablen extrahieren“ entsprechend.
  2. Im oben dargestellten Beispiel bestand die Lösung darin, die Netzwerkkonfiguration zu korrigieren, um den Traffic von Edge-Nachrichtenprozessoren zu Ihrem Back-End-Server zuzulassen. Dazu wurden die IP-Adressen der Message Processor auf dem jeweiligen Back-End-Server auf die Zulassungsliste gesetzt. Unter Linux könnten Sie beispielsweise iptables verwenden, um den Traffic von den IP-Adressen von Message Processor auf dem Back-End-Server zuzulassen.

Beispiel 3: Fehler in der JavaCallout-Richtlinie

Sehen wir uns nun ein weiteres Beispiel an, bei dem der interne Serverfehler 500 aufgrund eines Fehlers in der Java-Callout-Richtlinie verursacht wird, und sehen wir uns an, wie Sie das Problem beheben können.

  1. Das folgende UI-Trace zeigt den Statuscode 500 aufgrund eines Fehlers in der Java-Callout-Richtlinie:

  2. Wählen Sie den Ablauf mit dem Namen "Error" aus, gefolgt von der fehlgeschlagenen Java-Callout-Richtlinie, um die Fehlerdetails zu erhalten, wie in der folgenden Abbildung dargestellt:

  3. In diesem Beispiel zeigt die Eigenschaft "error" im Abschnitt Eigenschaften an, dass der Fehler auf ein abgelaufenes Passwort zurückzuführen ist, das während der Verbindung zur Oracle-Datenbank innerhalb der JavaCallout-Richtlinie verwendet wurde. Ihr eigenes Java-Callout verhält sich anders und es wird eine andere Meldung in der Eigenschaft error angezeigt.
  4. Prüfen Sie den JavaCallout-Richtliniencode und bestätigen Sie die korrekte Konfiguration, die verwendet werden muss.

Lösungsbeispiel 3

Korrigieren Sie den Java-Callout-Code oder die Java-Konfiguration entsprechend, um die Laufzeitausnahme zu vermeiden. Im dargestellten Beispiel für einen Fehler bei Java-Callouts oben müsste zur Behebung des Problems das richtige Passwort für die Verbindung zur Oracle-Datenbank verwendet werden.

Fehler im Back-End-Server

Ein 500-Interner Serverfehler kann auch vom Back-End-Server stammen. In diesem Abschnitt wird erläutert, wie Sie das Problem beheben können, wenn der Fehler vom Back-End-Server kommt.

Diagnose

Diagnoseschritte für alle Nutzer

Die Ursachen anderer Back-End-Fehler können stark variieren. Sie müssen jede Situation einzeln diagnostizieren.

  1. Überprüfen Sie, ob der Fehler durch den Back-End-Server verursacht wurde. Weitere Informationen finden Sie unter Ursache des Problems ermitteln.
  2. Wenn der Fehler durch den Back-End-Server verursacht wurde, fahren Sie fort. Wenn der Fehler während der Richtlinienausführung aufgetreten ist, gehen Sie zu Ausführungsfehler in Edge-Richtlinie.
  3. Führen Sie die folgenden Schritte aus, je nachdem, ob Sie Zugriff auf eine Trace-Sitzung für die fehlgeschlagene API haben oder ob das Back-End ein Node.js-Server ist:

Wenn Sie keine Trace-Sitzung für den fehlgeschlagenen API-Aufruf haben:

  1. Wenn das UI-Trace für die fehlgeschlagene Anfrage nicht verfügbar ist, prüfen Sie die Back-End-Serverlogs, um Details zum Fehler zu erhalten.
  2. Aktivieren Sie nach Möglichkeit den Fehlerbehebungsmodus auf dem Back-End-Server, um weitere Details zum Fehler und zur Ursache zu erhalten.

Wenn für den fehlgeschlagenen API-Aufruf eine Trace-Sitzung vorhanden ist:

Wenn Sie eine Trace-Sitzung haben, helfen Ihnen die folgenden Schritte bei der Diagnose des Problems.

  1. Wählen Sie im Trace-Tool die API-Anfrage aus, die mit dem Fehler 500 interner Serverfehler fehlgeschlagen ist.
  2. Wählen Sie die Phase Antwort vom Zielserver erhalten aus der fehlgeschlagenen API-Anfrage aus, wie in der folgenden Abbildung dargestellt:

  3. Details zum Fehler finden Sie im Abschnitt Antwortinhalt.

  4. In diesem Beispiel zeigt der Antwortinhalt, bei dem es sich um einen SOAP-Envelope handelt, den Fehlerstring als Meldung "Nicht autorisiert" an. Die wahrscheinlichste Ursache für dieses Problem ist, dass die richtigen Anmeldedaten (Nutzername/Passwort, Zugriffstoken usw.) nicht vom Nutzer an den Back-End-Server weitergegeben werden. Dieses Problem kann behoben werden, indem Sie die richtigen Anmeldedaten an den Back-End-Server übergeben.

Wenn das Back-End ein Node.js-Server ist:

  1. Wenn das Back-End ein Node.js-Back-End-Server ist, prüfen Sie die Node.js-Logs für den jeweiligen API-Proxy in der Edge-Benutzeroberfläche (Nutzer von öffentlichen und privaten Clouds können die Node.js-Logs prüfen). Wenn Sie ein Edge Private Cloud-Nutzer sind, können Sie auch in den Message Processor-Logs (/opt/apigee/var/log/edge-message-processor/logs/system.log) weitere Details zum Fehler prüfen.

    Option „NodeJS-Logs“ in der Edge-Benutzeroberfläche – Tab „Übersicht“ des API-Proxys

Lösung

  1. Sobald Sie die Ursache des Fehlers gefunden haben, beheben Sie das Problem auf Ihrem Back-End-Server.
  2. Wenn es sich um einen Node.js-Back-End-Server handelt:
    1. Überprüfen Sie, ob der Fehler von Ihrem benutzerdefinierten Code ausgegeben wird, und beheben Sie das Problem, falls möglich.
    2. Wenn der Fehler nicht von Ihrem benutzerdefinierten Code zurückgegeben wird oder Sie Hilfe benötigen, wenden Sie sich an den Apigee-Support.

Wenn Sie weitere Unterstützung bei der Fehlerbehebung des internen Serverfehlers 500 benötigen oder vermuten, dass es sich um ein Problem in Edge handelt, wenden Sie sich an den Apigee-Support.

Ursache des Problems ermitteln

Mit einem der folgenden Verfahren können Sie feststellen, ob der interne Serverfehler 500 während der Ausführung einer Richtlinie im API-Proxy oder durch den Back-End-Server ausgegeben wurde.

Trace in der UI verwenden

Hinweis: Die Schritte in diesem Abschnitt können sowohl von Nutzern der öffentlichen als auch von der privaten Cloud ausgeführt werden.

  1. Wenn das Problem weiterhin besteht, aktivieren Sie das Trace in der Benutzeroberfläche für die betroffene API.
  2. Sobald Sie den Trace erfasst haben, wählen Sie die API-Anfrage aus, die den Antwortcode als 500 anzeigt.
  3. Sehen Sie sich alle Phasen der fehlgeschlagenen API-Anfrage an und prüfen Sie, in welcher Phase der Fehler 500 (Interner Serverfehler) zurückgegeben wird:
    1. Wenn der Fehler während der Ausführung einer Richtlinie ausgegeben wird, fahren Sie mit Ausführungsfehler in einer Edge-Richtlinie fort.
    2. Wenn der Back-End-Server mit 500 für den internen Server geantwortet hat, fahren Sie mit Fehler auf dem Back-End-Server fort.

API-Monitoring verwenden

Hinweis:Die Schritte in diesem Abschnitt können nur von Nutzern öffentlicher Clouds ausgeführt werden.

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 Statuscodes oder steps.servicecallout.ExecutionFailed Fehler einen bestimmten Grenzwert überschreitet.

NGINX-Zugriffslogs verwenden

Hinweis: Die Schritte in diesem Abschnitt gelten nur für Edge Private Cloud-Nutzer.

Sie können auch auf die NGINX-Zugriffslogs zurückgreifen, um festzustellen, ob der Statuscode 500 während der Ausführung einer Richtlinie im API-Proxy oder vom Back-End-Server ausgegeben wurde. Dies ist besonders nützlich, wenn das Problem in der Vergangenheit aufgetreten ist oder nur zeitweise auftritt und Sie den Trace in der UI nicht erfassen können. Führen Sie die folgenden Schritte aus, um diese Informationen aus den NGINX-Zugriffslogs zu ermitteln:

  1. Prüfen Sie die NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. Suchen Sie nach 500-Fehlern für den spezifischen API-Proxy an der angegebenen Dauer.
  3. Wenn 500-Fehler vorliegen, prüfen Sie, ob es sich um einen Richtlinien- oder Zielserverfehler handelt, wie unten dargestellt:

    Beispieleintrag mit einem Richtlinienfehler

    Beispieleintrag mit einem Zielserverfehler

  4. Sobald Sie festgestellt haben, ob es sich um einen Richtlinien- oder Zielserverfehler handelt, gehen Sie so vor:
    1. Fahren Sie mit Ausführungsfehler in einer Edge-Richtlinie fort, wenn es sich um einen Richtlinienfehler handelt.
    2. Fahren Sie mit Fehler im Back-End-Server fort, wenn es sich um einen Zielserverfehler handelt.