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

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Krótki opis problemu

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

Komunikat o błędzie

Aplikacja kliencka pobiera ten kod odpowiedzi:

HTTP/1.1 503 Service Unavailable

Oprócz tego może pojawić się ten komunikat o błędzie:

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

Możliwe przyczyny

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Serwer docelowy przedwcześnie zamyka połączenie	Serwer docelowy przedwcześnie kończy połączenie, gdy procesor wiadomości nadal wysyła ładunek żądania.	Użytkownicy chmury publicznej i prywatnej usługi Edge

Najczęstsze kroki diagnostyki

Określ identyfikator wiadomości nieudanego żądania

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

Diagnostyka

1. Jeśli jesteś użytkownikiem chmury publicznej lub chmury prywatnej:
   1. Użyj narzędzia do śledzenia (jak opisano w sekcji Typowe kroki diagnostyki) i sprawdź, czy w panelu Zarejestrowane dane Analytics masz ustawione oba te warunki:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

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

      

   3. Aby dowiedzieć się więcej, zapoznaj się z artykułem Korzystanie z tcpdump.
2. Jeśli jesteś użytkownikiem Private Cloud:
   • Określ identyfikator wiadomości dla nieudanego żądania.
   • Wyszukaj identyfikator wiadomości w logu procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   • Występuje jeden z tych wyjątków:

     Wyjątek 1: java.io.IOWyjątek: podczas zapisu w kanale ClientExitChannel wystąpił błąd potoku

     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: onexceptWrite wyjątek: {}
     java.io.IOWyjątek: Uszkodzona pionowa kreska

     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 gdy procesor wiadomości nadal pisał ładunek żądania do serwera backendu, połączenie zostało przedwcześnie zamknięte przez serwer backendu. Z tego powodu mechanizm przetwarzania wiadomości zgłasza wyjątek java.io.IOException: Broken pipe.
   • Pole Remote:IP:PORT wskazuje adres IP i numer portu rozpoznanego serwera backendu.
   • Atrybut bytesWritten=76295 w powyższym komunikacie o błędzie wskazuje, że procesor wiadomości wysłał do serwera backendu ładunek w rozmiarze 76295 B, gdy połączenie zostało przedwcześnie zamknięte.
   • Atrybut bytesRead=0 wskazuje, że procesor wiadomości nie otrzymał żadnych danych (odpowiedzi) z serwera backendu.
   • Aby dokładniej zbadać ten problem, zbierz obiekt tcpdump z serwera backendu lub procesora wiadomości i przeanalizuj go w sposób opisany poniżej.

Korzystanie z tcpdump

1. Przechwyć tcpdump na serwerze backendu lub procesorze wiadomości za pomocą tych poleceń:

   Polecenie pozwalające zebrać tcpdump z serwera backendu:

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

   Polecenie służące do zebrania adresu tcpdump z procesora wiadomości:

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

2. Przeanalizuj zarejestrowane dane (tcpdump):

   Przykładowe dane wyjściowe tcpdump (zebrane w procesie przetwarzania wiadomości):

   

   W powyższym elemencie tcpdump możesz zobaczyć:

   1. W pakiecie 4 procesor wiadomości wysłał żądanie POST do serwera backendu.
   2. W pakiecie 5, 8, 9, 10 i 11 procesor wiadomości nadal wysyłał ładunek żądania do serwera backendu.
   3. W pakietach 6 i 7 serwer backendu wysłał odpowiedź ACK na część ładunku żądania otrzymanego od podmiotu przetwarzającego wiadomości.
   4. Jednak w pakiecie 12 zamiast ACK dla odebranych pakietów danych aplikacji, a następnie ładunku odpowiedzi, serwer backendu odpowiada FIN ACK, inicjując zamknięcie połączenia.
   5. Wskazuje to wyraźnie, że serwer backendu przedwcześnie zamyka połączenie, gdy procesor wiadomości nadal wysyłał ładunek żądania.
   6. Powoduje to, że podmiot przetwarzający wiadomości rejestruje błąd IOException: Broken Pipei zwraca klientowi 503.

Rozdzielczość

1. Skontaktuj się z zespołem ds. aplikacji lub sieci (albo z nim), aby przeanalizować i rozwiązać problem z przedwczesnym rozłączaniem po stronie serwera backendu.
2. Zadbaj o to, aby aplikacja serwera backendu nie przekraczała limitu czasu ani nie resetowała połączenia przed odebraniem całego ładunku żądania.
3. Jeśli masz pośrednie urządzenie sieciowe lub warstwę między Apigee a serwerem backendu, sprawdź, czy nie przekraczają one limitu czasu, zanim zostanie odebrany cały ładunek żądania.

Jeśli problem nadal występuje, przejdź do artykułu Musisz zebrać informacje diagnostyczne.

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 503
• Plik śledzenia zawierający żądanie z błędem 503 Service Unavailable
• Jeśli błędy 503 nie występują obecnie, podaj informacje o strefie czasowej, w których wystąpiły błędy 503 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 503 błędu
• Pakiet proxy 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
• Okres z informacjami o strefie czasowej, w których wystąpiły błędy 503
• Dane Tcpdumps zebrane z procesorów wiadomości i serwera backendu w momencie wystąpienia błędu