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

Przeglądasz dokumentację Apigee Edge.
Przejdź do Dokumentacja Apigee X. informacje.

Krótki opis problemu

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

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 503 Service Unavailable

Możesz też zobaczyć następujący komunikat o błędzie:

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

Możliwe przyczyny

Typowe kroki diagnostyki

Określ identyfikator wiadomości nieudanego żądania

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

Diagnostyka

1. Jeśli jesteś użytkownikiem Public Cloud lub Private Cloud:
   1. Użyć narzędzia śledzenia (jak opisano w sekcji Typowe kroki diagnostyki). i sprawdź, czy w panelu Analytics Data Recorded (Rejestrowane dane Analytics) masz ustawione oba te elementy:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Użyć narzędzia śledzenia (jak opisano w sekcji Typowe kroki diagnostyki). i sprawdź, czy w panelu Error (Błąd) masz ustawione oba te ustawienia bezpośrednio po właściwość state TARGET_REQ_FLOW:
      • error.class::com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      

   3. Więcej informacji znajdziesz w artykule Korzystanie z tcpdump.
2. Jeśli jesteś użytkownikiem Private Cloud:
   • Ustal identyfikator wiadomości nieudanego żądania.
   • Wyszukaj identyfikator wiadomości w dzienniku procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   • Zobaczysz jeden z tych wyjątków:

     Wyjątek 1: java.io.IOException: podczas zapisu do kanału ClientOutputChannel wystąpiła uszkodzona potok

     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: wyjątek onExceptionWrite: {}
     java.io.IOException: Uszkodzona potok

     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 oznaczają, że chociaż procesor wiadomości nadal pisał żądanie do serwera backendu, połączenie zostało przedwcześnie zamknięte przez z serwera backendu. Dlatego procesor wiadomości zgłasza wyjątek java.io.IOException: Broken pipe.
   • Remote:IP:PORT wskazuje rozpoznany serwer backendu adres IP i numer portu.
   • Atrybut bytesWritten=76295 w powyższym komunikacie o błędzie wskazuje, że procesor wiadomości wysłał do backendu ładunek o długości 76295 bajtów serwera, gdy połączenie zostało przedwcześnie zamknięte.
   • Atrybut bytesRead=0 wskazuje, że procesor wiadomości nie odebrano jakiekolwiek dane (odpowiedź) z serwera backendu.
   • Aby dokładniej zbadać ten problem, zbierz w backendzie obiekt tcpdump serwera lub procesora wiadomości i przeanalizuj je w sposób opisany poniżej.

Korzystanie z tcpdump

1. Przechwyć interfejs tcpdump na serwerze backendu lub w procesorze wiadomości za pomocą następujące polecenia:

   Polecenie do gromadzenia danych tcpdump na serwerze backendu:

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

   Polecenie do gromadzenia danych tcpdump w procesorze wiadomości:

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

2. Przeanalizuj przechwycone dane (tcpdump):

   Przykładowe dane wyjściowe tcpdump (zbierane przez procesor wiadomości):

   

   W sekcji tcpdump powyżej możesz zobaczyć:

   1. W pakiecie 4 procesor wiadomości wysłał żądanie POST do do serwera backendu.
   2. W pakiecie 5, 8, 9, 10, 11, procesor wiadomości nadal wysyłał ładunek żądania do z serwera backendu.
   3. W pakiecie 6 i 7 serwer backendu odpowiedział żądaniem ACK dla części ładunku żądania otrzymanego z procesora wiadomości.
   4. Jednak w pakiecie 12, zamiast odpowiadać z użyciem ACK dla odebranych pakietów danych aplikacji, a następnie odpowiadając ładunek, serwer backendu wysyła w odpowiedzi tag FIN ACK inicjujący zamknięcie połączenia.
   5. Widać to wyraźnie, że serwer backendu przedwcześnie zamyka połączenie. gdy procesor wiadomości wciąż wysyłał ładunek żądania.
   6. Powoduje to, że procesor wiadomości rejestruje IOException: Broken Pipe i zwróć klientowi 503

Rozdzielczość

1. Nawiąż współpracę z zespołami ds. aplikacji i sieci (albo z zespołami ds. aplikacji i sieci), aby przeanalizować i naprawić z przedwczesnymi odłączeniami po stronie serwera backendu.
2. Upewnij się, że aplikacja serwera backendu nie przekracza limitu czasu oczekiwania ani nie resetuje połączenia przed otrzymaniem całego ładunku żądania.
3. Jeśli masz urządzenie lub warstwę pośredniczącą między Apigee a serwerem backendu, upewnij się, że nie przekroczono limitu czasu przed otrzymaniem całego ładunku żądania.

Jeśli problem nadal występuje, przeczytaj artykuł Wymagane są informacje diagnostyczne.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zwróć uwagę na informacje diagnostyczne, a następnie skontaktuj się z zespołem pomocy Apigee Edge:

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

• Nazwa organizacji
• Nazwa środowiska
• Nazwa serwera proxy interfejsu API
• Wykonaj polecenie curl, aby odtworzyć błąd 503
• Plik śledzenia zawierający żądanie z błędem 503 Service Unavailable
• Jeśli błędy typu 503 nie występują obecnie, podaj przedział czasu za pomocą funkcji informacje o strefie czasowej, gdy w przeszłości wystąpiły błędy 503.

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

• Pełny komunikat o błędzie zaobserwowany dla nieudanych żądań
• Organizacja, nazwa środowiska i nazwa serwera proxy interfejsu API, które obserwujesz 503 błędu
• Pakiet serwera 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 wiadomości
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• Przedział czasu z informacjami o strefie czasowej, w którym wystąpiły błędy 503.
• Tcpdumps są zbierane przez procesory wiadomości i serwer backendu, gdy wystąpił błąd