502 Nieprawidłowa bramka – rozłączenie

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 502 Bad Gateway z kodem ECONNRESET w odpowiedzi na wywołania interfejsu API w Edge Microgateway.

Komunikat o błędzie

Klient zobaczy ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Odpowiedź będzie zawierać ten komunikat o błędzie:

{"message":"socket hang up","code":"ECONNRESET"}

Możliwe przyczyny

Typowe czynności diagnostyczne

1. Sprawdź logi Edge Microgateway:

   /var/tmp/edgemicro-`hostname`-*.log

2. Sprawdź, czy w określonym czasie (jeśli problem wystąpił w przeszłości) lub czy nadal występują błędy 502 z kodem ECONNRESET lub czy nadal występują żądania kończące się niepowodzeniem z kodem 502.

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. Jeśli poziom logowania jest ustawiony na warn lub info, w drugim elemencie pojawi się też komunikat [warn] zawierający nazwę hosta i port serwera docelowego. W tym przykładzie jest to X.X.X.X:8080, którego można później użyć do przechwycenia tcpdump.

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. Kod błędu [socket hang up][ECONNRESET] oznacza, że serwer docelowy zamknął połączenie z Edge Microgateway. Możesz wyszukać ten kod w logach, aby sprawdzić, jak często występuje ten problem.

Przyczyna: nieprawidłowo skonfigurowany limit czasu utrzymywania aktywności

Diagnostyka

1. Wykonaj czynności opisane w sekcji Typowe czynności diagnostyczne i sprawdź, czy wystąpił błąd [socket hang up][ECONNRESET].

2. Jeśli tak, przeprowadź dalszą analizę za pomocą tcpdump w sposób opisany poniżej:

Korzystanie z tcpdump

1. Przechwyć tcpdump między Edge Microgateway a serwerem backendu w systemie operacyjnym hosta Edge Microgateway za pomocą tego polecenia:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. Przeanalizuj przechwycony tcpdump:

   Przykładowe dane wyjściowe tcpdump: ( zobacz większy obraz)

   

   W powyższym przykładzie tcpdump możesz zobaczyć te informacje:

   1. W pakiecie 250288 klient wysyła żądanie POST.
   2. W pakiecie 250371 serwer odpowiada kodem 200 OK.
   3. W pakiecie 250559 klient wysyła ACK.
   4. W pakiecie 250560 serwer wysyła Continuation komunikat.
   5. W pakiecie 250561 klient wysyła ACK.
   6. W pakiecie 262436 serwer wysyła FIN, ACK do klienta, inicjując zamknięcie połączenia. Zwróć uwagę, że następuje to około pięć sekund po poprzednim pakiecie (250561).
   7. W pakiecie 262441 klient wysyła kolejne POST żądanie. Nie udaje się jednak, ponieważ serwer już zainicjował zamknięcie połączenia. W pakiecie 262441 odpowiada RST.

   W tym przykładzie to samo połączenie zostało co najmniej raz użyte z powodzeniem, ale w przypadku ostatniego żądania serwer inicjuje zamknięcie połączenia po 5 sekundach bezczynności, co następuje w tym samym czasie, gdy klient wysłał nowe żądanie. Sugeruje to, że limit czasu utrzymywania aktywności serwera backendu jest prawdopodobnie krótszy lub równy wartości ustawionej na kliencie. Aby to sprawdzić, porównaj limit czasu utrzymywania aktywności w Edge Microgateway i na serwerze backendu.

Porównanie limitów czasu utrzymywania aktywności

1. Edge Microgateway nie ma konkretnej właściwości limitu czasu utrzymywania aktywności. Jest on określany przez system operacyjny, w którym działa. Typowe przykłady to kontenery Windows, Linux i Docker.
2. Możliwe, że jest on dostosowany w systemie operacyjnym. Skontaktuj się z administratorem systemu. Domyślnie systemy operacyjne Linux mają domyślny limit czasu utrzymywania aktywności wynoszący 2 godziny.
3. Następnie sprawdź właściwość limitu czasu utrzymywania aktywności skonfigurowaną na serwerze backendu. Załóżmy, że serwer backendu jest skonfigurowany z wartością 10 sekund.
4. Jeśli stwierdzisz, że wartość limitu czasu utrzymywania aktywności w systemie operacyjnym jest wyższa niż wartość właściwości limitu czasu utrzymywania aktywności na serwerze backendu (jak w powyższym przykładzie), to jest to przyczyna błędów 502.

Rozwiązanie

Upewnij się, że właściwość limitu czasu utrzymywania aktywności w systemie operacyjnym, w którym działa Edge Microgateway, jest zawsze niższa niż na serwerze backendu.

1. Określ wartość ustawioną dla limitu czasu utrzymywania aktywności na serwerze backendu.
2. Skonfiguruj odpowiednią wartość właściwości limitu czasu utrzymywania aktywności w systemie operacyjnym, tak aby była ona niższa niż wartość ustawiona na serwerze backendu. Wykonaj czynności odpowiednie dla Twojego systemu operacyjnego.

Sprawdzona metoda

Zdecydowanie zalecamy, aby komponenty podrzędne miały zawsze niższy próg limitu czasu utrzymywania aktywności niż skonfigurowany na serwerach nadrzędnych, aby uniknąć tego rodzaju wyścigów i 502 błędów. Każdy przeskok podrzędny powinien być niższy niż każdy przeskok nadrzędny. W Edge Microgateway zalecamy stosowanie tych wskazówek:

1. Limit czasu utrzymywania aktywności w aplikacji klienckiej lub narzędziu do równoważenia obciążenia powinien być krótszy niż limit czasu utrzymywania aktywności w Edge Microgateway.

   Aby skonfigurować limit czasu utrzymywania aktywności w Edge Microgateway, dodaj keep_alive_timeout wartość do swojego ~/.edgemicro/org-env-config.yaml pliku.

   edgemicro:
     keep_alive_timeout: 65000

2. Limit czasu utrzymywania aktywności w systemie operacyjnym Edge Microgateway powinien być krótszy niż limit czasu utrzymywania aktywności na serwerze docelowym.
3. Jeśli masz inne przeskoki przed lub za Edge Microgateway, należy zastosować tę samą regułę. Zawsze należy pozostawić klientowi podrzędnemu odpowiedzialność za zamknięcie połączenia z serwerem nadrzędnym.

Przyczyna: serwer docelowy przedwcześnie zamyka połączenie

Diagnostyka

1. Wykonaj czynności opisane w sekcji Typowe czynności diagnostyczne i sprawdź, czy wystąpił błąd [socket hang up][ECONNRESET].
2. Jeśli tak, przeprowadź dalszą analizę za pomocą tcpdump w sposób opisany poniżej.

   Komunikat o błędzie [targetRequest error][GET][][socket hang up][ECONNRESET] w powyższym przykładzie wskazuje, że ten błąd wystąpił, gdy Edge Microgateway wysyłał żądanie do serwera backendu (docelowego). Oznacza to, że Edge Microgateway wysłał żądanie do interfejsu API do serwera backendu i czekał na odpowiedź. Serwer backendu nagle zakończył jednak połączenie, zanim Edge Microgateway otrzymał odpowiedź.

3. Sprawdź logi serwera backendu i zobacz, czy występują w nich błędy lub informacje, które mogły spowodować nagłe zakończenie połączenia przez serwer backendu. Jeśli znajdziesz jakieś błędy lub informacje, przejdź do sekcji Rozwiązanie i odpowiednio rozwiąż problem na serwerze backendu.
4. Jeśli na serwerze backendu nie znajdziesz żadnych błędów ani informacji, zbierz dane wyjściowe tcpdump na serwerze Edge Microgateway:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. Przeanalizuj przechwycony tcpdump:

   Przykładowe dane wyjściowe tcpdump: ( zobacz większy obraz)

   

   W powyższym przykładzie tcpdump możesz zobaczyć te informacje:

   1. W pakiecie 4 Edge Microgateway wysłał żądanie GET do serwera docelowego serwera.
   2. W pakiecie 5 serwer docelowy odpowiedział ACK, aby potwierdzić żądanie.
   3. Jednak w pakiecie 6 serwer docelowy zamiast odpowiedzieć ładunkiem odpowiedzi wysyła FIN, ACK, inicjując zamknięcie połączenia.
   4. W pakietach 7 i kolejnych połączenie jest zamykane wzajemnie. Ponieważ połączenie zostało zamknięte przed wysłaniem odpowiedzi, Edge Microgateway zwróci klientowi błąd HTTP 502 error back to the client.
   5. Zwróć uwagę, że sygnatura czasowa pakietu 8, 2021-06-23T03:52:24.110Z odpowiada sygnaturze czasowej, w której błąd został zarejestrowany w logach Edge Microgateway. Sygnatury czasowe w plikach dzienników i w tcpdump często można wykorzystać do powiązania błędów z rzeczywistymi pakietami.

   Rozwiązanie

   Odpowiednio rozwiąż problem na serwerze backendu.

   Jeśli problem nadal występuje i potrzebujesz pomocy w rozwiązaniu problemu z 502 Bad Gateway Error lub podejrzewasz, że problem występuje w Edge Microgateway, przejdź do Informacje diagnostyczne, które musisz zebrać.

   Informacje diagnostyczne, które musisz zebrać

   Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge:

   • Pliki dzienników: domyślny folder to /var/tmp, ale można go zastąpić w głównym pliku config.yaml (logging > dir parameter). Przed przekazaniem plików dzienników zespołowi pomocy Apigee zalecamy zmianę ustawienia log > level na info.
   • Plik konfiguracyjny: główna konfiguracja Edge Microgateway znajduje się w pliku YAML w domyślnym folderze Edge Microgateway, $HOME/.edgemicro. Dostępny jest domyślny plik konfiguracyjny o nazwie default.yaml oraz plik konfiguracyjny dla każdego środowiska ORG-ENV-config.yaml. Prześlij ten plik w całości w przypadku organizacji i środowiska, których dotyczy problem.