499 Połączenie zamknięte przez klienta

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

Aplikacja kliencka otrzymuje błąd przekroczenia limitu czasu dla żądań do interfejsu API lub żądanie zostaje zakończone nagle podczas wykonywania żądania do interfejsu API w Apigee.

będziesz obserwować kod stanu 499 dla takich żądań do interfejsu API w usłudze API Monitoring. Logi dostępu NGINX. Czasami w interfejsie API Analytics widoczne są różne kody stanu, pokazuje kod stanu zwrócony przez procesor wiadomości.

Komunikat o błędzie

Aplikacje klienckie mogą zobaczyć błędy takie jak: 

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

Co powoduje przekroczenie czasu oczekiwania klienta?

Typowa ścieżka żądania do interfejsu API na platformie Edge to Klient > Router > Procesor wiadomości > Serwer backendu zgodnie z tą ilustracją:

Routery i procesory wiadomości na platformie Apigee Edge są odpowiednio skonfigurowane domyślne wartości limitu czasu, by realizacja żądań do interfejsu API nie trwała zbyt długo.

Upłynął limit czasu klienta

Dla aplikacji klienckich można ustawić odpowiednią wartość limitu czasu w zależności od potrzeb.

Klienty takie jak przeglądarki czy aplikacje mobilne mają limity czasu zdefiniowane przez system operacyjny.

Upłynął limit czasu w routerze

Domyślny limit czasu skonfigurowany na routerach to 57 sekund. Jest to maksymalny czas Serwer proxy interfejsu API może być wykonywany od momentu otrzymania żądania do interfejsu API w Edge do momentu z powrotem, w tym z odpowiedzią backendu i wszystkimi wykonywanymi zasadami. Domyślny czas oczekiwania można zastąpić na routerach i hostach wirtualnych, jak wyjaśniono w artykule Konfiguruję czas oczekiwania na operacje wejścia-wyjścia w routerach.

Czas oczekiwania w procesorach wiadomości

Domyślny limit czasu skonfigurowany w systemach przetwarzania wiadomości wynosi 55 sekund. To jest maksymalna kwota ile czasu może zająć serwer backendu na przetworzenie żądania i odpowiedź na komunikat Podmiot przetwarzający. Domyślny limit czasu można zastąpić w procesorach komunikatów lub w interfejsie API Serwer proxy został opisany w artykule Konfiguruję czas oczekiwania na operacje 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, wyświetli błąd przekroczenia limitu czasu dla konkretnego żądania do interfejsu API. W przypadku takich żądań w routerze logowany jest kod stanu 499 Client Closed Connection, który można zaobserwować w interfejsie API Logi monitorowania i dostępu NGINX.

Możliwe przyczyny

Oto 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 zamyka połączenie, ponieważ użytkownik anuluje przed zakończeniem. Użytkownicy chmury publicznej i prywatnej
Czas oczekiwania aplikacji klienckiej Dzieje się tak, gdy upływa limit czasu działania aplikacji klienckiej, zanim serwer proxy interfejsu API zdąży i wysyłanie odpowiedzi. Zwykle dzieje się tak, gdy limit czasu klienta jest krótszy ponad limit czasu routera. Użytkownicy chmury publicznej i prywatnej

Typowe kroki diagnostyki

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

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

Monitorowanie interfejsów API

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

  1. Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
  2. Odfiltruj błędy (4xx) i wybierz przedział czasu.
  3. Porównaj Kod stanu z czasem.
  4. Wybierz komórkę, która zawiera 499 błędów, jak pokazano poniżej:

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

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

    W oknie Logi ruchu zapoznaj się z poniższymi informacjami na temat niektórych zdarzeń typu 499 błędy:

    • Request (Żądanie): określa metodę żądania i identyfikator URI używane do wykonywania wywołań.
    • Czas odpowiedzi:podaje łączny czas realizacji żądania.
    .

    Wszystkie logi można też pobrać za pomocą interfejsu API Monitoring interfejsu API pobierania logów. Dla: na przykład wysyłając zapytania dotyczące logów org, env timeRange i status, możesz pobrać wszystkie Dzienniki transakcji, w przypadku których przekroczono limit czasu klienta.

    Monitorowanie interfejsów API ustawia serwer proxy na - dla HTTP 499. możesz użyć interfejsu API (Logs API), aby pobrać powiązany serwer proxy dla wirtualnego hosta 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 błędów (499) i sprawdź, czy Czas odpowiedzi jest spójny (powiedzmy 30 sekund) 499 błędów.

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 NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Wyszukaj błędy (499) w tym okresie (jeśli problem wystąpił w przeszłości) lub jeśli masz jakieś żądania, które nadal kończą się niepowodzeniem 499
  4. Zwróć uwagę na te informacje dotyczące niektórych błędów typu 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 widoczne są te informacje:

    • Całkowity czas odpowiedzi: 10.001 s. Oznacza to, że przekroczono limit czasu klienta 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 (Całkowity czas odpowiedzi) i User Agent (Klient użytkownika) są stałe. we wszystkich 499 błędach.

Przyczyna: klient nagle zamknął połączenie

Diagnostyka

  1. Gdy interfejs API jest wywoływany z aplikacji na jednej stronie uruchomionej w przeglądarce lub aplikacji mobilnej, przeglądarka przerwie żądanie, jeśli użytkownik nagle zamknie przeglądarkę, przejdzie na inną stronę na tej samej karcie lub zatrzymać wczytywanie, klikając przestaje się ładować.
  2. W takim przypadku transakcje ze stanem HTTP 499 zazwyczaj się różnią w czasie przetwarzania żądań (Response Time) dla każdego z nich.
  3. Aby ustalić, czy jest to przyczyna, porównaj Czas odpowiedzi i sprawdź, czy jest inny dla każdego z błędów 499 korzystających z monitorowania interfejsu API lub dostępu do NGINX dzienniki zgodnie z opisem w sekcji Typowe kroki diagnostyki.

Rozdzielczość

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

  2. Jeśli często zdarza się to dla tej samej ścieżki adresu URL, być może dany serwer proxy jest powiązane z tą ścieżką bardzo wolno, a użytkownicy nie chcą czekać.

    Gdy już dowiesz się, których serwera proxy może dotyczyć problem, użyj Czas oczekiwania panelu analizy, aby dokładniej zbadać, co powoduje opóźnienie serwera proxy.

    1. W takim przypadku określ serwer proxy, którego dotyczy problem, wykonując czynności opisane w Najczęstsze czynności diagnostyczne.
    2. Użyj instrukcji panel analizy czasu oczekiwania, aby dokładniej zbadać, co powoduje opóźnienie serwera proxy. aby rozwiązać problem.
    3. Jeśli stwierdzisz, że dla konkretnego serwera proxy opóźnienie jest spodziewane, być może , aby poinformować użytkowników, że oczekiwanie na odpowiedź serwera proxy może trochę potrwać.

Przyczyna: limit czasu oczekiwania aplikacji klienckiej

Może się tak zdarzyć w zależności od różnych scenariuszy.

  1. Przetworzenie żądania powinno zająć pewien czas (powiedzmy 10 sekund). w normalnych warunkach. Aplikacja kliencka jest jednak ustawiona na nieprawidłową wartość limit czasu (powiedzmy 5 sekund), który powoduje przekroczenie limitu czasu aplikacji klienckiej przed żądanie do interfejsu API zostało zakończone, co prowadzi do wystąpienia 499. W tym przypadku trzeba ustawić parametr czas oczekiwania klienta do odpowiedniej wartości.
  2. Serwer docelowy lub objaśnienie trwa dłużej niż oczekiwano. W takim przypadku musisz poprawić błąd i odpowiednio dostosować wartości limitu czasu.
  3. Klient nie potrzebuje już odpowiedzi i przerwał. Może się tak zdarzyć w przypadku wysokiej jakości, interfejsów API częstotliwości, takich jak automatyczne uzupełnianie lub krótkie odpytania.

Diagnostyka

Logi dostępu do API Monitoring lub NGINX

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

  1. Sprawdź logi monitorowania API lub logi dostępu NGINX dotyczące transakcji HTTP 499, jak opisano w Najczęstsze czynności diagnostyczne.
  2. Sprawdź, czy czas odpowiedzi jest spójny dla wszystkich błędów typu 499.
  3. Jeśli tak, to może to oznaczać, że konkretna aplikacja kliencka skonfigurowała stały czas oczekiwania po ich stronie. Jeśli serwer proxy lub serwer docelowy interfejsu API odpowiada powoli, klient przekroczy limit czasu przed upływem limitu czasu serwera proxy, co spowoduje duże ilości ruchu HTTP 499s dla tę samą ścieżkę identyfikatora URI. W tym przypadku określ klienta użytkownika z dzienników dostępu NGINX, które może pomóc w określeniu konkretnej aplikacji klienckiej.
  4. Możliwe też, że przed Apigee znajduje się 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, żądanie czas oczekiwania systemu równoważenia obciążenia musi być skonfigurowany tak, aby był większy niż limit czasu Apigee API. Według domyślnie, router Apigee przekracza limit czasu po 57 sekundach, więc można skonfigurować żądanie 60 sekund w systemie równoważenia obciążenia.

Śledzenie

Zdiagnozuj błąd za pomocą śledzenia

Jeśli problem jest nadal aktywny (postępują 499 błędy), wykonaj następujące kroki:

  1. Włącz sesja śledzenia danego interfejsu API w interfejsie Edge.
  2. Zaczekaj na wystąpienie błędu lub, jeśli masz wywołanie interfejsu API, wykonaj kilka wywołań interfejsu API. i powtórzyć błąd.
  3. Sprawdzaj czas, który upłynął w każdej fazie i zanotuj, który etap na reklamę.
  4. Jeśli błąd jest najdłuższy, tuż po jednej z kolejnych fazach, oznacza to, że serwer backendu działa wolno lub zajmuje dużo czasu w celu przetworzenia żądania:
    • Żądanie wysłane do serwera docelowego
    • Zasady dotyczące wywołań usługi

    Oto przykładowy log czasu interfejsu pokazujący Limit czasu bramy po wysłaniu żądania Request wysłane do serwera docelowego:

Rozdzielczość

  1. Patrz: Sprawdzone metody konfigurowania limitu czasu wejścia-wyjścia, które pozwalają określić wartości limitu czasu na różnych komponentach zaangażowanych w przepływ żądania do interfejsu API przez Apigee Edge.
  2. Ustaw odpowiednią wartość limitu czasu dla aplikacji klienckiej zgodnie z za sprawdzone metody.

Jeśli problem nadal występuje, przeczytaj artykuł Wymagane są informacje diagnostyczne .

Musi zbierać informacje diagnostyczne

Jeśli problem nie ustąpi, zbierz poniższe informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge.

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

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

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

  • Pełny komunikat o błędzie zaobserwowany dla nieudanych żądań
  • Nazwa środowiska
  • Pakiet serwera proxy interfejsu API
  • Plik śledzenia żądań do interfejsu API, w przypadku których występują błędy 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)