Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

Symptom

Die Clientanwendung empfängt als Antwort auf API-Aufrufe den HTTP-Statuscode 504 mit der Nachricht Gateway Timeout.

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

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 verursacht Zeitüberschreitungen?

Der typische Pfad für eine API-Anfrage über die Edge-Plattform ist Client > Router > Message Processor > Backend Server (Client > Router > Nachrichtenprozessor > Back-End-Server), wie in der folgenden Abbildung dargestellt:

Alle Komponenten im Apigee Edge-Laufzeitfluss, einschließlich Clients, Router, Nachrichtenprozessoren und Back-End-Server, werden mit geeigneten Standardzeitlimitwerten eingerichtet, damit die Ausführung der API-Anfragen nicht zu lange dauert. Wenn eine der Komponenten im Ablauf innerhalb des in der Zeitlimitkonfiguration angegebenen Zeitraums keine Antwort von der Upstream-Komponente erhält, tritt für die spezifische Komponente eine Zeitüberschreitung auf und gibt normalerweise den Fehler 504 Gateway Timeout zurück.

In diesem Playbook wird beschrieben, wie Sie den Fehler 504 beheben, der bei einer Zeitüberschreitung des Routers auftritt.

Zeitüberschreitung auf dem Router

Das Standardzeitlimit, das für Router in Apigee Edge konfiguriert ist, beträgt 57 Sekunden. Dies ist die maximale Zeitspanne, die ein API-Proxy von dem Zeitpunkt, an dem die API-Anforderung bei Edge empfangen wird, bis zur Rücksendung der Antwort ausgeführt werden kann, einschließlich der Back-End-Antwort und aller ausgeführten Richtlinien. Das Standardzeitlimit kann auf den Routern/virtuellen Hosts überschrieben werden, wie unter E/A-Zeitlimit bei Routern konfigurieren erläutert.

Mögliche Ursachen

In Edge sind die typischen Ursachen für den Fehler 504 Gateway Timeout aufgrund einer Zeitüberschreitung des Routers:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Falsche Zeitüberschreitungskonfiguration auf dem Router	Dies geschieht, wenn der Router mit einem falschen E/A-Zeitlimit konfiguriert ist.	Nutzer von Edge Public und Private Cloud

Allgemeine Diagnoseschritte

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

API-Monitoring
NGINX-Zugriffslogs

API-Monitoring

So diagnostizieren Sie den Fehler mithilfe von API-Monitoring:

Rufen Sie die Seite Analysieren > API-Überwachung > Untersuchen auf.
Filtern Sie nach 5xx Fehlern und wählen Sie den Zeitraum aus.
Vergleiche den Statuscode mit der Zeit.
Klicken Sie auf die Zelle mit 504-Fehlern, um weitere Details und Logs zu diesen Fehlern aufzurufen (siehe unten):

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

Notieren Sie sich im Fenster Traffic-Protokolle die folgenden Details für einige 504-Fehler:
- Anfrage: Gibt die Anfragemethode und den URI an, die für die Aufrufe verwendet wurden.
- Response Time (Antwortzeit): Gibt die Gesamtzeit an, die für die Anfrage verstrichen ist.
Im obigen Beispiel
- Anfrage verweist auf GET /test-timeout.
- Die Reaktionszeit beträgt 57.001 Sekunden. Dies weist darauf hin, dass das Zeitlimit des Routers überschritten wurde, bevor der Message Processor antworten konnte, da der Wert sehr nahe an dem auf dem Router festgelegten Standard-E/A-Zeitlimit von 57 Sekunden liegt.
Sie können alle Logs auch mit der GET-Logs-API von API Monitoring abrufen. Durch die Abfrage von Logs für org, env, timeRange und status könnten Sie beispielsweise alle Logs für Transaktionen herunterladen, bei denen das Zeitlimit des Clients überschritten wurde.

Da das API-Monitoring den Proxy für diese 504-Fehler auf - (nicht festgelegt) festlegt, können Sie die API (Logs API) verwenden, um den verknüpften Proxy für den virtuellen Host und den Pfad abzurufen.

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

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 Sie nach 504-Fehlern innerhalb eines bestimmten Zeitraums (ob das Problem in der Vergangenheit aufgetreten ist) oder ob es immer noch Anfragen mit 504 gibt, die fehlschlagen.
Beachten Sie die folgenden Informationen für einige 504-Fehler:
- Reaktionszeit
- Anfrage-URI
In diesem Beispiel sehen wir die folgenden Informationen:
- Anfragezeit: 57.001 Sekunden. Dies weist darauf hin, dass es nach 57.001 Sekunden zu einer Zeitüberschreitung beim Router kam.
  
  Hinweis: Dies ist das Feld request_time in NGINX-Logs. Dies bedeutet die Verarbeitungszeit der Anfrage in Sekunden, also die Zeit, die zwischen den ersten Byte, die vom Client gelesen wurden, und dem Logschreibvorgang verstrichen sind, nachdem die letzten Byte an den Client gesendet wurden.
- Anfrage: GET /test-timeout
- Host-Alias: myorg-test.apigee.net
Hinweis: In den folgenden Feldern wird für diesen 504-Fehler der Wert - angezeigt:
- Fehlerquelle
- Fehlercode
- Fehlerfluss
- Fehlerrichtlinie
- Fehler-Proxy
Diese Felder werden vom Message Processor ausgefüllt und nur dann mit entsprechenden Werten festgelegt, wenn der Router eine Antwort vom Message Processor erhält. In diesem Fall ist beim Router eine Zeitüberschreitung vor dem Message Processor aufgetreten, da er nicht rechtzeitig geantwortet hat. Dadurch wird der Router gezwungen, den Statuscode auf 504 zu setzen. Daher werden alle oben genannten Felder als - angezeigt.
Prüfen Sie, ob die Anfragezeit mit dem E/A-Zeitlimit übereinstimmt, das auf dem Router bzw. dem virtuellen Host konfiguriert wurde. Wenn ja, bedeutet dies, dass es eine Zeitüberschreitung beim Router gab, bevor der Message Processor innerhalb dieses Zeitraums nicht geantwortet hat.

Im oben gezeigten Beispieleintrag im NGINX-Zugriffslog liegt die Anfragezeit von 57.001 Sekunden sehr nahe an dem auf dem Router festgelegten Standard-E/A-Zeitlimit. Dies weist eindeutig darauf hin, dass es eine Zeitüberschreitung beim Router gab, bevor der Message Processor antworten konnte.
Ermitteln Sie den API-Proxy, für den die Anfrage gestellt wurde. Verwenden Sie dazu den Basispfad im Feld Anfrage .

Ursache: Falsche Zeitüberschreitungskonfiguration auf dem Router

Diagnose

Ermitteln Sie, ob die 504-Fehler dadurch verursacht werden, dass der Router das Zeitlimit überschritten hat, bevor der Message Processor antworten konnte. Prüfen Sie dazu, ob die Reaktionszeit in der API-Überwachung/Anfragezeit im Router (beide Felder stellen die gleichen Informationen, aber mit unterschiedlichen Namen aufgerufen) mit dem E/A-Zeitlimit übereinstimmt, das auf dem Router/virtuellen Host konfiguriert wurde, und den Feldern Fehlerquelle, Fehlerquelle und Fehlercode mithilfe von API-Monitoring- oder NGINX-Zugriffsdiagnose-Logs auf - gesetzt ist. Informationen dazu finden Sie in den API-Monitoring- oder NGINX-Zugriffsdiagnose-Logs.
Prüfen Sie, ob das auf dem Router oder einem bestimmten virtuellen Host konfigurierte E/A-Zeitlimit niedriger ist als der Wert, der auf dem Message Processor oder dem spezifischen API-Proxy konfiguriert ist.

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

E/A-Zeitlimit auf virtuellen Hosts prüfen

Edge-Benutzeroberfläche

So prüfen Sie das Zeitlimit des virtuellen Hosts mithilfe der Edge-Benutzeroberfläche:

Melden Sie sich bei der Edge-Benutzeroberfläche an.
Gehen Sie zu Admin > Virtual Hosts (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 den Wert für das E/A-Zeitlimit prüfen möchten.
Sehen Sie sich unter Eigenschaften den Wert für die Zeitüberschreitung bei Proxy-Lesevorgängen in Sekunden an.

Im obigen Beispiel ist die Proxy-Lesezeitüberschreitung mit dem Wert 120 konfiguriert. Das bedeutet, dass das auf diesem virtuellen Host konfigurierte E/A-Zeitlimit 120 Sekunden beträgt.

Hinweis: Wenn für das Zeitlimit für Proxy-Lesevorgänge kein Wert angegeben ist, wird der auf dem Router konfigurierte Standardwert von 57 Sekunden verwendet (es sei denn, das E/A-Zeitlimit wird auf den Routerinstanzen überschrieben).

Verwaltungs-APIs

Sie können das Zeitlimit für Proxy-Lesevorgänge auch mithilfe der folgenden Verwaltungs-APIs überprüfen:

Führen Sie die Get virtual host API aus, 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üfen Sie den Wert, der für das Attribut proxy_read_timeout konfiguriert wurde.

Beispiel für einen virtuellen Host – Definition

{
  "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 dem Wert 120 konfiguriert. Das bedeutet, dass das auf diesem virtuellen Host konfigurierte E/A-Zeitlimit 120 Sekunden beträgt.

Hinweis:Wenn das Attribut proxy_read_timeout in der Ausgabe der Verwaltungs-API nicht vorhanden ist, wird der Standardwert von 57 Sekunden verwendet (es sei denn, das E/A-Zeitlimit wird auf den Routerinstanzen überschrieben).

E/A-Zeitlimit in der Datei „router.properties“ verifizieren

Melden Sie sich auf einem Router-Computer an.
Suchen Sie im Verzeichnis /opt/nginx/conf.d nach der Property proxy_read_timeout und prüfen Sie, ob sie mit dem neuen Wert festgelegt wurde:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Prüfen Sie den Wert, der für das Attribut proxy_read_timeout in der Konfigurationsdatei des jeweiligen virtuellen Hosts festgelegt wurde.

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;
```
In der obigen Beispielausgabe wurde das Attribut proxy_read_timeout mit dem neuen Wert 57 in 0-default.conf festgelegt. Dies ist die Konfigurationsdatei für den virtuellen Standardhost. Dies bedeutet, dass das E/A-Zeitlimit auf dem Router für den virtuellen Host default auf 57 Sekunden eingestellt ist. Wenn Sie mehrere virtuelle Hosts haben, werden diese Informationen für jeden von ihnen angezeigt. Rufen Sie den Wert von proxy_read_timeout für den spezifischen virtuellen Host ab, den Sie für die mit 504-Fehlern fehlgeschlagenen API-Aufrufe verwendet haben.

E/A-Zeitlimit im API-Proxy verifizieren

Sie können das E/A-Zeitlimit hier sehen:

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

E/A-Zeitlimit im Zielendpunkt des API-Proxys ansehen

Wählen Sie in der Edge-Benutzeroberfläche den jeweiligen API-Proxy aus, in dem Sie den E/A-Zeitüberschreitungswert anzeigen möchten.
Wählen Sie den Zielendpunkt aus, den Sie prüfen möchten.
Siehe Attribut io.timeout.millis mit einem geeigneten Wert unter dem Element <HTTPTargetConnection> in der 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-Zeitlimit in ServiceCallout-Richtlinie des API-Proxys ansehen

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

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

E/A-Zeitlimit auf den Message Processorn verifizieren

Melden Sie sich auf dem Message Processor-Computer an.

Suchen Sie mit dem folgenden Befehl im Verzeichnis /opt/apigee/edge-message-processor/conf nach dem Attribut HTTPTransport.io.timeout.millis:

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

In der obigen Beispielausgabe wurde das Attribut HTTPTransport.io.timeout.millis mit dem Wert 55000 in http.properties festgelegt. Dies zeigt an, dass das E/A-Zeitlimit für den Message Processor erfolgreich auf 55 Sekunden konfiguriert wurde.

Nachdem Sie das auf dem Router und dem Message Processor konfigurierte Zeitlimit ermittelt haben, prüfen Sie, ob der Router bzw. der virtuelle Host mit einem niedrigeren Zeitlimit als für den Message Processor-/API-Proxy konfiguriert wurde.

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

Zeitlimit auf dem Router (Sekunden)	Zeitlimit auf virtuellem Host (Sekunden)	Zeitüberschreitung bei Message Processor (Sekunden)	Zeitlimit am API-Proxy (Sekunden)
57	-	55	120

In diesem Beispiel

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

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

Auflösung

Führen Sie die folgenden Schritte aus, um das richtige E/A-Zeitlimit auf dem Router und dem Message Processor zu konfigurieren und dieses Problem zu beheben.

Unter Best Practices zum Konfigurieren des E/A-Zeitlimits finden Sie Informationen dazu, welche Zeitlimitwerte auf den verschiedenen Komponenten des API-Anfrageflusses über Apigee Edge festgelegt werden sollten.
Wenn Sie im obigen Beispiel feststellen, dass ein höheres Zeitlimit festgelegt werden muss, weil der Back-End-Server eine längere Zeit benötigt, und Sie den Zeitüberschreitungswert des Message Processor auf 120 Sekunden erhöht haben, legen Sie ein höheres Zeitlimit fest. Beispiel: 123 seconds auf dem Router. Damit die Auswirkungen auf alle API-Proxys aufgrund des neuen Zeitüberschreitungswerts nicht beeinträchtigt werden, legen Sie den Wert von 123 seconds nur auf dem bestimmten virtuellen Host fest, der im jeweiligen API-Proxy verwendet wird.
Folgen Sie der Anleitung unter E/A-Zeitlimit bei Routern konfigurieren, um das Zeitlimit auf dem virtuellen Host festzulegen.