503 Usługa niedostępna – przedwczesne zamknięcie przez serwer backendu

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu odpowiedzi HTTP 503 z komunikatem Service Unavailable po wywołaniu proxy interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 503 Service Unavailable

Dodatkowo możesz zobaczyć ten komunikat o błędzie:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

Możliwe przyczyny

Typowe czynności diagnostyczne

Określanie identyfikatora wiadomości żądania, które się nie powiodło

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

Diagnostyka

1. Jeśli jesteś użytkownikiem Public Cloud lub Private Cloud :
   1. Użyj narzędzia Trace (jak opis0}opisano w sekcji Typowe czynności diagnostyczne) i sprawdź, czy w panelu Zarejestrowane dane analityczne masz ustawione te 2 wartości:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Użyj narzędzia Trace (jak opisano w sekcji Typowe czynności diagnostyczne) i sprawdź, czy w panelu Błąd bezpośrednio po właściwości TARGET_REQ_FLOW state masz ustawione te 2 wartości:
      • error.class: com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      

   3. Aby uzyskać więcej informacji, przeczytaj artykuł Korzystanie z tcpdump.
2. Jeśli jesteś użytkownikiem Private Cloud :
   • Określ identyfikator wiadomości żądania, które się nie powiodło.
   • Wyszukaj identyfikator wiadomości w logu procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   • Zobaczysz jeden z tych wyjątków:

     Wyjątek 1: java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel

     2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
     rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
     INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
     Exception java.io.IOException: Broken pipe occurred while writing to channel
     ClientOutputChannel(ClientChannel[Connected:
     Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
     bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)

     lub

     Wyjątek 2: onExceptionWrite exception: {}
     java.io.IOException: Broken pipe

     2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
     rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
     NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
     ClientChannel[Connected: Remote:IP:PORT
     Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
     ms  isOpen=false.onExceptionWrite exception: {}
     java.io.IOException: Broken pipe

   • Oba te wyjątki wskazują, że gdy procesor komunikatów nadal zapisywał ładunek żądania na serwerze backendu, połączenie zostało przedwcześnie zamknięte przez serwer backendu. Dlatego procesor komunikatów zgłasza wyjątek java.io.IOException: Broken pipe.
   • Wartość Remote:IP:PORT wskazuje rozpoznany adres IP i numer portu serwera backendu.
   • Atrybut bytesWritten=76295 w powyższym komunikacie o błędzie wskazuje, że procesor komunikatów wysłał do serwera backendu ładunek o rozmiarze 76295 bajtów, gdy połączenie zostało przedwcześnie zamknięte.
   • Atrybut bytesRead=0 wskazuje, że procesor komunikatów nie otrzymał żadnych danych (odpowiedzi) z serwera backendu.
   • Aby dokładniej zbadać ten problem, zbierz tcpdump na serwerze backendu lub procesorze komunikatów i przeanalizuj go w sposób opisany poniżej.

Korzystanie z tcpdump

1. Uruchom tcpdump na serwerze backendu lub procesorze komunikatów za pomocą tych poleceń:

   Polecenie do zbierania tcpdump na serwerze backendu:

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

   Polecenie do zbierania tcpdump na procesorze komunikatów:

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

2. Przeanalizuj zebrany tcpdump:

   Przykładowe dane wyjściowe tcpdump (zebrane na procesorze komunikatów):

   

   W powyższym tcpdump możesz zobaczyć te informacje:

   1. W pakiecie 4 procesor komunikatów wysłał żądanie POST do serwera backendu.
   2. W pakiecie 5, 8, 9, 10, 11 procesor komunikatów nadal wysyłał ładunek żądania do serwera backendu.
   3. W pakietach 6 i 7 serwer backendu odpowiedział ACK na część ładunku żądania otrzymanego od procesora komunikatów.
   4. Jednak w pakiecie 12 serwer backendu zamiast odpowiedzieć ACK na otrzymane pakiety danych aplikacji i następnie odpowiedzieć ładunkiem odpowiedzi, odpowiada FIN ACK , inicjując zamknięcie połączenia.
   5. Wyraźnie widać, że serwer backendu przedwcześnie zamyka połączenie gdy procesor komunikatów nadal wysyła ładunek żądania.
   6. Powoduje to, że procesor komunikatów rejestruje błąd IOException: Broken Pipe i zwraca klientowi kod 503.

Rozwiązanie

1. Współpracuj z zespołem ds. aplikacji lub sieci (albo z oboma zespołami), aby przeanalizować i rozwiązać problem z przedwczesnym rozłączaniem po stronie serwera backendu.
2. Upewnij się, że aplikacja serwera backendu nie przekracza limitu czasu ani nie resetuje połączenia przed otrzymaniem całego ładunku żądania.
3. Jeśli między Apigee a serwerem backendu znajduje się urządzenie lub warstwa sieci pośredniej, upewnij się, że nie przekraczają one limitu czasu przed otrzymaniem całego ładunku żądania.

Jeśli problem nadal występuje, przejdź do sekcji Informacje diagnostyczne, które musisz zebrać.

Informacje diagnostyczne, które musisz zebrać

Jeśli problem nadal występuje nawet po wykonaniu powyższych instrukcji, zbierz te informacje diagnostyczne i skontaktuj się z zespołem pomocy Apigee Edge:

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

• Nazwa organizacji
• Nazwa środowiska
• Nazwa proxy interfejsu API
• Pełne polecenie curl do odtworzenia błędu 503
• Plik śledzenia zawierający żądanie z błędem 503 Service Unavailable
• Jeśli błędy 503 nie występują obecnie, podaj okres z informacjami o strefie czasowej, w którym błędy 503 występowały w przeszłości.

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

• Pełny komunikat o błędzie zaobserwowany w przypadku żądań, które się nie powiodły
• Nazwa organizacji, środowiska i proxy interfejsu API, w przypadku których występują 503 błędy
• Pakiet proxy interfejsu API
• Plik śledzenia zawierający żądania z błędem 503 Service Unavailable
• Logi dostępu NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Logi 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 503
• Tcpdumps zebrane na procesorach komunikatów i serwerze backendu, gdy wystąpił błąd