499 Połączenie zamknięte przez klienta

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje błąd przekroczenia limitu czasu w przypadku żądań do interfejsu API lub żądanie jest przerywane nagle, gdy jest jeszcze wykonywane w Apigee.

W przypadku takich żądań do interfejsu API w Monitorowaniu interfejsów API i logach dostępu NGINX zobaczysz kod stanu 499. Czasami w Analytics interfejsu API zobaczysz inne kody stanu, ponieważ on wyświetla kod stanu zwrócony przez procesor komunikatów.

Komunikat o błędzie

Aplikacje klienckie mogą wyświetlać błędy takie jak: 

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

Co powoduje przekroczenie limitu czasu przez klienta?

Typowa ścieżka żądania do interfejsu API na platformie Edge to Klient > Router > Procesor komunikatów > Serwer backendu , jak pokazano na ilustracji poniżej:

Routery i procesory komunikatów na platformie Apigee Edge są skonfigurowane z odpowiednimi domyślnymi wartościami limitu czasu, aby żądania do interfejsu API nie trwały zbyt długo.

Przekroczenie limitu czasu przez klienta

Aplikacje klienckie można skonfigurować z odpowiednią wartością limitu czasu w zależności od potrzeb.

Klienci, tacy jak przeglądarki internetowe i aplikacje mobilne, mają limity czasu zdefiniowane przez system operacyjny.

Przekroczenie limitu czasu przez router

Domyślny limit czasu skonfigurowany w routerach to 57 sekund. Jest to maksymalny czas, jaki proxy interfejsu API może wykonywać od momentu otrzymania żądania do interfejsu API w Edge do momentu wysłania odpowiedzi, w tym odpowiedzi backendu i wszystkich wykonywanych zasad. Domyślny limit czasu można zastąpić w routerach i hostach wirtualnych, jak opisano w artykule Konfigurowanie limitu czasu wejścia/wyjścia w routerach.

Przekroczenie limitu czasu przez procesory komunikatów

Domyślny limit czasu skonfigurowany w procesorach komunikatów to 55 sekund. Jest to maksymalny czas , jaki serwer backendu może poświęcić na przetworzenie żądania i odpowiedź do procesora komunikatów . Domyślny limit czasu można zastąpić w procesorach komunikatów lub w proxy interfejsu API , jak opisano w artykule Konfigurowanie limitu czasu wejścia/wyjścia w procesorach komunikatów.

Jeśli klient zamknie połączenie z routerem przed przekroczeniem limitu czasu przez proxy interfejsu API, zobaczysz błąd przekroczenia limitu czasu dla konkretnego żądania do interfejsu API. W przypadku takich żądań w routerze rejestrowany jest kod stanu 499 Client Closed Connection, który można zobaczyć w Monitorowaniu interfejsów API i logach dostępu NGINX.

Możliwe przyczyny

W Edge typowe przyczyny błędu 499 Client Closed Connection to:

Przyczyna Opis Instrukcje rozwiązywania problemów, których dotyczy
Klient nagle zamknął połączenie Dzieje się tak, gdy klient zamyka połączenie, ponieważ użytkownik anuluje żądanie przed jego zakończeniem. Użytkownicy chmury publicznej i prywatnej
Przekroczenie limitu czasu przez aplikację kliencką Dzieje się tak, gdy aplikacja kliencka przekroczy limit czasu, zanim proxy interfejsu API zdąży przetworzyć i wysłać odpowiedź. Zwykle dzieje się tak, gdy limit czasu klienta jest krótszy niż limit czasu routera. Użytkownicy chmury publicznej i prywatnej

Typowe czynności diagnostyczne

Aby zdiagnozować ten błąd, użyj jednego z tych narzędzi lub technik:

  • Monitorowanie interfejsów API
  • Logi dostępu NGINX

Monitorowanie interfejsów API

Aby zdiagnozować błąd za pomocą Monitorowania interfejsów API:

  1. Otwórz stronę Analiza > Monitorowanie interfejsów API > Zbadaj.
  2. Filtruj błędy 4xx i wybierz przedział czasu.
  3. Wykreśl Kod stanu względem Czasu.
  4. Wybierz komórkę z błędami 499, jak pokazano poniżej:

  5. W panelu po prawej stronie zobaczysz informacje o błędzie 499, jak pokazano poniżej:

  6. W panelu po prawej stronie kliknij Wyświetl logi.

    W oknie Logi ruchu zanotuj te szczegóły dotyczące niektórych błędów 499:

    • Żądanie:zawiera metodę żądania i identyfikator URI używane do wykonywania wywołań.
    • Czas odpowiedzi:zawiera łączny czas, jaki upłynął od wysłania żądania.

    Możesz też pobrać wszystkie logi za pomocą interfejsu API Monitorowania GET logs interfejsów API. Na przykład, wysyłając zapytanie do logów według org, env, timeRange, i status, możesz pobrać wszystkie logi transakcji, w których przekroczono limit czasu klienta.

    Ponieważ Monitorowanie interfejsów API ustawia proxy na - w przypadku błędów HTTP 499 , możesz użyć interfejsu API (Logs API), aby uzyskać powiązane proxy dla hosta wirtualnego i ścieżki.

    Na przykład : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Sprawdź Czas odpowiedzi w przypadku dodatkowych błędów 499 i sprawdź, czy Czas odpowiedzi jest spójny (np. 30 sekund) we wszystkich błędach 499.

Logi dostępu NGINX

Aby zdiagnozować błąd za pomocą logów dostępu NGINX:

  1. Jeśli jesteś użytkownikiem chmury prywatnej , możesz użyć logów dostępu NGINX, aby określić kluczowe informacje o błędach HTTP 499.
  2. Sprawdź logi dostępu NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Sprawdź, czy w określonym czasie występują błędy 499 (jeśli problem wystąpił w przeszłości) lub czy nadal występują żądania, które kończą się niepowodzeniem z kodem 499.
  4. Zanotuj te informacje dotyczące niektórych błędów 499:
    • Łączny czas odpowiedzi
    • Identyfikator URI żądania
    • Klient użytkownika

    Przykładowy błąd 499 z logu dostępu NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    W tym przykładzie widzimy te informacje:

    • Łączny czas odpowiedzi: 10.001 sekundy. Oznacza to, że klient przekroczył limit czasu po 10,001 sekundy.
    • Żądanie: GET /v1/products
    • Host:api.acme.org
    • Klient użytkownika:okhttp/3.9.1
  5. Sprawdź, czy Łączny czas odpowiedzi i Klient użytkownika są spójne we wszystkich 499 błędach.

Przyczyna: klient nagle zamknął połączenie

Diagnostyka

  1. Gdy interfejs API jest wywoływany z aplikacji jednostronicowej działającej w przeglądarce lub aplikacji mobilnej, przeglądarka przerwie żądanie, jeśli użytkownik nagle zamknie przeglądarkę, przejdzie na inną stronę w tej samej karcie lub zatrzyma ładowanie strony, klikając lub dotykając zatrzymaj ładowanie.
  2. W takim przypadku czas przetwarzania żądania (Czas odpowiedzi) w przypadku transakcji ze stanem HTTP 499 będzie się różnić w zależności od żądania.
  3. Możesz sprawdzić, czy to jest przyczyną, porównując Czas odpowiedzi i sprawdzając, czy jest on inny w przypadku każdego błędu 499, za pomocą Monitorowania interfejsów API lub logów dostępu NGINX, jak opisano w sekcji Typowe czynności diagnostyczne.

Rozwiązanie

  1. Jest to normalne i zwykle nie stanowi powodu do obaw, jeśli błędy HTTP 499 errors są happening w niewielkich ilościach.

  2. Jeśli często występuje w przypadku tej samej ścieżki adresu URL, może to być spowodowane tym, że proxy powiązane z tą ścieżką działa bardzo wolno i użytkownicy nie chcą czekać.

    Gdy wiesz, które proxy może być dotknięte, użyj panelu analizy opóźnień aby dokładniej zbadać, co powoduje opóźnienie proxy.

    1. W tym przypadku określ proxy, którego dotyczy problem, wykonując czynności opisane w sekcji Typowe czynności diagnostyczne.
    2. Użyj panelu analizy opóźnień, aby dokładniej zbadać, co powoduje opóźnienie proxy, i rozwiązać problem.
    3. Jeśli stwierdzisz, że opóźnienie jest oczekiwane w przypadku konkretnego proxy, musisz poinformować użytkowników, że to proxy będzie odpowiadać z opóźnieniem.

Przyczyna: przekroczenie limitu czasu przez aplikację kliencką

Może się to zdarzyć w kilku sytuacjach.

  1. Oczekuje się, że w normalnych warunkach operacyjnych wykonanie żądania zajmie określony czas (np. 10 sekund) . Aplikacja kliencka jest jednak skonfigurowana z nieprawidłową wartością limitu czasu (np. 5 sekund), co powoduje, że aplikacja kliencka przekracza limit czasu przed zakończeniem żądania do interfejsu API, co prowadzi do błędu 499. W takim przypadku musimy ustawić odpowiednią wartość limitu czasu klienta.
  2. Serwer docelowy lub wywołanie trwa dłużej niż oczekiwano. W takim przypadku musisz naprawić odpowiedni komponent i odpowiednio dostosować wartości limitu czasu.
  3. Klient nie potrzebował już odpowiedzi i dlatego przerwał działanie. Może się to zdarzyć w przypadku interfejsów API o wysokiej częstotliwości, takich jak autouzupełnianie lub krótkie odpytywanie.

Diagnostyka

Monitorowanie interfejsów API lub logi dostępu NGINX

Aby zdiagnozować błąd za pomocą Monitorowania interfejsów API lub logów dostępu NGINX:

  1. Sprawdź logi Monitorowania interfejsów API lub logi dostępu NGINX pod kątem transakcji HTTP 499 jak opisano w Typowe czynności diagnostyczne.
  2. Sprawdź, czy Czas odpowiedzi jest spójny we wszystkich błędach 499.
  3. Jeśli tak, może to oznaczać, że konkretna aplikacja kliencka ma skonfigurowany stały limit czasu. Jeśli proxy interfejsu API lub serwer docelowy odpowiada powoli, klient przekroczy limit czasu przed przekroczeniem limitu czasu przez proxy, co spowoduje dużą liczbę błędów HTTP 499s w przypadku tej samej ścieżki URI. W takim przypadku określ Klienta użytkownika na podstawie logów dostępu NGINX, co pomoże Ci określić konkretną aplikację kliencką.
  4. Możliwe jest też, że przed Apigee znajduje się system równoważenia obciążenia, taki jak Akamai, F5, AWS ELB itp. Jeśli Apigee działa za niestandardowym systemem równoważenia obciążenia, limit czasu żądania systemu równoważenia obciążenia musi być skonfigurowany tak, aby był dłuższy niż limit czasu interfejsu API Apigee. Domyślnie router Apigee przekracza limit czasu po 57 sekundach, dlatego warto skonfigurować limit czasu żądania na 60 sekund w systemie równoważenia obciążenia.

Śledzenie

Aby zdiagnozować błąd za pomocą Śledzenia:

Jeśli problem nadal występuje (499 błędy nadal się pojawiają), wykonaj następujące czynności:

  1. Włącz sesję śledzenia dla interfejsu API, którego dotyczy problem, w interfejsie Edge.
  2. Poczekaj na wystąpienie błędu lub, jeśli masz wywołanie interfejsu API, wykonaj kilka wywołań interfejsu API i odtwórz błąd.
  3. Sprawdź czas, jaki upłynął w każdej fazie, i zanotuj fazę, w której spędzasz najwięcej czasu jest wydawane.
  4. Jeśli błąd z najdłuższym czasem, jaki upłynął, występuje bezpośrednio po jednej z tych faz, oznacza to, że serwer backendu działa wolno lub przetwarza żądanie przez długi czas:
    • Żądanie wysłane do serwera docelowego
    • Zasada ServiceCallout

    Oto przykładowy ślad interfejsu pokazujący przekroczenie limitu czasu bramy po wysłaniu żądania zostało wysłane do serwera docelowego:

Rozwiązanie

  1. Zapoznaj się z artykułem Sprawdzone metody konfigurowania limitu czasu wejścia/wyjścia, aby dowiedzieć się, jakie wartości limitu czasu należy ustawić w różnych komponentach biorących udział w przepływie żądania do interfejsu API przez Apigee Edge.
  2. Upewnij się, że w aplikacji klienckiej ustawisz odpowiednią wartość limitu czasu zgodnie ze sprawdzonymi metodami.

Jeśli problem nadal występuje, przejdź do sekcji Informacje diagnostyczne, które musisz zebrać .

Informacje diagnostyczne, które musisz zebrać

Jeśli problem nadal występuje, zbierz te informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge.

Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:

  • Nazwa organizacji
  • Nazwa środowiska
  • Nazwa proxy interfejsu API
  • Pełne polecenie curl użyte do odtworzenia błędu przekroczenia limitu czasu
  • Plik śledzenia żądań do interfejsu API, w przypadku których występują błędy przekroczenia limitu czasu klienta

Jeśli jesteś użytkownikiem chmury prywatnej, podaj te informacje:

  • Pełny komunikat o błędzie występującym w przypadku żądań, które kończą się niepowodzeniem
  • Nazwa środowiska
  • Pakiet proxy interfejsu API
  • Plik śledzenia żądań do interfejsu API, w przypadku których występują błędy przekroczenia limitu czasu klienta
  • Logi dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Logi systemowe procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log)