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

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

Filmy

Wideo Opis
500 Wewnętrzny błąd serwera – spowodowany przez backend Demonstracja 500 Internal Server Error w czasie rzeczywistym wywołana przez serwer backendu wraz z instrukcjami rozwiązywania problemów.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 500 z komunikatem Internal Server Error jako odpowiedź na wywołania interfejsu API.

Kod stanu HTTP 500 to ogólna odpowiedź na błąd. Oznacza to, że serwer wystąpił 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 poniżej:

Przykład 1

Przykładowa odpowiedź serwera backendu 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 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 powodu błędu wiele przyczyn. Z tego poradnika dowiesz się, jak rozwiązywać problemy za pomocą typowych czynności. niezależnie od jego przyczyny.

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 ulec awarii. Użytkownicy Edge Private Cloud i użytkownicy chmury publicznej

Typowe kroki diagnostyki

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

Monitorowanie interfejsów API

Procedura 1. Korzystanie z 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 uprawnieniami odpowiednią rolę.

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

  3. Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
  4. Wybierz okres, w którym zaobserwowano błędy.

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

  6. Wybierz komórkę, która zawiera kod błędu messaging.adaptors.http.flow.ErrorResponseCode jak pokazano na ekranie poniżej:

    ( wyświetl większy obraz)

  7. Informacje o kodzie błędu messaging.adaptors.http.flow.ErrorResponseCode jest wyświetlany jako 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:
    • Request Message ID (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 śledzenia

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

  1. Włącz sesję śledzenia i wykonaj jedną z tych czynności:
    • Poczekaj na pojawienie się 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 odtworzyć problem. 500 Internal Server Error

  2. Sprawdź, czy opcja Show all FlowInfos jest włączona:

  3. Wybierz jedno z nieudanych żądań i sprawdź log czasu.
  4. Przejdź przez różne fazy śledzenia i znajdź miejsca, w których wystąpił błąd.

  5. Błąd pojawia się zwykle w ciągu po odpowiedzi odebranej z serwera docelowego. faza, jak poniżej:

    ( wyświetl większy obraz)

  6. Przejdź do fazy AX (zarejestrowane dane Analytics) i kliknij ją.

  7. Przewiń w dół do sekcji Phase Details Response Headers (Nagłówki odpowiedzi szczegółów etapu) i określ wartości X-Apigee-fault-code i X-Apigee-fault-source; X-Apigee-Message-ID zgodnie z poniższym przykładem:

    ( wyświetl większy obraz)

  8. Zwróć uwagę na 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 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, aby określić Kluczowe informacje o HTTP 500 Internal Server Error.

  2. Sprawdź logi dostępu NGINX:

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

  3. Wyszukaj błędy (500) z kodem błędu messaging.adaptors.http.flow.ErrorResponseCode w określonym czasie (jeśli problem wystąpił w wcześniejsze) lub jeśli jakieś żądania z usługą 500 nadal kończą się niepowodzeniem.

  4. Jeśli znajdziesz błędy 500 w dopasowaniu X-Apigee-fault-code wartość messaging.adaptors.http.flow.ErrorResponseCode, a następnie określić wartość źródła X-Apigee-fault-source..

    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 zawiera następujące wartości dla: X-Apigee-fault-code i X-Apigee-fault-code

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

Przyczyna: błąd na serwerze backendu

Diagnostyka

Pole 500 Internal Server Error, na które odpowiada serwer backendu, może być z różnych przyczyn. Każdą sytuację należy diagnozować z osobna.

  1. Określ kod błędu, źródło błędu dla błędu zaobserwowanego za pomocą monitorowania interfejsów API. narzędzia śledzenia lub dziennikó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 – messaging.adaptors.http.flow.ErrorResponseCode, oznacza to, że serwer backendu zwraca błąd.
  3. Aby zdiagnozować przyczynę problemu, wykonaj jedną z tych czynności:

    Śledzenie

    Za pomocą logu czasu:

    Jeśli masz sesję śledzenia błędu, wykonaj te czynności:

    1. W logu czasu wybierz żądanie do interfejsu API, którego nie udało się zrealizować 500 Internal Server Error

    2. Wybierz etap Odpowiedź otrzymana z serwera docelowego z nieudane żądanie API, jak widać na ilustracji poniżej:

      ( wyświetl większy obraz)

    3. Przewiń w dół do sekcji Etapy 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ę na komunikat o błędzie serwera backendu Brak autoryzacji. Oznacza to, że użytkownik mógł przesłać nieprawidłowe dane danych logowania i dlatego pojawia się ten błąd.

    .

    Serwer backendu połączeń

    Bezpośrednie wywołanie serwera backendu:

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

    • Sprawdź, czy otrzymujesz tę samą wartość 500 Internal Server Error odpowiedź jako odebrana, gdy żądanie zostało przesłane za pomocą Apigee Edge
    • Sprawdź komunikat o błędzie (odpowiedź) odebrany 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 dane uwierzytelniające, które należy przekazać do serwera backendu w ramach żądania.
    2. Jeśli usługa backendu jest dostępna publicznie, możesz używać curl, Postman lub dowolnego innego klienta REST i wywołaj metodę lub interfejs API serwera backendu.

    3. Jeśli serwer backendu jest dostępny tylko z procesora wiadomości, możesz za pomocą polecenia curl, Postman lub innego klienta REST i wywołaj metodę API serwera backendu bezpośrednio z procesora wiadomości.

    4. Sprawdź, czy usługa backendu rzeczywiście zwraca kod 500 Internal Server Error, i sprawdź komunikat o błędzie (odpowiedź) zwrócony przez serwer backendu i 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 oraz przyczyna.
    2. Jeśli to możliwe, włącz tryb debugowania na serwerze backendu, aby uzyskać więcej informacji o błędzie i przyczynie.

  4. Sprawdź, czy używasz łańcuch serwerów proxy w określonym docelowym punkcie końcowym serwera proxy interfejsu API, w którym wystąpiła awaria; czyli jeśli serwer docelowy/docelowy punkt końcowy wywołuje inny serwer proxy Apigee Edge Aby to sprawdzić:

    1. Jeśli masz ślad nieprawidłowego żądania, przejdź do sekcji Żądanie wysłane do etapu docelowego serwera i kliknij Pokaż skręt.

    2. Otworzy się okno Curl for Request Sent to Target Server (Adres URL żądania wysłanego do serwera docelowego), w którym może określić alias hosta serwera docelowego.
    3. Sprawdź docelowy punkt końcowy serwera proxy interfejsu API i sprawdź, czy serwer backendu URL lub nazwa hosta na serwerze docelowym wskazuje inny serwer proxy lub Twój z serwera backendu.
    4. Jeśli alias hosta serwera docelowego wskazuje alias hosta wirtualnego, jest łańcuch serwerów proxy. W takim przypadku musisz powtórzyć wszystkie powyższe kroki, aby łańcuchowy serwer proxy, dopóki nie ustalisz, co tak naprawdę jest przyczyną żądania 500 Internal Server Error. W takich przypadkach 500 Internal Server Error może występują w innych łańcuchowych serwerach proxy na innych etapach, które mogą być zdiagnozowane i można rozwiązać, korzystając z instrukcji podanych w tym poradniku lub w Poradnik dotyczący błędu wewnętrznego serwera 500.
    5. Jeśli alias hosta serwera docelowego wskazuje Twój serwer backendu, otwórz Rozwiązanie.

Rozdzielczość

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

W przykładzie powyżej może być konieczne poproszenie użytkowników o przekazanie prawidłowych danych logowania, aby rozwiązać problem. tego problemu.

Najważniejsze kwestie

  1. Rzeczywisty komunikat o błędzie zwrócony przez serwer backendu dla 500 Internal Server Error można wyświetlić tylko wtedy, gdy zarejestrujesz sesję śledzenia dla błędu żądań.
  2. Odpowiedź serwera backendu nie będzie rejestrowana w usłudze API Monitoring, logach dostępu NGINX ani Dzienniki procesora wiadomości ze względów bezpieczeństwa.
  3. Możesz przejrzeć logi serwera backendu lub włączyć tryb debugowania w backendzie, aby uzyskać więcej informacji szczegóły błędu 500 Internal Server Error lub wyświetl zwrócony komunikat o błędzie przez serwer backendu.

Musi zbierać informacje diagnostyczne

Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zwróć uwagę na 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 serwera proxy interfejsu API
  • Wykonaj polecenie curl, aby odtworzyć błąd 500
  • Plik śledzenia zawierający żądania za pomocą funkcji 500 Internal Server Error
  • Jeśli błędy typu 500 nie występują obecnie, podaj czas okres z informacjami o strefie czasowej, gdy w przeszłości wystąpiły błędy 500.

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 500 błędu
  • Pakiet serwerów proxy interfejsu API
  • Plik śledzenia zawierający żądania za pomocą funkcji 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 wartościami rzeczywistymi.

  • Logi systemowe 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 500.