500 – wewnętrzny błąd serwera – serwer backendu

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

Filmy

Wideo Opis
500 Wewnętrzny błąd serwera – spowodowany przez backend Pokazuje w czasie rzeczywistym 500 Internal Server Error spowodowany przez serwer backendu oraz czynności, które należy wykonać, aby rozwiązać ten problem.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 500 z komunikatem Internal Server Error w odpowiedzi na wywołania interfejsu API.

Kod stanu HTTP 500 to ogólna odpowiedź o błędzie. Oznacza to, że serwer napotkał nieoczekiwany stan, który uniemożliwił mu wykonanie żądania. Ten błąd jest zwykle zwracany przez serwer, gdy żaden inny kod błędu nie jest odpowiedni.

Komunikaty o błędach

Aplikacja kliencka otrzymuje ten kod odpowiedzi: 

HTTP/1.1 500 Internal Server Error

Dodatkowo możesz zobaczyć komunikat o błędzie podobny do tego poniżej:

Próbka 1

Przykładowa odpowiedź serwera backendu 1

{"errorMessage":"Sorry either your e-mail or password didn't match.",
"errorParameters":"{}",
"errorCode":"500",
"errorKey":"INVALID_EMAILPASSWORD"}

Próbka 2

Przykładowa odpowiedź serwera backendu 2

<Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

Możliwe przyczyny

500 Internal Server Error może być zwracany przez serwer backendu z wielu powodów. Z tego przewodnika dowiesz się, jak rozwiązywać ten problem, wykonując typowe czynności, niezależnie od jego przyczyny.

Możliwe przyczyny tego problemu:

Przyczyna Opis Instrukcje rozwiązywania problemów, które mają zastosowanie do
Błąd na serwerze backendu Serwer backendu może z jakiegoś powodu ulec awarii. Użytkownicy chmury prywatnej i publicznej Edge

Typowe czynności diagnostyczne

Aby zdiagnozować ten błąd, użyj jednego z tych narzędzi lub metod:

Monitorowanie interfejsów API

Procedura 1. Używanie monitorowania interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsów API:

  1. Zaloguj się w interfejsie Apigee Edge jako użytkownik z odpowiednią rolą.

  2. Przejdź do organizacji, w której chcesz zbadać problem.

  3. Otwórz stronę Analiza > Monitorowanie interfejsów API > Zbadaj.
  4. Wybierz konkretny przedział czasu, w którym wystąpiły błędy.

  5. Wykreśl Kod błędu względem Czasu.

  6. Wybierz komórkę z kodem błędu messaging.adaptors.http.flow.ErrorResponseCode jak pokazano poniżej:

    ( powiększ obraz)

  7. Informacje o kodzie błędu messaging.adaptors.http.flow.ErrorResponseCode są wyświetlane jak poniżej:

    ( powiększ obraz)

  8. Kliknij Wyświetl logi i rozwiń wiersz nieudanego żądania.

    ( powiększ obraz)

  9. W oknie Logi zanotuj te informacje:
    • Identyfikator wiadomości żądania
    • Kod stanu: 500
    • Źródło błędu: target
    • Kod błędu: messaging.adaptors.http.flow.ErrorResponseCode

Śledzenie

Procedura 2. Używanie narzędzia Trace

Aby zdiagnozować błąd za pomocą narzędzia Trace:

  1. Włącz sesję śledzenia i wykonaj jedną z tych czynności:
    • Poczekaj na wystąpienie błędu 500 Internal Server Error z kodem błędu messaging.adaptors.http.flow.ErrorResponseCode.
    • Jeśli możesz odtworzyć problem, wywołaj interfejs API, aby odtworzyć problem 500 Internal Server Error

  2. Sprawdź, czy jest włączona opcja Pokaż wszystkie informacje o przepływach:

  3. Wybierz jedno z nieudanych żądań i sprawdź ślad.
  4. Przejdź przez różne etapy śledzenia i znajdź miejsce, w którym wystąpił błąd.

  5. Błąd zwykle występuje w przepływie po etapie Odpowiedź odebrana z serwera docelowego jak pokazano poniżej:

    ( powiększ obraz)

  6. W śladzie przejdź do etapu AX (Zapisane dane Analytics) i kliknij go.

  7. Przewiń w dół do sekcji Szczegóły etapu Nagłówki odpowiedzi i określ wartości X-Apigee-fault-code i X-Apigee-fault-source oraz X-Apigee-Message-ID jak pokazano poniżej:

    ( powiększ obraz)

  8. Zanotuj wartości X-Apigee-fault-code, X-Apigee-fault-source, i X-Apigee-Message-ID:
    9. Nagłówki odpowiedzi Wartość
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target
    X-Apigee-Message-ID MESSAGE_ID

NGINX

Procedura 3. Używanie logów dostępu NGINX

Aby zdiagnozować błąd za pomocą logów dostępu NGINX:

  1. Jeśli jesteś użytkownikiem chmury prywatnej, możesz użyć logów dostępu NGINX, aby określić kluczowe informacje o błędzie HTTP 500 Internal Server Error.

  2. Sprawdź logi dostępu NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. Sprawdź, czy w określonym czasie (jeśli problem wystąpił w przeszłości) występują błędy 500 z kodem błędu messaging.adaptors.http.flow.ErrorResponseCode lub czy nadal występują żądania, które kończą się niepowodzeniem z kodem 500.

  4. Jeśli znajdziesz błędy 500 z X-Apigee-fault-code pasującym do wartości messaging.adaptors.http.flow.ErrorResponseCode, określ wartość X-Apigee-fault-source.

    Przykładowy błąd 500 z logu dostępu NGINX:

    ( powiększ obraz)

    Powyższy przykładowy wpis z logu dostępu NGINX ma te wartości dla X-Apigee-fault-code i X-Apigee-fault-source:

    Nagłówki Wartość
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Przyczyna: błąd na serwerze backendu

Diagnostyka

Błąd 500 Internal Server Error zwracany przez serwer backendu może być spowodowany wieloma przyczynami. Każdą sytuację musisz zdiagnozować osobno.

  1. Określ kod błędu i źródło błędu zaobserwowanego błędu za pomocą monitorowania interfejsów API, narzędzia Trace lub logów dostępu NGINX zgodnie z opisem w sekcji Typowe czynności diagnostyczne.
  2. Jeśli źródło błędu to target, a kod błędu to messaging.adaptors.http.flow.ErrorResponseCode, oznacza to, że błąd jest zwracany przez serwer backendu.
  3. Aby zdiagnozować przyczynę problemu, możesz wykonać jedną z tych czynności:

    Śledzenie

    Używanie narzędzia Trace:

    Jeśli masz sesję śledzenia dotyczącą niepowodzenia, wykonaj te czynności:

    1. W śladzie wybierz żądanie do interfejsu API, które zakończyło się niepowodzeniem z powodu błędu 500 Internal Server Error.

    2. W nieudanym żądaniu do interfejsu API wybierz etap Odpowiedź odebrana z serwera docelowego jak pokazano na ilustracji poniżej:

      ( powiększ obraz)

    3. Przewiń w dół do sekcji Szczegóły etapu i sprawdź Treść odpowiedzi,która zawiera odpowiedź z serwera backendu.

      Przykładowa treść odpowiedzi:

      <Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <Body>
      <Error>
         <code>500</code>
         <message xml:lang="en-US">Not Authorised(e4138fa0-ec57).</message>
      </Error>
   </Body>
</Envelope>

      W powyższej odpowiedzi zwróć uwagę, że komunikat o błędzie z serwera backendu to Not Authorised (Brak autoryzacji). Oznacza to, że użytkownik mógł podać nieprawidłowe dane logowania i dlatego występuje ten błąd.

    Wywołaj serwer backendu

    Bezpośrednie wywołanie serwera backendu:

    Możesz bezpośrednio wywołać serwer backendu i:

    • Sprawdź, czy otrzymujesz tę samą 500 Internal Server Error odpowiedź co wtedy, gdy żądanie zostało wysłane przez Apigee Edge.
    • Sprawdź komunikat o błędzie (odpowiedź) otrzymany z serwera backendu.

    Aby bezpośrednio wywołać serwer backendu, wykonaj te czynności:

    1. Upewnij się, że masz wszystkie wymagane nagłówki, parametry zapytania i wszelkie dane uwierzytelniające, które należy przekazać do serwera backendu w ramach żądania.
    2. Jeśli usługa backendu jest publicznie dostępna, możesz użyć polecenia curl , Postmana lub innego klienta REST i bezpośrednio wywołać interfejs API serwera backendu.

    3. Jeśli serwer backendu jest dostępny tylko z procesorów komunikatów, możesz użyć polecenia curl, Postmana lub innego klienta REST i bezpośrednio wywołać interfejs API serwera backendu z procesora komunikatów.

    4. Sprawdź, czy usługa backendu rzeczywiście zwraca błąd 500 Internal Server Error, i sprawdź komunikat o błędzie (odpowiedź) zwrócony przez serwer backendu, aby określić przyczynę tego błędu.

    Logi serwera backendu

    Używanie logów serwera backendu

    1. Sprawdź logi serwera backendu i spróbuj uzyskać więcej informacji o błędzie i jego przyczynie.
    2. Jeśli to możliwe, włącz tryb debugowania na serwerze backendu, aby uzyskać więcej szczegółów o błędzie i jego przyczynie.

  4. Sprawdź, czy w konkretnym punkcie końcowym docelowym nieudanego proxy interfejsu API używasz łańcucha proxy, czyli czy serwer docelowy lub punkt końcowy docelowy wywołuje inne proxy w Apigee Edge. Aby to sprawdzić:

    1. Jeśli masz ślad nieudanego żądania, przejdź do etapu Żądanie wysłane do serwera docelowego i kliknij Pokaż Curl.

    2. Otworzy się okno Curl for Request Sent to Target Server (Curl dla żądania wysłanego do serwera docelowego), w którym możesz określić alias hosta serwera docelowego.
    3. Sprawdź punkt końcowy docelowy proxy interfejsu API i sprawdź, czy adres URL serwera backendu lub nazwa hosta na serwerze docelowym wskazuje inne proxy lub Twój serwer backendu.
    4. Jeśli alias hosta serwera docelowego wskazuje alias hosta wirtualnego, jest to łańcuch proxy. W takim przypadku musisz powtórzyć wszystkie powyższe czynności w przypadku proxy w łańcuchu, aż ustalisz, co powoduje błąd 500 Internal Server Error. W takich przypadkach 500 Internal Server Error może wystąpić też na innych etapach w innych proxy w łańcuchu. Możesz go zdiagnozować i rozwiązać, korzystając z instrukcji podanych w tym przewodniku lub w przewodniku 500 Wewnętrzny błąd serwera.
    5. Jeśli alias hosta serwera docelowego wskazuje Twój serwer backendu, przejdź do sekcji Rozwiązanie.

Rozdzielczość

Jeśli stwierdzisz, że błąd 500 pochodzi z serwera backendu, wówczas współpracuj z zespołem serwera backendu, aby odpowiednio rozwiązać ten problem.

W omówionym powyżej przykładzie, aby rozwiązać ten problem, możesz poprosić użytkowników o podanie prawidłowych danych logowania.

Ważne uwagi

  1. Rzeczywisty komunikat o błędzie zwracany przez serwer backendu w przypadku błędu 500 Internal Server Error można wyświetlić tylko wtedy, gdy masz sesję śledzenia dotyczącą nieudanych żądań.
  2. Ze względów bezpieczeństwa odpowiedź serwera backendu nie będzie rejestrowana w monitorowaniu interfejsów API, logach dostępu NGINX ani w logach procesora komunikatów.
  3. Aby uzyskać więcej informacji o 500 Internal Server Error lub wyświetlić komunikat o błędzie zwrócony przez serwer backendu, możesz sprawdzić logi serwera backendu lub włączyć na nim tryb debugowania.

Informacje diagnostyczne, które musisz zebrać

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
  • Pełne polecenie curl, aby odtworzyć błąd 500
  • Plik śledzenia zawierający żądania z 500 Internal Server Error
  • Jeśli błędy 500 nie występują obecnie, podaj przedział czasu z informacjami o strefie czasowej, w którym błędy 500 występowały w przeszłości.

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

  • Pełny komunikat o błędzie zaobserwowany w przypadku nieudanych żądań
  • Nazwa organizacji, środowiska i proxy interfejsu API, w przypadku których występują 500 błędy
  • Pakiet proxy interfejsu API
  • Plik śledzenia zawierający żądania z 500 Internal Server Error
  • Logi dostępu NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    Gdzie: ORG, ENV, i PORT# są zastępowane rzeczywistymi wartościami.

  • Logi systemowe procesora komunikatów /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 500.