502 Nieprawidłowa bramka – rozłączenie

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

Krótki opis problemu

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

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

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Nieprawidłowo skonfigurowany limit czasu utrzymywania aktywności Limit czasu utrzymywania aktywności został skonfigurowany nieprawidłowo między Edge Microgateway a serwerem docelowym. Użytkownicy chmury publicznej i prywatnej usługi Edge
Serwer docelowy przedwcześnie zamyka połączenie Serwer docelowy przedwcześnie zamyka połączenie, gdy Edge Microgateway wysyła ładunek żądania. Użytkownicy chmury publicznej i prywatnej usługi Edge

Najczęstsze kroki diagnostyki

  1. Sprawdź logi Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Sprawdź, czy w danym okresie wystąpiły jakieś błędy 502 z kodem ECONNRESET (jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 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, pojawi się też komunikat [warn] z nazwą hosta serwera docelowego i portem w drugim elemencie. W tym przykładzie jest to X.X.X.X:8080, którego można później użyć do przechwytywania 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] wskazuje, że serwer docelowy zamknął połączenie z Edge Microgateway. Możesz to wyszukać w logach, aby określić, jak często występuje.

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

Diagnostyka

  1. Wykonaj czynności opisane w artykule Typowe czynności diagnostyczne, aby sprawdzić, czy wystąpił błąd [socket hang up][ECONNRESET].

  2. Jeśli tak, zbadaj dokładniej dane za pomocą narzędzia 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 zarejestrowane dane (tcpdump):

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

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

    1. W pakiecie 250288 klient wysyła żądanie POST.
    2. W pakiecie 250371 serwer odpowiada 200 OK.
    3. W pakiecie 250559 klient wysyła ACK.
    4. W pakiecie 250560 serwer wysyła komunikat Continuation.
    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 zajmuje to około 5 sekund po poprzednim pakiecie (250561).
    7. W pakiecie 262441 klient wysyła kolejne żądanie POST. Ta czynność się jednak nie uda, ponieważ serwer zainicjował już zamknięcie połączenia. Odpowiada on RST w pakiecie 262441.

    W tym przykładzie to samo połączenie zostało ponownie użyte co najmniej raz, ale w ostatnim żądaniu serwer inicjuje zamknięcie połączenia po 5 sekundach bezczynności, czyli w tym samym momencie, w którym 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 w kliencie. Informacje na ten temat znajdziesz w artykule o porównywaniu limitu czasu utrzymywania aktywności na Edge Microgateway i na serwerze backendu.

Porównanie limitów czasu utrzymywania aktywności

  1. Edge Microgateway nie ma określonej właściwości limitu czasu utrzymywania aktywności. Zależy to od systemu operacyjnego, w którym jest uruchomiony. Typowe przykłady to kontenery Windows, Linux i Dockera.
  2. Możliwe, że opcja ta została dostosowana w systemie operacyjnym. Skontaktuj się z administratorem systemu. Domyślnie w systemach operacyjnych Linux domyślny limit czasu utrzymywania aktywności wynosi 2 godziny.
  3. Następnie sprawdź właściwość limitu czasu utrzymywania aktywności skonfigurowaną na serwerze backendu. Załóżmy, że Twój serwer backendu jest skonfigurowany z wartością 10 sekund.
  4. Jeśli ustalisz, ż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.

Rozdzielczość

Sprawdź, czy właściwość limitu czasu utrzymywania aktywności jest zawsze niższa w systemie operacyjnym, w którym działa Edge Microgateway, w porównaniu z tym na serwerze backendu.

  1. Określ wartość 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, wykonując czynności odpowiednie dla Twojego systemu operacyjnego.

Sprawdzona metoda

Zdecydowanie zalecamy, aby komponenty pobierania danych zawsze miały niższy próg limitu czasu utrzymywania aktywności niż skonfigurowany na serwerach nadrzędnych. Pozwoli to uniknąć tego typu problemów podczas wyścigu i błędów 502. Każdy przeskok w dół powinien być niższy niż każdy przeskok z klienta na serwer. W Edge Microgateway zalecamy postępowanie zgodnie z tymi wytycznymi:

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

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

    edgemicro:
  keep_alive_timeout: 65000
  2. Limit czasu utrzymywania aktywności systemu operacyjnego Edge Microgateway powinien być krótszy niż limit czasu utrzymywania aktywności serwera docelowego.
  3. Jeśli masz inne przeskoki przed lub za Edge Microgateway, należy zastosować tę samą regułę. Za zamknięcie połączenia z hostem wychodzącym zawsze należy zostawić klienta odbierającego.

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

Diagnostyka

  1. Wykonaj czynności opisane w sekcji Typowe czynności diagnostyczne, aby sprawdzić, czy wystąpił błąd [socket hang up][ECONNRESET].
  2. Jeśli tak, zbadaj sprawę dalej z pomocą firmy tcpdump w sposób opisany poniżej.

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

  3. Sprawdź logi serwera backendu, aby zobaczyć, czy występują jakieś błędy lub informacje, które mogły skłoniły serwer backendu do nagłego zakończenia połączenia. Jeśli znajdziesz błędy lub informacje, przejdź do sekcji Rozwiązanie i napraw problem na swoim serwerze backendu.
  4. Jeśli nie znajdziesz żadnych błędów ani informacji na serwerze backendu, zbierz dane wyjściowe tcpdump na serwerze Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Przeanalizuj zarejestrowane dane (tcpdump):

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

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

    1. W pakiecie 4 Edge Microgateway wysłała żądanie GET do serwera docelowego.
    2. W pakiecie 5 serwer docelowy wysłał odpowiedź ACK, aby potwierdzić żądanie.
    3. Jednak w pakiecie 6, zamiast odpowiadać ładunkiem odpowiedzi, serwer docelowy wysyła FIN, ACK, inicjując zamknięcie połączenia.
    4. W kolejnych pakietach od 7 połączenie jest zamykane wzajemnie. Ponieważ połączenie zostało zamknięte przed wysłaniem odpowiedzi, Edge Microgateway zwraca klientowi błąd HTTP 502.
    5. Zauważ, że sygnatura czasowa pakietu 8, 2021-06-23T03:52:24.110Z odpowiada sygnaturze czasowej, w której został zarejestrowany błąd w logach Edge Microgateway. Sygnatury czasowe w plikach logu i w pliku tcpdump mogą często służyć do korelowania błędów z rzeczywistymi pakietami.

    Rozdzielczość

    Napraw problem na serwerze backendu.

    Jeśli problem nie ustąpi i potrzebujesz pomocy w rozwiązaniu problemu z 502 Bad Gateway Error lub podejrzewasz, że jest on związany z Edge Microgateway, zapoznaj się z sekcją Wymagane jest zbieranie informacji diagnostycznych.

    Musisz zebrać informacje diagnostyczne

    Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge:

    • Pliki dziennika: domyślny folder to /var/tmp, ale może on zostać zastąpiony w głównym pliku config.yaml (logging > dir parameter). Zalecamy zmianę log > level na info przed przekazaniem plików logu do zespołu pomocy Apigee.
    • Plik konfiguracji: główna konfiguracja Edge Microgateway znajduje się w pliku YAML w domyślnym folderze Edge Microgateway $HOME/.edgemicro. Istnieje domyślny plik konfiguracyjny default.yaml, a następnie jeden dla każdego środowiska ORG-ENV-config.yaml. Prześlij w całości ten plik dla organizacji i środowiska, których dotyczy problem.