Diese Seite wurde von der Cloud Translation API übersetzt.

504 Gateway-Zeitüberschreitung – Zeitüberschreitung des Routers

<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-Statuscode 504 mit der Nachricht Gateway Timeout als Antwort auf API-Aufrufe.

Diese Fehlerantwort zeigt an, dass der Client keine rechtzeitige Antwort von Apigee Edge erhalten hat. Back-End-Server während der Ausführung eines API-Aufrufs.

Fehlermeldung

Die Clientanwendung ruft den folgenden Antwortcode ab:

HTTP/1.1 504 Gateway Time-out

Wenn Sie einen solchen Proxy mit cURL oder einem Webbrowser aufrufen, wird möglicherweise der folgende Fehler angezeigt:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Was führt zu Zeitüberschreitungen?

Der typische Pfad für eine API-Anfrage über die Edge-Plattform lautet Client > Router > Nachricht Prozessor > Back-End-Server, wie in der folgenden Abbildung dargestellt:

Alle Komponenten im Apigee Edge-Laufzeitablauf, einschließlich Clients, Router, Nachricht Prozessoren und Backend-Server sind mit geeigneten Standardwerten für die Zeitüberschreitung eingerichtet, um sicherzustellen, dass die API-Anfragen nicht zu lange dauern. Wenn eine der Komponenten im die Antwort von der vorgelagerten Komponente nicht innerhalb des im Zeitüberschreitungskonfiguration aktiviert, tritt für die jeweilige Komponente eine Zeitüberschreitung auf und gibt in der Regel eine 504 Gateway TimeoutFehler.

In diesem Playbook wird beschrieben, wie Sie einen 504-Fehler beheben, der verursacht wird, wenn das Zeitlimit des Routers überschritten wird.

Zeitüberschreitung auf dem Router

Das standardmäßige Zeitlimit, das auf Routern in Apigee Edge konfiguriert ist, beträgt 57 Sekunden. Dies ist das Maximum Zeit, die ein API-Proxy von dem Zeitpunkt, an dem die API-Anfrage in Edge empfangen wird, bis zum wird die Antwort einschließlich der Back-End-Antwort und aller ausgeführten Richtlinien zurückgesendet. Das Standardzeitlimit kann auf den Routern/virtuellen Hosts überschrieben werden, wie unter <ph type="x-smartling-placeholder"></ph> E/A-Zeitlimit auf Routern konfigurieren

Mögliche Ursachen

In Edge sind die typischen Ursachen für den Fehler 504 Gateway Timeout aufgrund des Fehlers Eine Zeitüberschreitung beim Router ist:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Falsche Zeitlimitkonfiguration auf dem Router	Dies geschieht, wenn der Router mit einer falschen E/A-Zeitüberschreitung konfiguriert ist.	Edge-Nutzer von öffentlichen und privaten Clouds

Allgemeine Diagnoseschritte

Verwenden Sie eines der folgenden Tools oder Techniken, um diesen Fehler zu diagnostizieren:

API-Monitoring
NGINX-Zugriffslogs

API-Monitoring

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

Wechseln Sie zum Bereich Analysieren > API-Monitoring > Untersuchen.
Filtern Sie nach 5xx Fehlern und wählen Sie den Zeitraum aus.
Stell den Statuscode in den Vergleich mit Time ein.
Klicken Sie auf die Zelle mit 504 Fehlern, um weitere Details zu sehen und die Zelle anzusehen. Protokolle über diese Fehler enthalten:

Beispiel für 504-Fehler
Klicken Sie im rechten Bereich auf Logs ansehen.

Beachten Sie im Fenster Traffic-Logs zu einigen 504-Fehlern die folgenden Details:
- Anfrage: Stellt die Anfragemethode und den URI für die Aufrufe bereit.
- Response Time (Antwortzeit): Zeigt die insgesamt verstrichene Zeit für die Anfrage an.
Im obigen Beispiel
- Anfrage verweist auf GET /test-timeout.
- Die Reaktionszeit beträgt 57.001 Sekunden. Das bedeutet, dass der Router eine Zeitüberschreitung aufgetreten ist, bevor der Message Processor antworten konnte, da der Wert sehr nahe liegt auf das standardmäßige E/A-Zeitlimit des Routers von 57 Sekunden.
Sie können alle Logs auch mithilfe der API-Überwachung abrufen. GET-Logs Durch Abfragen von Logs für org, env, timeRange, und status könnten Sie alle Logs für Transaktionen herunterladen, Zeitüberschreitung beim Client.

Da API-Überwachung den Proxy für diese 504 auf - (nicht festgelegt) festlegt können Sie mithilfe der API (Protokolle API), um den zugehörigen Proxy für den virtuellen Host und den virtuellen Pfad abzurufen.

For example :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
<ph type="x-smartling-placeholder">
</ph> Hinweis:In den folgenden Feldern wird der Wert für diesen 504-Fehler angezeigt:
- Fehlerquelle
- Fehlercode
- Fehlerfluss
- Fehlerrichtlinie
- Fehler-Proxy
Diese Felder werden vom Message Processor ausgefüllt und mit entsprechenden Werten festgelegt wenn der Router eine Antwort vom Message Processor erhält. In diesem Fall hat der Router Zeitüberschreitung vor dem Message Processor, da er nicht rechtzeitig geantwortet hat. Dadurch wird der Router gezwungen, den Statuscode auf 504 zu setzen. oben erwähnten Felder werden als - angezeigt.
Prüfen Sie die Reaktionszeit auf zusätzliche 504-Fehler und prüfen Sie, um zu prüfen, ob die Response Time konsistent ist (Wert für das E/A-Zeitlimit am Router festgelegt). (57 Sekunden) bei allen 504-Fehlern.

NGINX-Zugriffslogs

So diagnostizieren Sie den Fehler mithilfe von NGINX-Zugriffslogs:

Prüfen Sie die NGINX-Zugriffslogs:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Suchen, um zu sehen, ob es während eines bestimmten Zeitraums 504 Fehler gibt (wenn das Problem in der Vergangenheit aufgetreten ist) oder wenn immer noch Anfragen mit 504
Beachten Sie die folgenden Informationen zu einigen 504-Fehlern: <ph type="x-smartling-placeholder">
- Reaktionszeit
- Anfrage-URI
In diesem Beispiel sehen wir die folgenden Informationen:
- Anfragezeit: 57.001 Sekunden. Dies bedeutet, dass der Zeitüberschreitung beim Router nach 57.001 Sekunden.
  <ph type="x-smartling-placeholder">
  </ph> Hinweis: Dies stellt das Feld request_time in NGINX-Logs dar. Es bezeichnet die Verarbeitungszeit der Anfrage in Sekunden. Zeit zwischen dem ersten Bytes wurden vom Client gelesen und der Logschreibvorgang wurde nach dem Senden der letzten Bytes durchgeführt. an die Kundschaft.
- Anfrage: GET /test-timeout
- Host Alias (Host-Alias): myorg-test.apigee.net
Hinweis: In den folgenden Feldern wird der Wert - für diese 504 angezeigt. Fehler:
- Fehlerquelle
- Fehlercode
- Fehlerfluss
- Fehlerrichtlinie
- Fehler-Proxy
Diese Felder werden vom Message Processor ausgefüllt und nur mit geeigneten Werten festgelegt Der Router erhält eine Antwort vom Message Processor. In diesem Fall hat der Router an das Message Processor weitergeleitet zu werden, da es nicht rechtzeitig geantwortet hat. Dadurch wird den Router, um den Statuscode auf 504 zu setzen. werden als - angezeigt.
Prüfen Sie, ob die Anfragezeit mit dem E/A-Zeitlimit übereinstimmt. die auf dem Router bzw. virtuellen Host konfiguriert sind. Wenn ja, bedeutet dies, dass für den Router eine Zeitüberschreitung aufgetreten ist, bevor Der Message Processor hat innerhalb dieses Zeitraums nicht geantwortet.

Im oben gezeigten Beispieleintrag eines NGINX-Zugriffsprotokolls wird die Anfrage Die Zeit von 57.001 Sekunden liegt sehr nahe an dem festgelegten standardmäßigen E/A-Zeitlimit. auf dem Router. Dies weist eindeutig darauf hin, dass beim Router vor der Nachricht eine Zeitüberschreitung aufgetreten ist. Der Auftragsverarbeiter könnte antworten.
Ermitteln Sie den API-Proxy, für den die Anfrage gestellt wurde. Verwenden Sie dazu den Basispfad in der Anfrage .

Ursache: Falsche Konfiguration des Zeitlimits auf dem Router

Diagnose

Ermitteln Sie, ob die 504-Fehler aufgrund einer Zeitüberschreitung des Routers verursacht werden könnte der Message Processor antworten. Hierzu können Sie prüfen, Response Time (Reaktionszeit) in der API-Überwachung/Request Time (Anfragezeit) im Router (beide Felder) die dieselben Informationen darstellen,aber unter unterschiedlichen Namen aufgerufen werden) entspricht dem Das auf dem Router bzw. virtuellen Host konfigurierte E/A-Zeitlimit und die Felder Fehlerquelle und Fehler Proxy und Fehlercode sind mithilfe von API-Überwachung oder NGINX-Zugriff auf - gesetzt. wie unter Allgemeine Diagnoseschritte erläutert.
Prüfen Sie, ob das E/A-Zeitlimit auf dem Router oder dem spezifischen virtuellen Host niedriger als die, die im Message Processor oder im jeweiligen API-Proxy konfiguriert wurde.

Führen Sie dazu die Schritte in diesem Abschnitt aus.

E/A-Zeitlimit auf virtuellen Hosts prüfen

Edge-Benutzeroberfläche

Führen Sie die folgenden Schritte aus, um das Zeitlimit des virtuellen Hosts mithilfe der Edge-Benutzeroberfläche zu überprüfen:

Melden Sie sich bei der Edge-Benutzeroberfläche an.
Klicken Sie auf Verwaltung > Virtuelle Hosts
Wählen Sie eine bestimmte Umgebung aus, in der das Zeitüberschreitungsproblem auftritt.
Wählen Sie den spezifischen virtuellen Host aus, für den Sie das E/A-Zeitlimit prüfen möchten.
Unter Eigenschaften sehen Sie den Wert für die Proxy-Lesezeitüberschreitung in Sekunden.

Im obigen Beispiel ist für Proxy-Lesezeitlimit der folgende Wert konfiguriert: 120 Das bedeutet, dass das auf diesem virtuellen Host konfigurierte E/A-Zeitlimit 120 Sekunden beträgt.

Hinweis: Wenn für Proxy Read Timeout kein Wert angegeben ist, erfolgt die Standardwert von 57 Sekunden , der auf dem Router konfiguriert wird (es sei denn, das E/A-Zeitlimit ist auf den Routerinstanzen überschrieben werden.

Verwaltungs-APIs

Sie können die Proxy-Lesezeitüberschreitung auch mithilfe der folgenden Verwaltungs-APIs überprüfen:

Führen Sie den <ph type="x-smartling-placeholder"></ph> Rufen Sie die API für den virtuellen Host ab, um die virtualhost-Konfiguration wie unten gezeigt zu erhalten:

Public Cloud-Nutzer
```
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
Private Cloud-Nutzer
```
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
Wobei:

ORGANIZATION_NAME ist der Name der Organisation.

ENVIRONMENT_NAME ist der Name der Umgebung.

VIRTUALHOST_NAME ist der Name des virtuellen Hosts.

Prüfe den für das Attribut proxy_read_timeout konfigurierten Wert

Beispiel für Definition eines virtuellen Hosts

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

Im obigen Beispiel ist proxy_read_timeout mit folgendem Wert konfiguriert: 120. Das bedeutet, dass das auf diesem virtuellen Host konfigurierte E/A-Zeitlimit 120 beträgt Sekunden.

Hinweis: Wenn die Property proxy_read_timeout in der Ausgabe der Verwaltung nicht vorhanden ist verwendet sie die Standard-API, von 57 Sekunden fest, es sei denn, das E/A-Zeitlimit wird auf den Routerinstanzen überschrieben.

E/A-Zeitlimit in der Datei "router.properties" prüfen

Melden Sie sich auf einem Routercomputer an.
Suchen Sie nach der Property proxy_read_timeout in der /opt/nginx/conf.d und prüfen Sie, ob es mit dem neuen Wert festgelegt wurde wie folgt:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Prüfen Sie den Wert, der für das Attribut proxy_read_timeout in der spezifischen virtuellen Host-Konfigurationsdatei.

Beispielergebnis des Befehls „grep“
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
Beachten Sie in der obigen Beispielausgabe, dass das Attribut proxy_read_timeout auf den neuen Wert 57 in 0-default.conf gesetzt, Konfigurationsdatei für den virtuellen Standardhost. Das bedeutet, dass das E/A-Zeitlimit auf dem Router für den virtuellen default-Host auf 57 Sekunden konfiguriert. Wenn Sie virtueller Hosts nutzen, werden diese Informationen für jeden einzelnen angezeigt. Holen Sie sich den Wert von proxy_read_timeout für den spezifischen virtuellen Host, den Sie zum Erstellen der API verwendet haben Aufrufe, die mit 504-Fehlern fehlgeschlagen sind.

E/A-Zeitlimit im API-Proxy prüfen

So können Sie sich das E/A-Zeitlimit ansehen:

Zielendpunkt des API-Proxys
ServiceCallout-Richtlinie des API-Proxys

E/A-Zeitüberschreitung im Zielendpunkt des API-Proxys ansehen

Wählen Sie in der Edge-Benutzeroberfläche den spezifischen API-Proxy aus, in dem Sie die E/A anzeigen möchten. Zeitüberschreitungswert.
Wählen Sie den spezifischen Zielendpunkt aus, den Sie prüfen möchten.
Sehen Sie sich die Eigenschaft io.timeout.millis mit einem entsprechenden Wert unter dem <HTTPTargetConnection>-Element in TargetEndpoint Konfiguration.
Beispielsweise ist das E/A-Zeitlimit im folgenden Code auf 120 Sekunden festgelegt:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

E/A-Zeitüberschreitung in ServiceCallout-Richtlinie des API-Proxys anzeigen

Wählen Sie in der Edge-Benutzeroberfläche den spezifischen API-Proxy aus, in dem Sie die neue E/A anzeigen möchten. Zeitüberschreitungswert für die ServiceCallout-Richtlinie.
Wählen Sie die spezifische ServiceCallout-Richtlinie aus, die Sie prüfen möchten.
Sehen Sie sich das Element <Timeout> mit einem entsprechenden Wert unter der <ServiceCallout>-Konfiguration.

Das E/A-Zeitlimit des folgenden Codes beträgt beispielsweise 120 Sekunden:
```
<Timeout>120000</Timeout>
```

E/A-Zeitüberschreitung bei den Message Processors prüfen

Melden Sie sich beim Message Processor-Computer an.

Suchen Sie nach der Property HTTPTransport.io.timeout.millis in der /opt/apigee/edge-message-processor/conf mit dem folgenden Befehl:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

Beispielausgabe

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

Beachten Sie in der obigen Beispielausgabe, dass das Attribut HTTPTransport.io.timeout.millis wurde auf den Wert 55000 festgelegt in http.properties Dies zeigt an, dass das E/A-Zeitlimit erfolgreich konfiguriert wurde: 55 Sekunden im Message Processor

Nachdem Sie das auf dem Router und dem Message Processor konfigurierte Zeitlimit ermittelt haben, überprüfen Sie, ob das Der Router/virtuelle Host wurde mit einem niedrigeren Zeitüberschreitungswert konfiguriert als auf dem Message Processor/API-Proxy.

Notieren Sie sich die Werte, die auf allen Ebenen festgelegt sind, wie in der folgenden Tabelle gezeigt:

Zeitlimit auf Router (Sekunden)	Zeitlimit auf virtuellem Host (Sekunden)	Zeitüberschreitung beim Message Processor (Sekunden)	Zeitüberschreitung für API-Proxy (Sekunden)
57	-	55	120

In diesem Beispiel

Der Standardwert von 57 Sekunden ist auf dem Router konfiguriert.
Der Zeitüberschreitungswert ist nicht auf dem spezifischen virtuellen Host festgelegt. Das bedeutet, dass die Standardwert von 57 Sekunden, der auf dem Router selbst konfiguriert ist.
Im Message Processor wird ein Standardwert von 55 Sekunden konfiguriert.
Für den spezifischen API-Proxy wird jedoch ein Wert von 120 Sekunden konfiguriert.

Beachten Sie, dass der höhere Zeitüberschreitungswert nur für den API-Proxy konfiguriert wird, der Router jedoch weiterhin mit 57 Sekunden konfiguriert. Daher tritt beim Router nach 57 Sekunden eine Zeitüberschreitung auf, während die Nachricht Der Prozessor/Back-End verarbeitet Ihre Anfrage noch. Dadurch antwortet der Router mit 504 Gateway Timeout-Fehler an die Clientanwendung.

Auflösung

Führen Sie die folgenden Schritte aus, um das richtige E/A-Zeitlimit auf dem Router und in der Nachricht zu konfigurieren. Prozessor zur Behebung dieses Problems.

Weitere Informationen finden Sie unter <ph type="x-smartling-placeholder"></ph> Best Practices für die Konfiguration des E/A-Zeitlimits, um die Werte für das Zeitlimit zu verstehen sollte auf verschiedenen Komponenten festgelegt werden, die am API-Anfragefluss über Apigee Edge beteiligt sind.
Wenn im obigen Beispiel ein höherer Wert für das Zeitlimit festgelegt werden muss, da der Back-End-Server mehr Zeit benötigt und Sie das Zeitlimit erhöht haben des Message Processor auf 120 Sekunden festlegen und dann einen höheren Timeout-Wert für Beispiel: 123 seconds auf dem Router. Um Auswirkungen auf alle API-Proxys zu vermeiden legen Sie den Wert für 123 seconds aufgrund des neuen Zeitüberschreitungswerts nur auf der Einen bestimmten virtuellen Host, der im jeweiligen API-Proxy verwendet wird
Folgen Sie dazu der Anleitung unter <ph type="x-smartling-placeholder"></ph> E/A-Zeitlimit auf Routern konfigurieren, um das Zeitlimit auf dem virtuellen Host festzulegen.