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
- Sprawdź logi Edge Microgateway:
/var/tmp/edgemicro-`hostname`-*.log
- Sprawdź, czy w danym okresie wystąpiły jakieś błędy
502
z kodemECONNRESET
(jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z502
.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][]
- Jeśli poziom logowania jest ustawiony na
warn
lubinfo
, pojawi się też komunikat[warn]
z nazwą hosta serwera docelowego i portem w drugim elemencie. W tym przykładzie jest toX.X.X.X:8080
, którego można później użyć do przechwytywaniatcpdump
.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]
- 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
- Wykonaj czynności opisane w artykule Typowe czynności diagnostyczne, aby sprawdzić, czy wystąpił błąd
[socket hang up][ECONNRESET]
. Jeśli tak, zbadaj dokładniej dane za pomocą narzędzia
tcpdump
w sposób opisany poniżej:
Korzystanie z tcpdump
- 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
- 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:- W pakiecie 250288 klient wysyła żądanie
POST
. - W pakiecie 250371 serwer odpowiada
200 OK
. - W pakiecie 250559 klient wysyła
ACK.
- W pakiecie 250560 serwer wysyła komunikat
Continuation
. - W pakiecie 250561 klient wysyła
ACK.
- 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). - W pakiecie 262441 klient wysyła kolejne żądanie
POST
. Ta czynność się jednak nie uda, ponieważ serwer zainicjował już zamknięcie połączenia. Odpowiada onRST
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.
- W pakiecie 250288 klient wysyła żądanie
Porównanie limitów czasu utrzymywania aktywności
- 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.
- 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.
- 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.
- 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.
- Określ wartość limitu czasu utrzymywania aktywności na serwerze backendu.
- 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:
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
- Limit czasu utrzymywania aktywności systemu operacyjnego Edge Microgateway powinien być krótszy niż limit czasu utrzymywania aktywności serwera docelowego.
- 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
- Wykonaj czynności opisane w sekcji Typowe czynności diagnostyczne, aby sprawdzić, czy wystąpił błąd
[socket hang up][ECONNRESET]
. - 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ź. - 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.
- 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
- 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:- W pakiecie 4 Edge Microgateway wysłała żądanie
GET
do serwera docelowego. - W pakiecie 5 serwer docelowy wysłał odpowiedź
ACK
, aby potwierdzić żądanie. - Jednak w pakiecie 6, zamiast odpowiadać ładunkiem odpowiedzi, serwer docelowy wysyła
FIN, ACK
, inicjując zamknięcie połączenia. - 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
. - 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 plikutcpdump
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 plikuconfig.yaml
(logging > dir parameter
). Zalecamy zmianęlog > level
nainfo
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 konfiguracyjnydefault.yaml
, a następnie jeden dla każdego środowiskaORG-ENV-config.yaml
. Prześlij w całości ten plik dla organizacji i środowiska, których dotyczy problem.
- W pakiecie 4 Edge Microgateway wysłała żądanie