Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Krótki opis problemu
Aplikacja kliencka otrzymuje kod stanu HTTP 502
z komunikatem Bad Gateway
w odpowiedzi na wywołania interfejsu API.
Kod stanu HTTP 502
oznacza, że klient nie otrzymuje prawidłowej odpowiedzi z serwerów backendu, które powinny zrealizować żądanie.
Komunikaty o błędach
Aplikacja kliencka otrzymuje ten kod odpowiedzi:
HTTP/1.1 502 Bad Gateway
Oprócz tego może pojawić się ten komunikat o błędzie:
{ "fault": { "faultstring": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Możliwe przyczyny
Jedną z typowych przyczyn błędu 502 Bad Gateway Error
jest błąd Unexpected EOF
, który może mieć te przyczyny:
Przyczyna | Szczegóły | Kroki podane dla |
---|---|---|
Nieprawidłowo skonfigurowany serwer docelowy | Serwer docelowy nie jest prawidłowo skonfigurowany do obsługi połączeń TLS/SSL. | Użytkownicy chmury publicznej i prywatnej usługi Edge |
Wyjątek EOFWyjątek z serwera backendu | Serwer backendu może nagle wysłać EOF. | Tylko użytkownicy chmury Edge Private Cloud |
Nieprawidłowo skonfigurowany limit czasu utrzymywania aktywności | Utrzymuj nieprawidłowo skonfigurowane limity czasu aktywności na Apigee i na serwerze backendu. | Użytkownicy chmury publicznej i prywatnej usługi Edge |
Najczęstsze kroki diagnostyki
Aby zdiagnozować błąd, możesz użyć dowolnej z następujących metod:
Monitorowanie interfejsów API
Aby zdiagnozować błąd za pomocą monitorowania interfejsu API:
Za pomocą Monitorowania interfejsów API możesz badać błędy 502
, wykonując czynności opisane w sekcji Badanie problemów. Czyli:
- Otwórz panel Zbadaj.
- Wybierz Kod stanu z menu i sprawdź, czy w przypadku wystąpienia błędów
502
został wybrany właściwy okres. - Jeśli widzisz dużą liczbę błędów
502
, kliknij pole w tabeli. - Po prawej stronie kliknij Wyświetl logi obok błędów
502
, które wyglądają mniej więcej tak: - Źródło błędu:
target
- Kod błędu:
messaging.adaptors.http.UnexpectedEOFAtTarget
Znajdują się tu następujące informacje:
Oznacza to, że błąd 502
jest spowodowany przez cel z powodu nieoczekiwanego zakończenia operacji.
Oprócz tego zanotuj Request Message ID
związany z błędem 502
, aby umożliwić dalszą analizę.
Narzędzie do śledzenia
Aby zdiagnozować błąd za pomocą narzędzia do śledzenia:
- Włącz
sesję śledzenia i wykonaj wywołanie interfejsu API, aby odtworzyć problem
502 Bad Gateway
. - Wybierz 1 z nieudanych żądań i sprawdź log czasu.
- Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.
-
Błąd powinien pojawić się po wysłaniu żądania do serwera docelowego, jak pokazano poniżej:
-
Ustal wartość X-Apigee.fault-source i X-Apigee.fault-code na fazie AX (rejestrowane dane Analytics) w logu czasu.
Jeśli wartości X-Apigee.fault-source i X-Apigee.fault-code są zgodne z wartościami podanymi w poniższej tabeli, możesz sprawdzić, czy błąd
502
pochodzi z serwera docelowego:Nagłówki odpowiedzi Wartość X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Oprócz tego zanotuj
X-Apigee.Message-ID
związany z błędem502
, aby ułatwić dalszą analizę.
Logi dostępu NGINX
Aby zdiagnozować błąd przy użyciu NGINX:
Aby ustalić przyczynę kodu stanu 502
, możesz też sprawdzić logi dostępu NGINX. Jest to szczególnie przydatne, jeśli problem występował w przeszłości lub występuje sporadycznie i nie możesz przechwycić logu czasu w interfejsie użytkownika. Aby określić te informacje w logach dostępu NGINX, wykonaj te czynności:
- Sprawdź logi dostępu do NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Wyszukaj błędy
502
dotyczące konkretnego serwera proxy interfejsu API w danym okresie (jeśli problem występował w przeszłości) lub jakiekolwiek żądania, które nadal kończą się niepowodzeniem z502
. - Jeśli wystąpiły błędy
502
, sprawdź, czy błąd jest spowodowany przez cel wysyłający sygnałUnexpected EOF
. Jeśli wartości X-Apigee.fault-source i X- Apigee.fault-code są zgodne z wartościami podanymi w tabeli poniżej, błąd502
jest spowodowany nieoczekiwanym zamykaniem połączenia przez cel:Nagłówki odpowiedzi Wartość X-Apigee.fault-source target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Oto przykładowy wpis przedstawiający błąd
502
spowodowany przez serwer docelowy:
Oprócz tego zanotuj identyfikatory wiadomości dla błędów 502
, aby umożliwić dalszą analizę.
Przyczyna: nieprawidłowo skonfigurowany serwer docelowy
Serwer docelowy nie jest prawidłowo skonfigurowany do obsługi połączeń TLS/SSL.
Diagnostyka
- Użyj monitorowania interfejsów API, narzędzia do śledzenia lub logów dostępu NGINX, aby określić identyfikator komunikatu, kod błędu i źródło błędu
502
. - Włącz w interfejsie użytkownika log czasu interfejsu API, którego dotyczy problem.
- Jeśli śledzenie nieudanego żądania do interfejsu API wygląda tak:
- Błąd
502 Bad Gateway
pojawia się natychmiast po rozpoczęciu żądania przepływu docelowego. error.class
wyświetlamessaging.adaptors.http.UnexpectedEOF.
W takim przypadku bardzo prawdopodobne jest, że ten problem jest spowodowany nieprawidłową konfiguracją serwera docelowego.
- Błąd
- Uzyskaj definicję serwera docelowego przy użyciu wywołania interfejsu Edge Management API:
- Jeśli jesteś użytkownikiem chmury publicznej, użyj tego interfejsu API:
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Jeśli jesteś użytkownikiem Private Cloud, użyj tego interfejsu API:
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Przykładowa definicja błędu
TargetServer
:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Jeśli jesteś użytkownikiem chmury publicznej, użyj tego interfejsu API:
-
Ilustracja
TargetServer
przedstawia przykład jednego z typowych błędów konfiguracji, który został wyjaśniony w ten sposób:Załóżmy, że serwer docelowy
mocktarget.apigee.net
jest skonfigurowany tak, aby akceptować połączenia bezpieczne (HTTPS) przez port443
. W definicji serwera docelowego nie ma jednak innych atrybutów/flag, które wskazują, że serwer docelowy jest przeznaczony do bezpiecznych połączeń. Sprawi to, że Edge będzie traktować żądania interfejsu API wysyłane do określonego serwera docelowego jako żądania HTTP (niezabezpieczone). Edge nie zainicjuje procesu uzgadniania połączenia SSL z tym serwerem docelowym.Serwer docelowy jest skonfigurowany do przyjmowania tylko żądań HTTPS (SSL) z
443
, dlatego odrzuci żądania z Edge lub zamknie połączenie. W związku z tym w procesorze wiadomości pojawi się błądUnexpectedEOFAtTarget
. Podmiot przetwarzający wiadomości wyśle klientowi odpowiedź502 Bad Gateway
.
Rozdzielczość
Zawsze upewnij się, że serwer docelowy jest prawidłowo skonfigurowany zgodnie z Twoimi wymaganiami.
W przykładzie powyżej, jeśli chcesz wysyłać żądania do bezpiecznego serwera docelowego (HTTPS/SSL), musisz dodać atrybuty SSLInfo
z flagą enabled
ustawioną na true
. Atrybuty SSLInfo
serwera docelowego można dodawać w samej definicji docelowego punktu końcowego, ale zalecamy dodanie atrybutów SSLInfo
do definicji serwera docelowego, aby uniknąć niejasności.
- Jeśli usługa backendu wymaga jednokierunkowej komunikacji SSL:
- Musisz włączyć TLS/SSL w definicji
TargetServer
, dodając atrybutySSLInfo
, w których flagaenabled
ma wartość Prawda, jak pokazano poniżej:<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Jeśli chcesz zweryfikować certyfikat serwera docelowego w Edge, musisz też uwzględnić magazyn zaufania (zawierający certyfikat serwera docelowego) jak poniżej:
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- Musisz włączyć TLS/SSL w definicji
- Jeśli usługa backendu wymaga dwukierunkowej komunikacji SSL:
- Musisz mieć atrybuty
SSLInfo
z odpowiednio ustawionymi flagamiClientAuthEnabled
,Keystore
,KeyAlias
iTruststore
, jak pokazano poniżej:<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- Musisz mieć atrybuty
Odniesienia
Równoważenie obciążenia między serwerami backendu
Przyczyna: wyjątek EOFEx z serwera backendu
Serwer backendu może nagle wysłać EOF (koniec pliku).
Diagnostyka
- Użyj monitorowania interfejsów API, narzędzia do śledzenia lub logów dostępu NGINX, aby określić identyfikator komunikatu, kod błędu i źródło błędu
502
. - Sprawdź logi procesora wiadomości (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) i wyszukaj elementyeof unexpected
dla określonego interfejsu API lub czy masz unikalny identyfikatormessageid
dla żądania do interfejsu API, możesz go wyszukać.Przykładowy zrzut stosu wyjątków z logu procesora wiadomości
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
W powyższym przykładzie widać, że podczas próby odczytania odpowiedzi z serwera backendu wystąpił błąd
java.io.EOFException: eof unexpected
. Ten wyjątek wskazuje koniec pliku (EOF) lub nieoczekiwanie zakończyło się koniec strumienia.Oznacza to, że podmiot przetwarzający wiadomości wysłał żądanie interfejsu API do serwera backendu i oczekiwał lub odczytał odpowiedź. Jednak serwer backendu nagle przerwał połączenie, zanim procesor wiadomości otrzymał odpowiedź lub mógł odczytać pełną 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 jakieś błędy lub informacje, przejdź do sekcji Rozwiązanie i napraw problem na serwerze backendu.
- Jeśli na serwerze backendu nie znajdziesz żadnych błędów ani informacji, zbierz dane wyjściowe
tcpdump
z procesorów do przetwarzania wiadomości:- Jeśli Twój host serwera backendu ma jeden adres IP, użyj tego polecenia:
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Jeśli Twój host serwera backendu ma wiele adresów IP, użyj tego polecenia:
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
Przyczyną tego błędu jest zwykle to, że serwer backendu odpowiada poleceniem
[FIN,ACK]
, gdy tylko procesor wiadomości wyśle żądanie do serwera backendu.
- Jeśli Twój host serwera backendu ma jeden adres IP, użyj tego polecenia:
-
Przeanalizuj ten przykład
tcpdump
.Przykładowy plik
tcpdump
wykonany, gdy wystąpiło502 Bad Gateway Error
(UnexpectedEOFAtTarget
) - W wyniku TCPDump zauważysz taką sekwencję zdarzeń:
- W pakiecie
985
procesor wiadomości wysyła żądanie API do serwera backendu. - W pakiecie
986
serwer backendu natychmiast odpowiada, wysyłając[FIN,ACK]
. - W pakiecie
987
procesor wiadomości wysyła do serwera backendu żądanie[FIN,ACK]
. - Ostatecznie połączenia zostały zamknięte za pomocą
[ACK]
i[RST]
po obu stronach. - Ponieważ serwer backendu wysyła
[FIN,ACK]
, otrzymujesz wyjątekjava.io.EOFException: eof unexpected
w procesorze wiadomości.
- W pakiecie
- Może się tak zdarzyć, jeśli na serwerze backendu wystąpi problem z siecią. Zaangażuj zespół operacyjny ds. sieci, aby dokładniej zbadał ten problem.
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, skontaktuj się z zespołem pomocy Apigee Edge.
Przyczyna: nieprawidłowo skonfigurowany limit czasu utrzymywania aktywności
Zanim dowiesz się, czy jest to przyczyna błędów 502
, zapoznaj się z poniższymi pojęciami.
Stałe połączenia w Apigee
Apigee domyślnie (oraz zgodnie ze standardem HTTP/1.1) podczas komunikacji z docelowym serwerem backendu używa trwałych połączeń. Stałe połączenia mogą zwiększyć wydajność, umożliwiając ponowne wykorzystanie już nawiązanego połączenia TCP i (jeśli jest to możliwe) połączenia TLS/SSL, co zmniejsza obciążenia związane z opóźnieniami. Czas, przez jaki połączenie musi być utrzymywane, jest określany za pomocą limitu czasu utrzymywania aktywności (keepalive.timeout.millis
) właściwości.
Zarówno serwer backendu, jak i procesor wiadomości Apigee utrzymują limity czasu aktywności, aby utrzymywać otwarte połączenia. Gdy po upływie limitu czasu utrzymywania aktywności nie otrzymano żadnych danych, serwer backendu lub podmiot przetwarzający wiadomości może zakończyć połączenie.
Serwery proxy interfejsów API wdrożone w procesorze wiadomości w Apigee mają domyślnie ustawiony limit czasu utrzymywania aktywności na 60s
, chyba że zostanie zastąpiony. Gdy nie otrzyma żadnych danych dla 60s
, Apigee zamknie połączenie z serwerem backendu. Serwer backendu będzie utrzymywać limit czasu utrzymywania aktywności, a po jego wygaśnięciu serwer backendu zamknie połączenie z procesorem wiadomości.
Konsekwencje nieprawidłowej konfiguracji limitu czasu utrzymywania aktywności
Jeśli Apigee lub serwer backendu są skonfigurowane z nieprawidłowymi limitami czasu utrzymywania aktywności, powoduje to sytuację wyścigu, w wyniku której serwer backendu wysyła nieoczekiwany End Of File
(FIN)
w odpowiedzi na żądanie zasobu.
Jeśli na przykład limit czasu utrzymywania aktywności jest skonfigurowany w serwerze proxy interfejsu API lub procesorze wiadomości z wartością większą niż lub równą limitowi czasu oczekiwania nadrzędnego serwera backendu, może wystąpić poniższy warunek wyścigu. Oznacza to, że jeśli podmiot przetwarzający wiadomości nie otrzyma żadnych danych do momentu, gdy będzie bardzo bliski osiągnięcia limitu czasu utrzymywania aktywności serwera backendu, żądanie nadejdzie i zostanie wysłane do serwera backendu przy użyciu istniejącego połączenia. Może to prowadzić do wystąpienia błędu 502 Bad Gateway
z powodu nieoczekiwanego błędu EOF, jak opisano poniżej:
- Załóżmy, że limit czasu utrzymywania aktywności ustawiony w procesorze wiadomości i na serwerze backendu wynosi 60 sekund, a nowe żądanie nie nadeszło do 59 sekund od momentu, gdy poprzednie żądanie zostało obsłużone przez określony podmiot przetwarzający wiadomości.
- Podmiot przetwarzający wiadomości przechodzi dalej, przetwarzając żądanie wysłane w 59 sekundzie, korzystając z istniejącego połączenia (ponieważ nie upłynął jeszcze limit czasu utrzymywania aktywności) i wysyła żądanie do serwera backendu.
- Zanim żądanie dotrze do serwera backendu, limit czasu utrzymywania aktywności został przekroczony.
- Żądanie zasobu realizowane przez procesor wiadomości jest w trakcie przesyłania, ale serwer backendu próbuje zamknąć połączenie, wysyłając do niego pakiet
FIN
. - Gdy procesor wiadomości czeka na dane, otrzymuje nieoczekiwaną wartość
FIN
, a połączenie jest przerywane. - Powoduje to pokazanie identyfikatora
Unexpected EOF
, a następnie zwracanie klienta502
przez podmiot przetwarzający wiadomości.
W tym przypadku zaobserwowaliśmy błąd 502
, ponieważ zarówno w procesorze wiadomości, jak i na serwerze backendu skonfigurowano tę samą wartość limitu czasu utrzymywania aktywności wynoszącą 60 sekund. Ten problem może również wystąpić, jeśli w procesorze wiadomości skonfigurowano wyższą wartość limitu czasu utrzymywania aktywności niż na serwerze backendu.
Diagnostyka
- Jeśli jesteś użytkownikiem chmury publicznej:
- Użyj narzędzia do monitorowania lub monitorowania interfejsów API (jak wyjaśniono w sekcji Typowe czynności diagnostyczne) i sprawdź, czy masz oba te ustawienia:
- Kod błędu:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Źródło błędu:
target
- Kod błędu:
- Aby dowiedzieć się więcej, zapoznaj się z artykułem Korzystanie z tcpdump.
- Użyj narzędzia do monitorowania lub monitorowania interfejsów API (jak wyjaśniono w sekcji Typowe czynności diagnostyczne) i sprawdź, czy masz oba te ustawienia:
- Jeśli jesteś użytkownikiem Private Cloud:
- Użyj narzędzia do śledzenia lub logów dostępu NGINX, aby określić identyfikator komunikatu, kod błędu i źródło błędu
502
. - Wyszukaj identyfikator wiadomości w logu procesora wiadomości
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Zobaczysz
java.io.EOFEXception: eof unexpected
, jak poniżej:2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- Błąd
java.io.EOFException: eof unexpected
oznacza, że procesor wiadomości otrzymałEOF
podczas oczekiwania na odczytanie odpowiedzi z serwera backendu. - Atrybut
useCount=7
w powyższym komunikacie o błędzie oznacza, że podmiot przetwarzający wiadomości użył tego połączenia około 7 razy, a atrybutbytesWritten=159
wskazuje, że procesor wiadomości wysłał do serwera backendu ładunek żądania w rozmiarze159
B. Jednak po wystąpieniu nieoczekiwanego błęduEOF
odebrano 0 bajtów. -
Oznacza to, że podmiot przetwarzający wiadomości wielokrotnie używał tego samego połączenia i tym razem wysłał dane, ale wkrótce potem otrzymał
EOF
przed otrzymaniem jakichkolwiek danych. Oznacza to, że istnieje duże prawdopodobieństwo, że limit czasu utrzymywania aktywności serwera backendu będzie krótszy lub równy czasowi ustawionemu w serwerze proxy interfejsu API.Aby dokładniej zbadać problem, skorzystaj z pomocy firmy
tcpdump
.
- Użyj narzędzia do śledzenia lub logów dostępu NGINX, aby określić identyfikator komunikatu, kod błędu i źródło błędu
Korzystanie z tcpdump
- Przechwyć
tcpdump
na serwerze backendu za pomocą tego polecenia:tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Przeanalizuj zarejestrowane dane (
tcpdump
):Oto przykładowe dane wyjściowe tcpdump:
W przykładzie powyżej
tcpdump
możesz zobaczyć te informacje:- W pakiecie
5992,
serwer backendu odebrał żądanieGET
. - W pakiecie
6064
odpowiada komunikatowi200 OK.
- W pakiecie
6084
serwer backendu odebrał kolejne żądanieGET
. - W pakiecie
6154
odpowiada komunikatowi200 OK
. - W pakiecie
6228
serwer backendu odebrał trzecie żądanieGET
. - Tym razem serwer backendu zwraca wartość
FIN, ACK
do procesora wiadomości (pakiet6285
), inicjując zamknięcie połączenia.
W tym przykładzie to samo połączenie zostało użyte ponownie dwukrotnie, ale w przypadku trzeciego żądania serwer backendu inicjuje zamknięcie połączenia, a procesor wiadomości czeka na dane z serwera backendu. Sugeruje to, że czas oczekiwania serwera backendu jest prawdopodobnie krótszy lub równy wartości określonej w serwerze proxy interfejsu API. Informacje na ten temat znajdziesz w artykule Porównanie limitu czasu utrzymywania aktywności na Apigee i na serwerze backendu.
- W pakiecie
Porównaj limity czasu utrzymywania aktywności na Apigee i na serwerze backendu
- Domyślnie Apigee używa wartości 60 sekund dla właściwości limitu czasu utrzymywania aktywności.
-
Możliwe jednak, że została przez Ciebie zastąpiona wartość domyślną w interfejsie API serwera proxy. Możesz to sprawdzić, sprawdzając konkretną definicję
TargetEndpoint
w niesprawnym serwerze proxy interfejsu API, który zwraca błędy502
.Przykładowa konfiguracja punktu końcowego docelowego:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
W powyższym przykładzie właściwość limitu czasu utrzymywania aktywności została zastąpiona wartością 30 sekund (
30000
milisekund). - 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ą
25 seconds
. - Jeśli ustalisz, że wartość właściwości limitu czasu utrzymywania aktywności w Apigee jest wyższa niż wartość właściwości limitu czasu utrzymywania aktywności na serwerze backendu jak w przykładzie powyżej, to jest przyczyną błędów
502
.
Rozdzielczość
Sprawdź, czy właściwość limitu czasu utrzymywania aktywności jest zawsze niższa w Apigee (w komponencie Proxy interfejsu API i procesor wiadomości) niż 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 serwerze proxy interfejsu API lub procesorze wiadomości tak, aby była ona krótsza niż wartość ustawiona na serwerze backendu, wykonując czynności opisane w artykule Konfigurowanie limitu czasu utrzymywania aktywności w procesorach wiadomości.
Jeśli problem nadal występuje, przejdź do artykułu Wymagane jest zebranie informacji diagnostycznych.
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 Apigee Edge warto przestrzegać tych wytycznych:
- Limit czasu utrzymywania aktywności klienta powinien być krótszy niż limit czasu utrzymywania aktywności routera brzegowego.
- Limit czasu utrzymywania aktywności routera brzegowego powinien być krótszy niż limit czasu utrzymywania aktywności procesora wiadomości.
- Limit czasu utrzymywania aktywności procesora wiadomości powinien być krótszy niż limit czasu utrzymywania aktywności na serwerze docelowym.
- Jeśli masz inne przeskoki przed lub za Apigee, zastosuj tę samą regułę. Za zamknięcie połączenia z hostem wychodzącym zawsze należy zostawić klienta odbierającego.
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.
Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
- Nazwa organizacji
- Nazwa środowiska
- Nazwa serwera proxy interfejsu API
- Wykonaj polecenie
curl
, aby odtworzyć błąd502
- Plik śledzenia zawierający żądania z błędem
502 Bad Gateway - Unexpected EOF
- Jeśli błędy
502
nie występują obecnie, podaj informacje o strefie czasowej, w których wystąpiły błędy502
w przeszłości.
Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:
- Zaobserwowany pełny komunikat o błędzie dotyczący nieudanych żądań
- Organizacja, nazwa środowiska i nazwa serwera proxy interfejsu API, w przypadku których zaobserwowano
502
błędu - Pakiet proxy API
- Plik śledzenia zawierający żądania z błędem
502 Bad Gateway - Unexpected EOF
- Logi dostępu NGINX
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Logi procesora wiadomości
/opt/apigee/var/log/edge-message-processor/logs/system.log
- Okres z informacjami o strefie czasowej, w których wystąpiły błędy
502
- Dane
Tcpdumps
zebrane przez procesory wiadomości, serwer backendu lub oba te serwery w momencie wystąpienia błędu