502 Nieprawidłowa bramka Nieoczekiwana wartość EOF

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

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 realizować żądanie.

Komunikaty o błędach

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 502 Bad Gateway

Możesz też zobaczyć 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 być spowodowany tymi czynnikami:

Typowe etapy diagnostyki

Aby zdiagnozować błąd, możesz użyć jednej z tych metod:

• Monitorowanie interfejsu API
• Narzędzie Trace
• Dzienniki dostępu NGINX

Przyczyna: nieprawidłowo skonfigurowany serwer docelowy

Serwer docelowy nie jest prawidłowo skonfigurowany do obsługi połączeń TLS/SSL.

Diagnostyka

1. Aby określić identyfikator wiadomości, kod błędu i źródło błędu 502, użyj monitorowania interfejsu API, narzędzia do śledzenia lub logów dostępu NGINX.
2. Włącz śledzenie w interfejsie API, którego dotyczy problem.
3. Jeśli ślad nieudanego żądania do interfejsu API zawiera te informacje:
   1. Błąd 502 Bad Gateway pojawia się natychmiast po rozpoczęciu żądania przepływu docelowego.
   2. Na ekranie error.class wyświetla się messaging.adaptors.http.UnexpectedEOF.

      W takim przypadku problem jest najprawdopodobniej spowodowany nieprawidłową konfiguracją serwera docelowego.

4. Pobierz definicję serwera docelowego za pomocą 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 błędna definicja TargetServer:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. Ilustracja definicji TargetServer przedstawia przykład jednej z typowych nieprawidłowych konfiguracji, która jest wyjaśniona w ten sposób:

   Załóżmy, że serwer docelowy mocktarget.apigee.net jest skonfigurowany tak, aby akceptować bezpieczne (HTTPS) połączenia na porcie 443. Jeśli jednak przyjrzysz się definicji serwera docelowego, nie znajdziesz żadnych innych atrybutów ani flag, które wskazywałyby, że jest on przeznaczony do bezpiecznych połączeń. Powoduje to, że Edge traktuje żądania API kierowane do określonego serwera docelowego jako żądania HTTP (niezabezpieczone). Dlatego Edge nie zainicjuje procesu uzgadniania połączenia SSL z tym serwerem docelowym.

   Serwer docelowy jest skonfigurowany tak, aby akceptować tylko żądania HTTPS (SSL) na porcie 443, dlatego odrzuci żądanie z Edge lub zamknie połączenie. W efekcie w procesorze komunikatów pojawi się błąd UnexpectedEOFAtTarget. Procesor komunikatów wyśle 502 Bad Gateway jako odpowiedź do klienta.

Rozdzielczość

Zawsze sprawdzaj, czy serwer docelowy jest prawidłowo skonfigurowany zgodnie z Twoimi wymaganiami.

W przypadku powyższego przykładu, jeśli chcesz wysyłać żądania do bezpiecznego serwera docelowego (HTTPS/SSL), musisz uwzględnić atrybuty SSLInfo z ustawioną flagą enabled na wartość true. Chociaż atrybuty SSLInfo można dodać do serwera docelowego w samej definicji punktu końcowego docelowego, zalecamy dodanie atrybutów SSLInfo w ramach definicji serwera docelowego, aby uniknąć nieporozumień.

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 jest ustawiona na wartość „true”, 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 zaufanych certyfikatów (zawierający certyfikat serwera docelowego), jak pokazano 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 na serwerach backendu

Przyczyna: wyjątek EOFException z serwera backendu

Serwer backendu może nagle wysłać EOF (End of File).

Diagnostyka

1. Aby określić identyfikator wiadomości, kod błędu i źródło błędu 502, użyj monitorowania interfejsu API, narzędzia do śledzenia lub logów dostępu NGINX.
2. Sprawdź logi procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) i wyszukaj, czy masz eof unexpected w przypadku konkretnego interfejsu API lub czy masz unikalny messageid dla żądania do interfejsu API. Jeśli tak, możesz go wyszukać.

   Przykładowy zrzut stosu wyjątku z dziennika procesora komunikatów

   "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 java.io.EOFException: eof unexpected wystąpił podczas próby odczytania przez procesor wiadomości odpowiedzi z serwera backendu. Ten wyjątek oznacza, że nieoczekiwanie osiągnięto koniec pliku lub strumienia.

   Oznacza to, że procesor wiadomości wysłał żądanie interfejsu API do serwera backendu i oczekiwał lub odczytywał odpowiedź. Serwer backendu nagle przerwał połączenie, zanim procesor wiadomości otrzymał odpowiedź lub mógł ją w całości odczytać.

3. Sprawdź logi serwera backendu i poszukaj błędów lub informacji, które mogły spowodować nagłe przerwanie połączenia przez serwer backendu. Jeśli znajdziesz jakieś błędy lub informacje, przejdź do sekcji Rozwiązanie i odpowiednio rozwiąż problem na serwerze backendu.
4. Jeśli na serwerze backendu nie znajdziesz żadnych błędów ani informacji, zbierz dane wyjściowe tcpdump na procesorach wiadomości:
   1. Jeśli 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 host serwera backendu ma kilka adresów IP, użyj tego polecenia:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      Zwykle ten błąd jest spowodowany tym, że serwer backendu odpowiada kodem [FIN,ACK], gdy tylko procesor komunikatów wyśle żądanie do serwera backendu.

5. Zapoznaj się z tym tcpdump przykładem.

   Próbka tcpdump pobrana, gdy wystąpiło zdarzenie 502 Bad Gateway Error (UnexpectedEOFAtTarget)

   

6. W danych wyjściowych TCPDump zauważasz tę sekwencję zdarzeń:
   1. W pakiecie 985 procesor wiadomości wysyła żądanie interfejsu API do serwera backendu.
   2. W pakiecie 986 serwer backendu natychmiast odpowiada pakietem [FIN,ACK].
   3. W pakiecie 987 procesor komunikatów odpowiada [FIN,ACK] serwerowi backendu.
   4. Połączenia z [ACK] i [RST] zostaną ostatecznie zamknięte po obu stronach.
   5. Ponieważ serwer backendu wysyła [FIN,ACK], w procesorze wiadomości otrzymujesz wyjątek java.io.EOFException: eof unexpected.
7. Może się tak zdarzyć, jeśli na serwerze backendu wystąpi problem z siecią. Poproś zespół ds. operacji sieciowych o zbadanie tego problemu.

Rozdzielczość

Odpowiednio rozwiąż problem na serwerze backendu.

Jeśli problem nadal występuje i potrzebujesz pomocy w rozwiązaniu problemu z 502 Bad Gateway Error lub podejrzewasz, że problem dotyczy Edge, skontaktuj się z zespołem pomocy Apigee Edge.

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

Zanim zaczniesz sprawdzać, czy to jest przyczyną błędów 502, zapoznaj się z tymi pojęciami.

Stałe połączenia w Apigee

Apigee domyślnie (zgodnie ze standardem HTTP/1.1) używa trwałych połączeń podczas komunikacji z docelowym serwerem backendu. Stałe połączenia mogą zwiększyć wydajność, ponieważ umożliwiają ponowne wykorzystanie już nawiązanego połączenia TCP i (w stosownych przypadkach) TLS/SSL, co zmniejsza opóźnienia. Czas, przez jaki połączenie musi być utrzymywane, jest kontrolowany przez właściwość keep alive timeout (keepalive.timeout.millis).

Zarówno serwer backendu, jak i procesor komunikatów Apigee używają limitów czasu utrzymywania połączenia, aby utrzymywać otwarte połączenia między sobą. Jeśli w czasie trwania limitu czasu utrzymywania aktywności nie zostaną odebrane żadne dane, serwer backendu lub procesor komunikatów może zamknąć połączenie z drugim urządzeniem.

Serwery proxy interfejsu API wdrożone w procesorze komunikatów w Apigee mają domyślnie ustawiony limit czasu utrzymywania połączenia na 60s, chyba że zostanie on zastąpiony. Gdy przez czas 60s nie zostaną odebrane żadne dane, Apigee zamknie połączenie z serwerem backendu. Serwer backendu będzie też utrzymywać limit czasu utrzymywania połączenia, a gdy ten limit czasu wygaśnie, serwer backendu zamknie połączenie z procesorem komunikatów.

Konsekwencje nieprawidłowej konfiguracji limitu czasu podtrzymania połączenia

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 kod stanu End Of File (FIN) w odpowiedzi na żądanie zasobu.

Jeśli na przykład limit czasu utrzymywania aktywności jest skonfigurowany w ramach proxy interfejsu API lub procesora komunikatów z wartością większą lub równą czasowi oczekiwania serwera backendu upstream, może wystąpić następująca sytuacja wyścigu. Oznacza to, że jeśli procesor komunikatów nie otrzyma żadnych danych aż do momentu zbliżonego do progu limitu czasu oczekiwania na utrzymywanie aktywności serwera backendu, przyjdzie żądanie, które zostanie wysłane do serwera backendu przy użyciu istniejącego połączenia. Może to prowadzić do 502 Bad Gateway z powodu nieoczekiwanego błędu EOF, jak wyjaśniono poniżej:

1. Załóżmy, że czas oczekiwania na utrzymanie aktywności w przypadku procesora komunikatów i serwera backendu wynosi 60 sekund, a nowe żądanie nie nadeszło do 59 sekund po obsłużeniu poprzedniego żądania przez konkretny procesor komunikatów.
2. Procesor komunikatów przetwarza żądanie, które nadeszło w 59 sekundzie, korzystając z istniejącego połączenia (ponieważ limit czasu utrzymywania aktywności jeszcze nie upłynął), i wysyła żądanie do serwera backendu.
3. Zanim jednak żądanie dotrze do serwera backendu, na serwerze backendu zostanie przekroczony próg czasu oczekiwania na utrzymanie połączenia.
4. Żądanie zasobu przez procesor wiadomości jest w trakcie realizacji, ale serwer backendu próbuje zamknąć połączenie, wysyłając do procesora wiadomości pakiet FIN.
5. Gdy procesor komunikatów oczekuje na otrzymanie danych, zamiast tego otrzymuje nieoczekiwany znak FIN, a połączenie zostaje zakończone.
6. W rezultacie procesor komunikatów zwraca klientowi wartość Unexpected EOF, a następnie 502.

W tym przypadku zaobserwowaliśmy, że błąd 502 wystąpił, ponieważ zarówno w procesorze komunikatów, jak i na serwerze backendu skonfigurowano tę samą wartość limitu czasu podtrzymania połączenia, czyli 60 sekund. Podobnie ten problem może wystąpić, jeśli w przypadku procesora wiadomości skonfigurowano wyższą wartość limitu czasu utrzymywania połączenia niż na serwerze backendu.

Diagnostyka

1. Jeśli jesteś użytkownikiem chmury publicznej:
   1. Użyj narzędzia do monitorowania interfejsu API lub narzędzia śledzenia (zgodnie z opisem 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. Więcej informacji znajdziesz w artykule Korzystanie z tcpdump.
2. Jeśli jesteś użytkownikiem Private Cloud:
   1. Użyj narzędzia do śledzenia lub dzienników dostępu NGINX, aby określić identyfikator wiadomości, kod błędu i źródło błędu 502.
   2. Wyszukaj identyfikator wiadomości w dzienniku procesora komunikatów
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Zobaczysz ikonę java.io.EOFEXception: eof unexpected, jak pokazano 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, gdy nadal czekał na odczytanie odpowiedzi z serwera backendu.
   5. Atrybut useCount=7 w powyższym komunikacie o błędzie wskazuje, że procesor komunikatów użył tego połączenia około 7 razy, a atrybut bytesWritten=159 wskazuje, że procesor komunikatów wysłał do serwera backendu ładunek żądania o rozmiarze 159 bajtów. Jednak w momencie wystąpienia nieoczekiwanego błędu EOF otrzymał 0 bajtów.

   6. Wynika z tego, że procesor komunikatów wielokrotnie używał tego samego połączenia, a w tym przypadku wysłał dane, ale wkrótce potem otrzymał EOF, zanim jakiekolwiek dane zostały odebrane. Oznacza to, że istnieje duże prawdopodobieństwo, że limit czasu podtrzymania połączenia serwera backendu jest krótszy lub równy limitowi czasu ustawionemu w proxy interfejsu API.

      Możesz to sprawdzić, korzystając z tcpdump, jak opisano poniżej.

Korzystanie z tcpdump

1. Zrób tcpdump na serwerze backendu za pomocą tego polecenia:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Analizuj tcpdump:

   Oto przykładowe dane wyjściowe polecenia tcpdump:

   

   W przykładzie powyżej tcpdump widać:

   1. W pakiecie 5992, serwer backendu otrzymał żądanie GET.
   2. W pakiecie 6064 odpowiada 200 OK.
   3. W pakiecie 6084 serwer backendu otrzymał kolejne żądanie GET.
   4. W pakiecie 6154 odpowiada 200 OK.
   5. W pakiecie 6228 serwer backendu otrzymał trzecie żądanie GET.
   6. Tym razem serwer backendu zwraca do procesora komunikatów FIN, ACK (pakiet 6285), co powoduje zamknięcie połączenia.

   W tym przykładzie to samo połączenie zostało użyte 2 razy, ale przy trzecim żądaniu serwer backendu zainicjował zamknięcie połączenia, podczas gdy procesor komunikatów oczekiwał na dane z serwera backendu. Sugeruje to, że czas oczekiwania na połączenie serwera backendu jest prawdopodobnie krótszy lub równy wartości ustawionej w proxy interfejsu API. Aby to sprawdzić, zapoznaj się z artykułem Porównanie czasu oczekiwania na odpowiedź na Apigee i serwerze backendu.

Porównanie limitu czasu podtrzymania połączenia w Apigee i na serwerze backendu

1. Domyślnie Apigee używa wartości 60 sekund dla właściwości limitu czasu utrzymywania połączenia.

2. Możliwe jednak, że wartość domyślna została zastąpiona w proxy interfejsu API. Możesz to sprawdzić, analizując konkretną definicję TargetEndpoint w nieprawidłowo działającym serwerze proxy interfejsu API, który zwraca błędy 502.

   Przykładowa konfiguracja TargetEndpoint:

   <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 utrzymania połączenia jest zastępowana wartością 30 sekund (30000 milisekund).

3. Następnie sprawdź właściwość limitu czasu utrzymywania połączenia skonfigurowaną na serwerze backendu. Załóżmy, że serwer backendu jest skonfigurowany z wartością 25 seconds.
4. Jeśli stwierdzisz, że wartość właściwości limitu czasu oczekiwania na odpowiedź na Apigee jest wyższa niż wartość właściwości limitu czasu oczekiwania na odpowiedź na serwerze backendu, jak w powyższym przykładzie, to jest to przyczyna błędów 502.

Rozdzielczość

Upewnij się, że wartość właściwości limitu czasu utrzymywania połączenia jest zawsze niższa w Apigee (w komponencie proxy interfejsu API i procesora komunikatów) niż na serwerze backendu.

1. Określ wartość czasu bezczynności połączenia keep-alive na serwerze backendu.
2. Skonfiguruj odpowiednią wartość właściwości limitu czasu utrzymywania połączenia w proxy interfejsu API lub procesorze komunikatów, tak aby była ona niższa niż wartość ustawiona na serwerze backendu. Aby to zrobić, wykonaj czynności opisane w artykule Konfigurowanie limitu czasu utrzymywania połączenia w procesorach komunikatów.

Jeśli problem nadal występuje, przejdź do sekcji Wymagane informacje diagnostyczne.

Sprawdzona metoda

Zdecydowanie zaleca się, aby komponenty podrzędne miały zawsze mniejszy próg limitu czasu utrzymywania połączenia niż skonfigurowany na serwerach nadrzędnych, aby uniknąć tego rodzaju sytuacji wyścigu i błędów 502. Każdy przeskok w dół powinien być mniejszy niż każdy przeskok w górę. W Apigee Edge warto stosować te wytyczne:

1. Czas oczekiwania na odpowiedź klienta powinien być krótszy niż czas oczekiwania na odpowiedź routera brzegowego.
2. Czas oczekiwania na utrzymywanie aktywności routera brzegowego powinien być krótszy niż czas oczekiwania na utrzymywanie aktywności procesora komunikatów.
3. Czas oczekiwania na utrzymywanie aktywności procesora komunikatów powinien być krótszy niż czas oczekiwania na utrzymywanie aktywności serwera docelowego.
4. Jeśli przed lub za Apigee znajdują się inne przeskoki, należy zastosować tę samą regułę. Zawsze pozostawiaj zamknięcie połączenia z serwerem nadrzędnym w gestii klienta podrzędnego.

musi zbierać informacje diagnostyczne;

Jeśli problem nadal występuje po wykonaniu powyższych instrukcji, zbierz te 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 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 okres, w którym wystąpiły 502 w przeszłości, wraz z informacjami o strefie czasowej.

Jeśli jesteś użytkownikiem chmury Private Cloud, podaj te informacje:

• Pełny komunikat o błędzie dotyczący żądań, które nie zostały zrealizowane
• Nazwa organizacji, środowiska i proxy interfejsu API, w których występują 502błędy
• Pakiet proxy interfejsu 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
• Dzienniki procesora komunikatów
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Okres z informacjami o strefie czasowej, w którym wystąpiły błędy 502.
• Tcpdumps zebrane na procesorach komunikatów lub serwerze zaplecza albo na obu tych elementach, gdy wystąpił błąd.