499-Clientverbindung geschlossen

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

Symptom

Die Clientanwendung erhält einen Zeitüberschreitungsfehler für API-Anfragen oder die Anfrage wird abrupt beendet, während die API-Anfrage noch auf Apigee ausgeführt wird.

Für solche API-Anfragen im API-Monitoring und in NGINX-Zugriffslogs wird der Statuscode 499 angezeigt. Manchmal werden in API Analytics unterschiedliche Statuscodes angezeigt, weil sie den vom Message Processor zurückgegebenen Statuscode enthält.

Fehlermeldung

In Client-Anwendungen können folgende Fehler angezeigt werden:

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

Wodurch kommt es zu Zeitüberschreitungen bei Clients?

Der typische Pfad für eine API-Anfrage auf der Edge-Plattform lautet Client > Router > Message Processor > Back-End-Server, wie in der folgenden Abbildung dargestellt:

Die Router und Nachrichtenprozessoren auf der Apigee Edge-Plattform werden mit geeigneten Standardzeitlimitwerten eingerichtet, damit die Ausführung der API-Anfragen nicht zu lange dauert.

Zeitüberschreitung auf Client

Clientanwendungen können je nach Ihren Anforderungen mit einem geeigneten Zeitüberschreitungswert konfiguriert werden.

Bei Clients wie Webbrowsern und mobilen Apps werden vom Betriebssystem vorgegebene Zeitlimits festgelegt.

Zeitüberschreitung auf dem Router

Das für Router konfigurierte Standardzeitlimit 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 Backend-Antwort und aller ausgeführten Richtlinien. Das Standardzeitlimit kann auf den Routern und virtuellen Hosts überschrieben werden, wie unter E/A-Zeitlimit bei Routern konfigurieren erläutert.

Zeitüberschreitung bei Nachrichtenprozessoren

Das auf Message Processors konfigurierte Standardzeitlimit beträgt 55 Sekunden. Dies ist die maximale Zeit, die der Back-End-Server benötigen kann, um die Anfrage zu verarbeiten und dem Message Processor zu antworten. Das Standardzeitlimit kann auf den Message Processorn oder im API-Proxy überschrieben werden, wie unter E/A-Zeitlimit für Message Processors konfigurieren erläutert.

Wenn der Client die Verbindung mit dem Router schließt, bevor das Zeitlimit für den API-Proxy überschritten wurde, wird der Zeitüberschreitungsfehler für die jeweilige API-Anfrage angezeigt. Für solche Anfragen wird der Statuscode 499 Client Closed Connection im Router protokolliert. Dies kann in API-Monitoring und NGINX-Zugriffslogs beobachtet werden.

Mögliche Ursachen

In Edge sind die typischen Ursachen für den Fehler 499 Client Closed Connection:

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Client hat die Verbindung abrupt geschlossen	Dies geschieht, wenn der Client die Verbindung schließt, weil der Endnutzer die Anfrage abgebrochen hat, bevor sie abgeschlossen ist.	Nutzer öffentlicher und privater Clouds
Zeitüberschreitung bei Clientanwendung	Dies geschieht, wenn für die Clientanwendung eine Zeitüberschreitung auftritt, bevor der API-Proxy Zeit hat, die Antwort zu verarbeiten und zu senden. In der Regel geschieht dies, wenn das Zeitlimit des Clients unter dem Zeitlimit des Routers liegt.	Nutzer öffentlicher und privater Clouds

Allgemeine Diagnoseschritte

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

• API-Monitoring
• NGINX-Zugriffslogs

Ursache: Client hat die Verbindung abrupt geschlossen

Diagnose

1. Wenn eine API von einer Single-Page-App aufgerufen wird, die in einem Browser oder in einer mobilen App ausgeführt wird, bricht der Browser die Anfrage ab, wenn der Endnutzer plötzlich den Browser schließt, zu einer anderen Webseite im selben Tab wechselt oder das Laden der Seite durch Klicken oder Tippen auf close Laden beenden anhält.
2. In diesem Fall variieren die Transaktionen mit dem HTTP-Status 499 normalerweise für jede Anfrage in der Verarbeitungszeit der Anfrage (Reaktionszeit).
3. Sie können feststellen, ob dies die Ursache ist. Vergleichen Sie dazu die Reaktionszeit und prüfen Sie, ob sie für jeden der 499-Fehler unterschiedlich ist. Verwenden Sie dazu API-Monitoring- oder NGINX-Zugriffslogs, wie unter Allgemeine Diagnoseschritte beschrieben.

Auflösung

1. Das ist normal und hat in der Regel keinen Grund zur Sorge, wenn die HTTP-499-Fehler nur in kleinen Mengen auftreten.

2. Tritt das Problem häufig für denselben URL-Pfad auf, ist der jeweilige Proxy, der mit diesem Pfad verknüpft ist, sehr langsam und Nutzer sind nicht zu warten bereit.

   Sobald Sie wissen, welcher Proxy betroffen sein könnte, verwenden Sie das Dashboard für die Latenzanalyse, um die Ursache der Proxy-Latenz genauer zu untersuchen.

   1. Ermitteln Sie in diesem Fall anhand der Schritte unter Allgemeine Diagnoseschritte den betroffenen Proxy.
   2. Verwenden Sie das Dashboard für die Latenzanalyse, um die Ursache der Proxy-Latenz weiter zu untersuchen und das Problem zu beheben.
   3. Wenn Sie feststellen, dass die Latenz für den spezifischen Proxy erwartet wird, müssen Sie Ihre Nutzer möglicherweise darüber informieren, dass die Antwort dieses Proxys einige Zeit in Anspruch nimmt.

Ursache: Zeitüberschreitung bei Clientanwendung

Dies kann in verschiedenen Szenarien vorkommen.

1. Unter normalen Betriebsbedingungen wird erwartet, dass die Anfrage eine bestimmte Zeit (z. B. 10 Sekunden) dauert. Die Clientanwendung ist jedoch auf einen falschen Zeitüberschreitungswert (z. B. 5 Sekunden) eingestellt. Dies führt dazu, dass vor Abschluss der API-Anfrage eine Zeitüberschreitung auftritt, was zu 499 führt. In diesem Fall müssen wir das Zeitlimit des Clients auf einen geeigneten Wert festlegen.
2. Ein Zielserver oder ein Callout dauert länger als erwartet. In diesem Fall müssen Sie die entsprechende Komponente korrigieren und die Zeitüberschreitungswerte entsprechend anpassen.
3. Der Client benötigte die Antwort nicht mehr und wurde daher abgebrochen. Dies kann bei APIs mit hoher Häufigkeit wie Auto-Vervollständigung oder kurzem Polling der Fall sein.

Diagnose

API-Monitoring oder NGINX-Zugriffslogs

Diagnostizieren Sie den Fehler mithilfe von API-Monitoring oder NGINX-Zugriffslogs:

1. Prüfen Sie die API-Monitoringlogs oder NGINX-Zugriffslogs für die HTTP-499-Transaktionen, wie unter Allgemeine Diagnoseschritte erläutert.
2. Prüfen Sie, ob die Antwortzeit für alle 499-Fehler konsistent ist.
3. Wenn ja, hat möglicherweise eine bestimmte Clientanwendung ein festes Zeitlimit auf ihrer Seite konfiguriert. Wenn ein API-Proxy- oder Zielserver langsam reagiert, kommt es beim Client vor einer Zeitüberschreitung des Proxys zu einer Zeitüberschreitung, was zu großen Mengen von HTTP-499s für denselben URI-Pfad führt. Bestimmen Sie in diesem Fall den User-Agent aus den NGINX-Zugriffslogs. Damit lässt sich die spezifische Clientanwendung ermitteln.
4. Es kann auch sein, dass vor Apigee ein Load-Balancer wie Akamai, F5, AWS ELB usw. steht. Wenn Apigee hinter einem benutzerdefinierten Load-Balancer ausgeführt wird, muss das Anfragezeitlimit des Load-Balancers so konfiguriert werden, dass es höher als das Apigee API-Zeitlimit ist. Standardmäßig läuft beim Apigee-Router nach 57 Sekunden eine Zeitüberschreitung ab. Daher empfiehlt es sich, ein Anfragezeitlimit von 60 Sekunden auf dem Load-Balancer zu konfigurieren.

Trace

Fehler mit Trace diagnostizieren

Wenn das Problem immer noch aktiv ist (499 Fehler treten immer noch auf), führen Sie die folgenden Schritte aus:

1. Aktivieren Sie die Trace-Sitzung für die betroffene API in der Edge-Benutzeroberfläche.
2. Warten Sie entweder, bis der Fehler auftritt, oder führen Sie nach dem API-Aufruf einige API-Aufrufe aus und reproduzieren Sie den Fehler.
3. Prüfen Sie in jeder Phase die verstrichene Zeit und notieren Sie sich die Phase, in der Sie die meiste Zeit aufgewendet haben.
4. Wenn direkt nach einer der folgenden Phasen der Fehler mit der längsten verstrichenen Zeit auftritt, weist dies darauf hin, dass der Back-End-Server langsam ist oder lange für die Verarbeitung der Anfrage benötigt wird:
   • Anfrage an Zielserver gesendet
   • ServiceCallout policy

   Hier ist ein Beispiel für einen UI-Trace, der eine Gateway-Zeitüberschreitung zeigt, nachdem die Request an den Zielserver gesendet wurde:

   

Auflösung

1. Unter Best Practices zum Konfigurieren des E/A-Zeitlimits finden Sie Informationen dazu, welche Zeitlimitwerte für die verschiedenen Komponenten des API-Anfrageflusses über Apigee Edge festgelegt werden sollten.
2. Legen Sie in der Clientanwendung ein geeignetes Zeitlimit gemäß den Best Practices fest.

Wenn das Problem weiterhin besteht, lesen Sie den Abschnitt Diagnoseinformationen müssen erfasst werden .

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem weiterhin besteht, stellen Sie die folgenden Diagnoseinformationen zusammen und wenden Sie sich an den Apigee Edge-Support.

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

• Name der Organisation
• Name der Umgebung
• API-Proxy-Name
• Schließen Sie den Befehl curl ab, um den Zeitüberschreitungsfehler zu reproduzieren.
• Ablaufverfolgungsdatei für die API-Anfragen, bei denen Client-Zeitüberschreitungsfehler auftreten

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

• Vollständige Fehlermeldung bei fehlgeschlagenen Anfragen
• Name der Umgebung
• API-Proxy-Bundle
• Ablaufverfolgungsdatei für die API-Anfragen, bei denen Client-Zeitüberschreitungsfehler auftreten
• NGINX-Zugriffslogs (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
• Systemprotokolle von Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)