502 Nieprawidłowa bramka – rozłączenie

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 502 Bad Gateway z parametrem kod ECONNRESET jako odpowiedź na wywołania interfejsu API w Edge Microgateway.

Komunikat o błędzie

Klient zobaczy następujący 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 czas utrzymywania aktywności Czasy utrzymywania aktywności są nieprawidłowo skonfigurowane między Edge Microgateway a serwerem docelowym. Użytkownicy chmury publicznej i prywatnej Edge
Serwer docelowy przedwcześnie zamyka połączenie Serwer docelowy przedwcześnie zamyka połączenie, gdy trwa wysyłanie Edge Microgateway do ładunku żądania. Użytkownicy chmury publicznej i prywatnej Edge

Typowe kroki diagnostyki

  1. Sprawdź logi Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Wyszukaj błędy (502) z kodem ECONNRESET w określonym czasie (jeśli problem wystąpił w przeszłości) lub jeśli są jakieś żądania. nadal występują błędy z użyciem funkcji 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, zostanie też musi być komunikatem [warn] zawierającym nazwę hosta serwera docelowego i port w drugiej . W tym przykładzie jest to X.X.X.X:8080 i można go użyć. później, aby zarejestrować 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 Zakończył połączenie z Edge Microgateway. Można to przeszukać w dziennikach, aby określić jak często to ma miejsce.

Przyczyna: nieprawidłowo skonfigurowany czas utrzymywania aktywności

Diagnostyka

  1. Wykonaj czynności opisane w Najczęstszych krokach diagnostyki i sprawdź, czy otrzymujesz [socket hang up][ECONNRESET] błąd.

  2. Jeśli tak, przeanalizuj dokładniej, korzystając z pomocy tcpdump, jak wyjaśniliśmy poniżej:

Korzystanie z tcpdump

  1. Przechwyć interfejs tcpdump między Edge Microgateway a serwerem backendu na systemu operacyjnego hosta Edge Microgateway za pomocą następującego polecenia: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Przeanalizuj przechwycone dane (tcpdump):

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

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

    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 Continuation .
    5. W pakiecie 250561 klient wysyła ACK.
    6. W pakiecie 262436 serwer wysyła FIN, ACK do inicjujący zamknięcie połączenia przez klienta. To około pięć. sekund po poprzednim pakiecie (250561).
    7. W pakiecie 262441 klient wysyła kolejne POST użytkownika. Jednak to się nie uda, ponieważ serwer już zainicjował zamknięcie połączenia. Wysyła odpowiedź RST w pakiecie 262441.

    W tym przykładzie to samo połączenie zostało użyte co najmniej raz, ale w dniu po przesłaniu ostatniego żądania serwer inicjuje zamknięcie połączenia po pięciu sekundach. czasu bezczynności, czyli w tym samym czasie, w którym klient wysłał nowe żądanie. Ten wskazuje, że limit czasu utrzymywania aktywności serwera backendu będzie najprawdopodobniej krótszy lub równy wartość ustawiona w kliencie. Aby to sprawdzić, zobacz Porównaj limity czasu utrzymywania aktywności na Edge Microgateway i na serwerze backendu.

Porównaj limity czasu utrzymywania aktywności

  1. Edge Microgateway nie ma konkretnej właściwości czasu utrzymywania aktywności. Jest zależy od systemu operacyjnego, w którym został uruchomiony. Typowe przykłady to Windows, kontenery Linuxa i Dockera.
  2. Możliwe, że ta funkcja jest dostosowana w systemie operacyjnym. Sprawdź w administratora systemu. Domyślnie systemy operacyjne Linux mają domyślne ustawienia utrzymywania aktywności limit czasu wynosi dwie godziny.
  3. Następnie sprawdź właściwość limitu czasu utrzymywania aktywności skonfigurowaną na serwerze backendu. Zaczynajmy tzn. serwer backendu jest skonfigurowany z wartością 10 sekund.
  4. Jeśli ustalisz, że wartość limitu czasu utrzymywania aktywności w systemie operacyjnym wynosi jest większa niż wartość właściwości limitu czasu utrzymywania aktywności na serwerze backendu, tak jak w tagu powyższego przykładu, to to jest przyczyną 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 Edge Usługa Microgate działa w porównaniu z działaniem 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 operacji , tak by właściwość limitu czasu utrzymywania aktywności była krótsza niż wartość ustawiona w backendzie. serwera, wykonując czynności odpowiednie dla Twojego systemu operacyjnego.

Sprawdzona metoda

Zdecydowanie zalecamy, aby komponenty podrzędne miały zawsze krótszy limit czasu utrzymywania aktywności niż określony na serwerach nadrzędnych, aby uniknąć tego rodzaju wyścigów 502 błędu. Każdy przeskok w dół powinien być mniejszy niż każdy przeskok nadrzędny. W Edge Microgateway, warto zastosować się do tych wskazówek:

  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 parametr keep_alive_timeout na ~/.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ż wartość docelowa limit czasu utrzymywania aktywności serwera.
  3. Jeśli masz inne przeskoki przed lub za Edge Microgateway, ta sama reguła powinna można zastosować. Odpowiedzialność za zamknięcie usługi należy zawsze pozostawiać na koncie klienta podrzędnego. połączenia z nadrzędnym.
.

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

Diagnostyka

  1. Wykonaj czynności opisane w sekcji Typowe kroki diagnostyki i sprawdź, czy wystąpił błąd [socket hang up][ECONNRESET].
  2. Jeśli tak, sprawdź dokładniej, korzystając z pomocy tcpdump, zgodnie z opisem 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ł podczas korzystania z Edge Microgateway wysyłał żądanie do serwera backendu (docelowego). Oznacza to, że Edge Microgateway wysłał Żądanie do interfejsu API wysłane do serwera backendu i oczekiwanie na odpowiedź. Backend Serwer nagle zakończył połączenie przed otrzymaniem odpowiedzi Edge Microgateway.

  3. Sprawdź w dziennikach serwera backendu, czy są w nim błędy lub informacje, które mogą skłoniły serwer backendu do nagłego zakończenia połączenia. Jeśli znajdziesz błędy lub , a następnie kliknij Rozwiązanie i odpowiednio rozwiąż problem. na serwerze backendu.
  4. Jeśli na serwerze backendu nie ma żadnych błędów ani informacji, zbierz Dane wyjściowe funkcji tcpdump na serwerze Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Przeanalizuj przechwycone dane (tcpdump):

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

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

    1. W pakiecie 4 usługa Edge Microgateway wysłała żądanie GET do miejsca docelowego serwera.
    2. W pakiecie 5 serwer docelowy odpowiedział żądaniem ACK, aby potwierdzić użytkownika.
    3. Jednak w pakiecie 6 zamiast wysłać odpowiedź ładunkiem odpowiedzi, docelowy Serwer wysyła komunikat FIN, ACK, inicjując zamknięcie połączenia.
    4. W pakietach 7 i nowszych połączenie jest zamykane wzajemnie. Ponieważ połączenie zamknięta przed wysłaniem odpowiedzi, Edge Microgateway zwróci żądanie HTTP 502 z komunikatem o błędzie.
    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 Edge Microgateway dzienników. Sygnatury czasowe w plikach dziennika i w pliku tcpdump mogą często w celu skorelowania błędów z rzeczywistymi pakietami.

    Rozdzielczość

    Napraw problem na serwerze backendu.

    Jeśli problem będzie się powtarzał i będziesz potrzebować pomocy w jego rozwiązaniu, 502 Bad Gateway Error lub podejrzewasz, że problem dotyczy Edge Microgateway, wejdź na Wymagane jest zbieranie informacji diagnostycznych.

    Musi zbierać informacje diagnostyczne

    Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zwróć uwagę na informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge:

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