502 Nieprawidłowa bramka Nieoczekiwana wartość EOF

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:

  1. Otwórz panel Zbadaj.
  2. Wybierz Kod stanu z menu i sprawdź, czy w przypadku wystąpienia błędów 502 został wybrany właściwy okres.
  3. Jeśli widzisz dużą liczbę błędów 502, kliknij pole w tabeli.
  4. Po prawej stronie kliknij Wyświetl logi obok błędów 502, które wyglądają mniej więcej tak:
  5. Znajdują się tu następujące informacje:

    • Źródło błędu: target
    • Kod błędu: messaging.adaptors.http.UnexpectedEOFAtTarget

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:

  1. Włącz sesję śledzenia i wykonaj wywołanie interfejsu API, aby odtworzyć problem 502 Bad Gateway.
  2. Wybierz 1 z nieudanych żądań i sprawdź log czasu.
  3. Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.
  4. Błąd powinien pojawić się po wysłaniu żądania do serwera docelowego, jak pokazano poniżej:

    alt_text

    alt_text

  5. 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łędem 502, 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:

  1. Sprawdź logi dostępu do NGINX.
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. 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 z 502.
  3. 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łąd 502 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

  1. 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.
  2. Włącz w interfejsie użytkownika log czasu interfejsu API, którego dotyczy problem.
  3. Jeśli śledzenie nieudanego żądania do interfejsu API wygląda tak:
    1. Błąd 502 Bad Gateway pojawia się natychmiast po rozpoczęciu żądania przepływu docelowego.
    2. error.class wyświetla messaging.adaptors.http.UnexpectedEOF.

      W takim przypadku bardzo prawdopodobne jest, że ten problem jest spowodowany nieprawidłową konfiguracją serwera docelowego.

  4. Uzyskaj definicję serwera docelowego przy użyciu wywołania interfejsu Edge Management API:
    1. 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>
      
    2. 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 >
      
  5. 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 port 443. 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łąd UnexpectedEOFAtTarget. 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.

  1. Jeśli usługa backendu wymaga jednokierunkowej komunikacji SSL:
    1. Musisz włączyć TLS/SSL w definicji TargetServer, dodając atrybuty SSLInfo, w których flaga enabled 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>
      
    2. 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>
      
  2. Jeśli usługa backendu wymaga dwukierunkowej komunikacji SSL:
    1. Musisz mieć atrybuty SSLInfo z odpowiednio ustawionymi flagami ClientAuthEnabled, Keystore, KeyAlias i Truststore, 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 >
      

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

  1. 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.
  2. Sprawdź logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log) i wyszukaj elementy eof unexpected dla określonego interfejsu API lub czy masz unikalny identyfikator messageid 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ź.

  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 jakieś błędy lub informacje, przejdź do sekcji Rozwiązanie i napraw problem na serwerze backendu.
  4. 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:
    1. 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
      
    2. 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.

  5. Przeanalizuj ten przykład tcpdump.

    Przykładowy plik tcpdump wykonany, gdy wystąpiło 502 Bad Gateway Error (UnexpectedEOFAtTarget)

  6. W wyniku TCPDump zauważysz taką sekwencję zdarzeń:
    1. W pakiecie 985 procesor wiadomości wysyła żądanie API do serwera backendu.
    2. W pakiecie 986 serwer backendu natychmiast odpowiada, wysyłając [FIN,ACK].
    3. W pakiecie 987 procesor wiadomości wysyła do serwera backendu żądanie [FIN,ACK].
    4. Ostatecznie połączenia zostały zamknięte za pomocą [ACK] i [RST] po obu stronach.
    5. Ponieważ serwer backendu wysyła [FIN,ACK], otrzymujesz wyjątek java.io.EOFException: eof unexpected w procesorze wiadomości.
  7. 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:

  1. 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.
  2. 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.
  3. Zanim żądanie dotrze do serwera backendu, limit czasu utrzymywania aktywności został przekroczony.
  4. Żą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.
  5. Gdy procesor wiadomości czeka na dane, otrzymuje nieoczekiwaną wartość FIN, a połączenie jest przerywane.
  6. Powoduje to pokazanie identyfikatora Unexpected EOF, a następnie zwracanie klienta 502 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

  1. Jeśli jesteś użytkownikiem chmury publicznej:
    1. 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
    2. Aby dowiedzieć się więcej, zapoznaj się z artykułem Korzystanie z tcpdump.
  2. Jeśli jesteś użytkownikiem Private Cloud:
    1. 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.
    2. Wyszukaj identyfikator wiadomości w logu procesora wiadomości
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    3. 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)
      
    4. Błąd java.io.EOFException: eof unexpected oznacza, że procesor wiadomości otrzymał EOF podczas oczekiwania na odczytanie odpowiedzi z serwera backendu.
    5. 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 atrybut bytesWritten=159 wskazuje, że procesor wiadomości wysłał do serwera backendu ładunek żądania w rozmiarze 159 B. Jednak po wystąpieniu nieoczekiwanego błędu EOF odebrano 0 bajtów.
    6. 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.

Korzystanie z tcpdump

  1. Przechwyć tcpdump na serwerze backendu za pomocą tego polecenia:
    tcpdump -i any -s 0 host MP_IP_Address -w File_Name
    
  2. Przeanalizuj zarejestrowane dane (tcpdump):

    Oto przykładowe dane wyjściowe tcpdump:

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

    1. W pakiecie 5992, serwer backendu odebrał żądanie GET.
    2. W pakiecie 6064 odpowiada komunikatowi 200 OK.
    3. W pakiecie 6084 serwer backendu odebrał kolejne żądanie GET.
    4. W pakiecie 6154 odpowiada komunikatowi 200 OK.
    5. W pakiecie 6228 serwer backendu odebrał trzecie żądanie GET.
    6. Tym razem serwer backendu zwraca wartość FIN, ACK do procesora wiadomości (pakiet 6285), 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.

Porównaj limity czasu utrzymywania aktywności na Apigee i na serwerze backendu

  1. Domyślnie Apigee używa wartości 60 sekund dla właściwości limitu czasu utrzymywania aktywności.
  2. 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łędy 502.

    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).

  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ą 25 seconds.
  4. 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.

  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 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:

  1. Limit czasu utrzymywania aktywności klienta powinien być krótszy niż limit czasu utrzymywania aktywności routera brzegowego.
  2. Limit czasu utrzymywania aktywności routera brzegowego powinien być krótszy niż limit czasu utrzymywania aktywności procesora wiadomości.
  3. Limit czasu utrzymywania aktywności procesora wiadomości powinien być krótszy niż limit czasu utrzymywania aktywności na serwerze docelowym.
  4. 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łąd 502
  • 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łędy 502 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