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

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

Filmy

Wideo Opis
500 Wewnętrzny błąd serwera – spowodowany przez backend Demonstracja działania 500 Internal Server Error w czasie rzeczywistym powodowana przez serwer backendu oraz czynności potrzebne do rozwiązania problemu i usunięcia błędu.

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 warunek, który uniemożliwił mu zrealizowanie żą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

Możesz też zobaczyć komunikat o błędzie podobny do tego:

Przykład 1

Przykładowa odpowiedź serwera backendu nr 1

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

Przykład 2

Przykładowa odpowiedź serwera backendu nr 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

Serwer backendu może zwrócić wartość 500 Internal Server Error z kilku powodów. Ten poradnik wyjaśnia, jak rozwiązać ten problem bez względu na jego przyczynę, korzystając z typowych czynności.

Możliwe przyczyny tego problemu:

Przyczyna Opis Instrukcje rozwiązywania problemów dotyczące
Błąd na serwerze backendu Z jakiegoś powodu serwer backendu może nie działać. Użytkownicy chmury prywatnej i publicznej Cloud

Najczęstsze kroki diagnostyki

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

Monitorowanie interfejsów API

Procedura 1. Korzystanie z monitorowania interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsu API:

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

  2. Przełącz się na organizację, w której chcesz zbadać problem.

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

  5. Porównaj kod błędu z czasem.

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

    ( wyświetl większy obraz)

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

    ( wyświetl większy obraz)

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

    ( wyświetl większy obraz)

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

Trace

Procedura 2. Korzystanie z narzędzia do śledzenia

Aby zdiagnozować błąd za pomocą narzędzia do śledzenia:

  1. Włącz sesję śledzenia i
    • Poczekaj na wystąpienie błędu 500 Internal Server Error z kodem błędu messaging.adaptors.http.flow.ErrorResponseCode lub
    • Jeśli możesz odtworzyć problem, wykonaj wywołanie interfejsu API, aby go odtworzyć. 500 Internal Server Error

  2. Sprawdź, czy opcja Show all FlowInfos (Pokaż wszystkie informacje) jest włączona:

  3. Wybierz 1 z nieudanych żądań i sprawdź log czasu.
  4. Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.

  5. Błąd pojawia się zwykle w przepływie po fazie otrzymanej z serwera docelowego, jak pokazano poniżej:

    ( wyświetl większy obraz)

  6. Przejdź do fazy AX (rejestrowane dane Analytics) w logu czasu i kliknij ją.

  7. Przewiń w dół do sekcji Szczegóły nagłówków odpowiedzi i ustal wartości X-Apigee-fault-code, X-Apigee-fault-source oraz X-Apigee-Message-ID, jak pokazano poniżej:

    ( wyświetl większy obraz)

  8. Zapisz 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 dzienników dostępu NGINX

Aby zdiagnozować błąd przy użyciu logów dostępu NGINX:

  1. Jeśli jesteś użytkownikiem Private Cloud, możesz użyć logów dostępu NGINX do określenia kluczowych informacji o HTTP 500 Internal Server Error.

  2. Sprawdź logi dostępu do NGINX:

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

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

  4. Jeśli znajdziesz błędy 500 z kodem X-Apigee-fault-code pasującym do wartości X-Apigee-fault-code , sprawdź wartość źródła błędów X-Apigee-fault-code .

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

    ( wyświetl większy obraz)

    Powyższy przykładowy wpis z logu dostępu NGINX ma następujące wartości kodu X-Apigee-fault-code i X-Apigee-fault-code :

    nagłówków, Wartość
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
    X-Apigee-fault-source target

Przyczyna: błąd serwera backendu

Diagnostyka

Odpowiedź 500 Internal Server Error przez serwer backendu może mieć kilka przyczyn. Musisz zdiagnozować każdą sytuację oddzielnie.

  1. Znajdź kod błędu, źródło błędu dla błędu zaobserwowanego za pomocą interfejsu API Monitoring, narzędzia do śledzenia lub logów dostępu NGINX zgodnie z opisem w częstych krokach diagnostyki.
  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, wykonaj jedną z tych czynności:

    Trace

    Przy użyciu logu czasu:

    Jeśli masz sesję śledzenia błędów, wykonaj te czynności:

    1. W logu czasu wybierz żądanie do interfejsu API, które zakończyło się niepowodzeniem (500 Internal Server Error).

    2. Wybierz etap Odpowiedź otrzymana z serwera docelowego w nieudanym żądaniu do interfejsu API, jak pokazano na ilustracji poniżej:

      ( wyświetl większy obraz)

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

      Przykładowa odpowiedź:

      <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 tej odpowiedzi zwróć uwagę, że komunikat o błędzie z serwera backendu to Not Authorization (Brak autoryzacji). Oznacza to, że użytkownik mógł podać nieprawidłowe dane logowania i dlatego pojawia się ten błąd.

    Wywołaj serwer backendu

    Bezpośrednie wywołanie serwera backendu:

    Możesz wykonać bezpośrednie wywołanie do serwera backendu i:

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

    Aby wysłać bezpośrednie wywołanie do serwera backendu, wykonaj te czynności:

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

    3. Jeśli do serwera backendu można uzyskać dostęp tylko z poziomu procesorów do przetwarzania wiadomości, możesz użyć polecenia curl, aplikacji Postman lub innego klienta REST i wywoływać interfejs API serwera backendu bezpośrednio z tego procesora.

    4. Sprawdź, czy usługa backendu faktycznie zwraca 500 Internal Server Error, a następnie sprawdź komunikat o błędzie (odpowiedź) zwrócony przez serwer backendu i ustal przyczynę tego błędu.

    Logi serwera backendu

    Korzystanie z 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 informacji o błędzie i jego przyczynie.

  4. Sprawdź, czy w określonym punkcie końcowym niedziałającego serwera proxy interfejsu API używasz łańcucha serwerów proxy; to znaczy, czy serwer docelowy/docelowy punkt końcowy wywołuje inny serwer proxy w Apigee Edge. Aby to sprawdzić:

    1. Jeśli masz dane śledzenia 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 na żądanie wysłane do serwera docelowego), w którym możesz określić alias hosta serwera docelowego.
    3. Sprawdź docelowy punkt końcowy serwera proxy interfejsu API i sprawdź, czy adres URL serwera backendu lub nazwa hosta na serwerze docelowym wskazuje inny serwer proxy lub Twój własny serwer backendu.
    4. Jeśli alias hosta serwera docelowego wskazuje alias hosta wirtualnego, jest to łańcuch serwerów proxy. W takim przypadku musisz powtórzyć wszystkie powyższe kroki dla połączonego serwera proxy, aż dowiesz się, co faktycznie powoduje błąd 500 Internal Server Error. W tych przypadkach 500 Internal Server Error może wystąpić w innych łańcuchach serwerów proxy na innych etapach, które można zdiagnozować i rozwiązać, korzystając z instrukcji podanych w tym scenariuszu lub w poradniku dotyczącym wewnętrznego błędu serwera 500.
    5. Jeśli alias hosta serwera docelowego wskazuje Twój serwer backendu, przejdź do sekcji Rozwiązanie.

Rozdzielczość

Jeśli masz pewność, że błąd 500 pochodzi z serwera backendu, skontaktuj się z zespołem serwera backendu, aby odpowiednio rozwiązać problem.

W celu rozwiązania tego problemu w przypadku omówionego powyżej przykładu może być konieczne poproszenie użytkowników o podanie prawidłowych danych logowania.

Najważniejsze kwestie

  1. Rzeczywisty komunikat o błędzie zwrócony przez serwer backendu dla instancji 500 Internal Server Error można wyświetlić tylko wtedy, gdy zarejestrujesz sesję śledzenia dla nieudanych żądań.
  2. Ze względów bezpieczeństwa odpowiedź serwera backendu nie będzie logowana w logach monitorowania interfejsów API, logów dostępu NGINX ani procesora wiadomości.
  3. Możesz przejrzeć logi serwera backendu lub włączyć tryb debugowania w backendzie, aby uzyskać więcej informacji o obiekcie 500 Internal Server Error lub wyświetlić komunikat o błędzie zwrócony przez serwer backendu.

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 500
  • Plik śledzenia zawierający żądania z 500 Internal Server Error
  • Jeśli błędy 500 nie występują obecnie, podaj informacje o strefie czasowej dla okresu, w którym w przeszłości wystąpiły błędy 500.

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 której występują błędy typu 500
  • 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 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 500.