499 Połączenie zamknięte przez klienta

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

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

W przypadku takich żądań do interfejsu API będziesz obserwować kod stanu 499 w logach monitorowania interfejsów API i w logach dostępu NGINX. Czasami w interfejsie API Analytics mogą występować różne kody stanu, ponieważ pokazuje on kod stanu zwrócony przez podmiot przetwarzający wiadomości.

Komunikat o błędzie

Aplikacje klienckie mogą napotkać takie błędy: 

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

Co powoduje przekroczenie limitu czasu oczekiwania klienta?

Typowa ścieżka żądania interfejsu API na platformie brzegowej to Klient > Router > Procesor wiadomości > Serwer backendu, jak pokazano na tym ilustracji:

Routery i procesory wiadomości na platformie Apigee Edge mają skonfigurowane odpowiednie domyślne wartości limitu czasu, aby żądania do interfejsu API nie trwały zbyt długo.

Upłynął limit czasu po stronie klienta

Aplikacje klienckie można skonfigurować przez skonfigurowanie odpowiedniej wartości limitu czasu w zależności od potrzeb.

Czasy oczekiwania są określone przez system operacyjny klientów, takich jak przeglądarki czy aplikacje mobilne.

Przekroczony limit czasu na routerze

Domyślny limit czasu skonfigurowany w routerach to 57 sekund. Jest to maksymalny czas, przez jaki serwer proxy interfejsu API może być wykonywany od momentu otrzymania żądania do interfejsu API w Edge do momentu zwrócenia odpowiedzi. Obejmuje to odpowiedź backendu i wszystkie uruchomione zasady. Domyślny limit czasu można zastąpić w routerach i hostach wirtualnych zgodnie z opisem w sekcji Konfigurowanie limitu czasu wejścia-wyjścia w routerach.

Przekroczenie limitu czasu oczekiwania na procesory wiadomości

Domyślny limit czasu skonfigurowany w procesach przetwarzania wiadomości to 55 sekund. Jest to maksymalny czas, którego serwer backendu może potrzebować na przetworzenie żądania i odpowiedź do podmiotu przetwarzającego wiadomości. Domyślny limit czasu można zastąpić w procesorach wiadomości lub w ramach serwera proxy interfejsu API, zgodnie z opisem w sekcji Konfigurowanie limitu czasu wejścia/wyjścia w procesorach wiadomości.

Jeśli klient zamknie połączenie z routerem przed upływem czasu oczekiwania serwera proxy interfejsu API, zobaczysz błąd przekroczenia limitu czasu dla konkretnego żądania do interfejsu API. W przypadku takich żądań kod stanu 499 Client Closed Connection jest logowany w routerze w przypadku takich żądań, co można zaobserwować w logach monitorowania interfejsów API i logów dostępu NGINX.

Możliwe przyczyny

Typowe przyczyny błędu 499 Client Closed Connection w Edge:

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Klient nagle zamknął połączenie Dzieje się tak, gdy klient zamknie połączenie w wyniku anulowania żądania przez użytkownika przed jego zakończeniem. Publiczni i prywatni użytkownicy chmury
Upłynął limit czasu aplikacji klienckiej Dzieje się tak, gdy aplikacja kliencka przekroczy limit czasu, zanim serwer proxy interfejsu API zbierze czas na przetworzenie i wysłanie odpowiedzi. Zwykle dzieje się tak, gdy czas oczekiwania klienta jest krótszy niż limit czasu routera. Publiczni i prywatni użytkownicy chmury

Najczęstsze kroki diagnostyki

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

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

Monitorowanie interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsu API:

  1. Otwórz stronę Analiza > Monitorowanie interfejsów API > Zbadaj.
  2. Przefiltruj widok pod kątem 4xx błędów i wybierz przedział czasu.
  3. Porównaj kod stanu z Czasem.
  4. Wybierz komórkę zawierającą 499 błędów, jak pokazano poniżej:

  5. Informacje o błędzie 499 zostaną wyświetlone w panelu po prawej stronie, jak pokazano poniżej:

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

    W oknie Logi ruchu zwróć uwagę na te informacje dotyczące niektórych błędów 499:

    • Żądanie: określa metodę żądania i identyfikator URI, które są używane do wykonywania wywołań.
    • Czas odpowiedzi:łączny czas, jaki upłynął w przypadku żądania.

    Wszystkie logi możesz też pobrać za pomocą interfejsu API Monitoring GET. Jeśli na przykład wyślesz zapytanie do logów org, env, timeRange i status, możesz pobrać wszystkie logi transakcji, w przypadku których upłynął limit czasu klienta.

    Monitorowanie interfejsów API ustawia serwer proxy na - w przypadku błędów HTTP 499, więc możesz użyć interfejsu API (Logs API), aby uzyskać powiązany serwer 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 pod kątem dodatkowych 499 błędów i zobacz, czy czas odpowiedzi jest spójny (np. 30 sekund) we wszystkich błędach 499.

Logi dostępu NGINX

Aby zdiagnozować błąd przy użyciu logów dostępu NGINX:

  1. Jeśli jesteś użytkownikiem Private Cloud, możesz użyć logów dostępu NGINX, aby określić kluczowe informacje o błędach HTTP 499.
  2. Sprawdź logi dostępu do NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Sprawdź, czy w danym okresie wystąpiły jakieś błędy 499 (jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 499.
  4. Zwróć uwagę na te informacje dotyczące niektórych błędów (499):
    • Całkowity czas odpowiedzi
    • Identyfikator URI żądania
    • klient użytkownika,

    Przykładowy błąd 499 z dziennika 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 następujące informacje:

    • Całkowity czas odpowiedzi: 10.001 s. Oznacza to, że klient przekroczył limit czasu po 10,001 sekundy
    • Prośba: GET /v1/products
    • Gospodarz:api.acme.org
    • Klient użytkownika:okhttp/3.9.1
  5. Sprawdź, czy wartości Total Response Time i Klient użytkownika są spójne we wszystkich błędach 499.

Przyczyna: klient nagle zamknął połączenie

Diagnostyka

  1. Gdy interfejs API jest wywoływany z aplikacji jednostronicowej uruchomionej w przeglądarce lub aplikacji mobilnej, przeglądarka przerwie żądanie, jeśli użytkownik nagle ją zamknie, przejdzie na inną stronę w tej samej karcie lub zatrzyma wczytywanie strony, klikając zatrzymaj wczytywanie.
  2. W takim przypadku transakcje o stanie HTTP 499 zwykle różnią się czasem przetwarzania żądań (Czas odpowiedzi) dla poszczególnych żądań.
  3. Aby ustalić, czy jest to przyczyną, możesz porównać czas odpowiedzi i sprawdzić, czy jest inny dla każdego z błędów 499, korzystając z logów monitorowania interfejsów API lub logów dostępu NGINX, jak opisano w typowych krokach diagnostyki.

Rozdzielczość

  1. Jest to normalne i zwykle nie jest powodem do niepokoju, jeśli błędy HTTP 499 występują w małych ilościach.

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

    Gdy dowiesz się, którego serwera proxy może to dotyczyć, użyj panelu analizy czasu oczekiwania, aby dokładniej zbadać przyczynę opóźnień serwera proxy.

    1. W takim przypadku ustal, którego serwera proxy dotyczy problem, wykonując czynności opisane w sekcji Typowe czynności diagnostyczne.
    2. Użyj panelu analizy czasu oczekiwania, aby dokładniej zbadać, co powoduje opóźnienia serwera proxy, i rozwiązać problem.
    3. Jeśli stwierdzisz, że dla określonego serwera proxy opóźnienie jest spodziewane, być może trzeba będzie poinformować użytkowników, że odpowiedź z tym serwerem proxy może trochę potrwać.

Przyczyna: przekroczenie limitu czasu aplikacji klienckiej

Może się to zdarzyć w różnych sytuacjach.

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

Diagnostyka

Monitorowanie interfejsów API lub logi dostępu do NGINX

Zdiagnozuj błąd za pomocą monitorowania interfejsu API lub logów dostępu NGINX:

  1. Sprawdź dzienniki monitorowania interfejsów API lub logi dostępu NGINX pod kątem transakcji HTTP 499 zgodnie z opisem w typowych krokach diagnostycznych.
  2. Ustal, czy czas odpowiedzi jest spójny w przypadku wszystkich błędów 499.
  3. Jeśli tak, może to oznaczać, że konkretna aplikacja kliencka skonfigurowała po swojej stronie stały limit czasu. Jeśli serwer proxy interfejsu API lub serwer docelowy odpowiada powoli, klient przekroczy limit czasu, zanim nastąpi przekroczenie limitu czasu serwera proxy, co spowoduje duże ilości żądań HTTP 499s dla tej samej ścieżki identyfikatora URI. W tym przypadku określ klienta użytkownika w logach dostępu NGINX, aby ułatwić Ci określenie konkretnej aplikacji klienckiej.
  4. Przed Apigee może też istnieć system równoważenia obciążenia, taki jak Akamai, F5, AWS ELB itd. Jeśli Apigee działa za niestandardowym systemem równoważenia obciążenia, musisz skonfigurować czas oczekiwania żądania systemu równoważenia obciążenia tak, aby przekraczał czas oczekiwania interfejsu Apigee API. Domyślnie router Apigee przekracza limit czasu po 57 sekundach, dlatego należy skonfigurować czas oczekiwania żądania wynoszący 60 sekund w systemie równoważenia obciążenia.

Trace

Zdiagnozowanie błędu za pomocą logu czasu

Jeśli problem jest nadal aktywny (pojawia się 499 błędów), wykonaj te czynności:

  1. Włącz sesję śledzenia dla interfejsu API, którego dotyczy problem, w interfejsie użytkownika 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 trwania poszczególnych faz i zanotuj, w których z nich spędzasz najwięcej czasu.
  4. Jeśli błąd występuje najdłużej bezpośrednio po jednej z poniższych faz, oznacza to, że serwer backendu działa wolno lub bardzo długo przetwarza żądanie:
    • Żądanie wysłane do serwera docelowego
    • Zasady dotyczące objaśnień dotyczących usług

    Oto przykładowy zrzut interfejsu użytkownika pokazujący Przekroczenie limitu czasu bramy po wysłaniu żądania do serwera docelowego:

Rozdzielczość

  1. Zapoznaj się ze sprawdzonymi metodami konfigurowania limitu czasu wejścia-wyjścia, aby dowiedzieć się, jakie wartości czasu oczekiwania należy ustawiać w różnych komponentach uczestniczących w przepływie żądań do interfejsu API przez Apigee Edge.
  2. Ustaw odpowiednią wartość limitu czasu w aplikacji klienckiej zgodnie ze sprawdzonymi metodami.

Jeśli problem nadal występuje, zapoznaj się z artykułem Wymagane jest zebranie informacji diagnostycznych .

Musisz zebrać informacje diagnostyczne

Jeśli problem będzie się powtarzać, zbierz poniższe 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 serwera proxy interfejsu API
  • Wykonaj polecenie curl użyte do odtworzenia błędu przekroczenia limitu czasu
  • Plik śledzenia dla żądań do interfejsu API, w przypadku których występują błędy przekroczenia limitu czasu klienta

Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:

  • Zaobserwowany pełny komunikat o błędzie dotyczący nieudanych żądań
  • Nazwa środowiska
  • Pakiet proxy API
  • Plik śledzenia dla żą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)
  • Dzienniki systemowe procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log)