500 Wewnętrzny błąd serwera

Wyświetlasz dokumentację Apigee Edge.
Przejdź do dokumentacji Apigee X. info

Filmy

Obejrzyj te filmy, aby dowiedzieć się więcej o rozwiązywaniu błędów 500 Internal Server Error.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 500 z komunikatem "Internal Server Error" w odpowiedzi na wywołania interfejsu API. Błąd 500 Internal Server Error może być spowodowany błędem podczas wykonywania dowolnej zasady w Edge lub błędem na serwerze docelowym/backendu.

Kod stanu HTTP 500 to ogólna odpowiedź o błędzie. Oznacza to, że serwer napotkał an 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

Może pojawić się ten komunikat o błędzie:

HTTP/1.1 500 Internal Server Error

W niektórych przypadkach możesz zobaczyć inny komunikat o błędzie, który zawiera więcej szczegółów. Oto przykładowy komunikat o błędzie:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

Możliwe przyczyny

Błąd 500 Internal Server Error może być spowodowany wieloma różnymi przyczynami. W Edge, przyczyny można podzielić na 2 główne kategorie w zależności od tego, gdzie wystąpił błąd:

Błąd wykonania zasady Edge

Z jakiegoś powodu zasada Policy w serwerze proxy interfejsu API może się nie powieść. W tej sekcji wyjaśniamy, jak rozwiązać problem, jeśli błąd 500 Internal Server Error występuje podczas wykonywania zasady.

Diagnostyka

Czynności diagnostyczne dla użytkowników chmury prywatnej i publicznej

Jeśli masz sesję interfejsu śledzenia dla błędu:

1. Sprawdź, czy błąd został spowodowany wykonaniem zasady. Szczegółowe informacje znajdziesz w artykule Określanie źródła problemu.
2. Jeśli błąd wystąpił podczas wykonywania zasady, kontynuuj. Jeśli błąd został spowodowany przez serwer backendu, przejdź do sekcji Błąd na serwerze backendu.
3. W śledzeniu wybierz żądanie do interfejsu API, które kończy się niepowodzeniem z powodu błędu 500 Internal Server Error.
4. Sprawdź żądanie i wybierz konkretną zasadę, która się nie powiodła, lub przepływ o nazwie "Błąd", który następuje bezpośrednio po nieudanej zasadzie w śledzeniu.
5. Więcej informacji o błędzie znajdziesz, sprawdzając pole „error” w sekcji Właściwości lub treść błędu.
6. Na podstawie zebranych informacji o błędzie spróbuj ustalić jego przyczynę.

Czynności diagnostyczne tylko dla użytkowników chmury prywatnej

Jeśli nie masz sesji interfejsu śledzenia:

1. Sprawdź, czy błąd wystąpił podczas wykonywania zasady. Szczegółowe informacje znajdziesz w artykule Określanie źródła problemu.
2. Jeśli błąd został spowodowany wykonaniem zasady, kontynuuj. Jeśli błąd wystąpił podczas wykonywania zasady wykonania, kontynuuj. Jeśli błąd został spowodowany przez serwer backendu, przejdź do sekcji Błąd na serwerze backendu.
3. Aby określić zasadę, która się nie powiodła w serwerze proxy interfejsu API, oraz unikalny identyfikator wiadomości żądania, użyj dzienników dostępu NGINX zgodnie z opisem w artykule Określanie źródła problemu.
4. Sprawdź dzienniki procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log) i wyszukaj w nich unikalny identyfikator wiadomości żądania.
5. Jeśli znajdziesz unikalny identyfikator wiadomości żądania, sprawdź, czy możesz uzyskać więcej informacji o przyczynie niepowodzenia.

Rozwiązanie

Jeśli udało Ci się ustalić przyczynę problemu z zasadą, spróbuj go rozwiązać, poprawiając zasadę i wdrażając ponownie serwer proxy.

Z poniższych przykładów dowiesz się, jak określić przyczynę i rozwiązanie różnych problemów.

Jeśli potrzebujesz dodatkowej pomocy w rozwiązywaniu błędu 500 Internal Server Error lub podejrzewasz że problem występuje w Edge, skontaktuj się z zespołem pomocy Apigee Support.

Przykład 1. Niepowodzenie zasady wywołania usługi z powodu błędu na serwerze backendu

Jeśli wywołanie serwera backendu nie powiedzie się w ramach zasady wywołania usługi z powodu dowolnego błędu, np. 4XX lub 5XX, zostanie to potraktowane jako błąd 500 Internal Server Error.

1. Oto przykład, w którym usługa backendu nie działa z powodu błędu 404 w ramach zasady wywołania usługi. Do użytkownika końcowego jest wysyłany ten komunikat o błędzie:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }

2. Ta sesja interfejsu śledzenia pokazuje kod stanu 500 spowodowany błędem w zasadzie wywołania usługi:

   

3. W tym przykładzie właściwość „error” zawiera przyczynę niepowodzenia zasady wywołania usługi jako „ResponseCode 404 is treated as error” (Kod odpowiedzi 404 jest traktowany jako błąd). Ten błąd może wystąpić, jeśli zasób, do którego uzyskiwany jest dostęp za pomocą adresu URL serwera backendu w zasadzie wywołania usługi, jest niedostępny.
4. Sprawdź dostępność zasobu na serwerze backendu. Może być tymczasowo lub trwale niedostępny albo został przeniesiony w inne miejsce.

Rozwiązanie przykładu 1

1. Sprawdź dostępność zasobu na serwerze backendu. Może być tymczasowo lub trwale niedostępny albo został przeniesiony w inne miejsce.
2. Popraw adres URL serwera backendu w zasadzie wywołania usługi, aby wskazywał prawidłowy i istniejący zasób.
3. Jeśli zasób jest tylko tymczasowo niedostępny, spróbuj wysłać żądanie do interfejsu API, gdy zasób będzie dostępny.

Przykład 2. Niepowodzenie zasady wyodrębniania zmiennych

Przyjrzyjmy się teraz innemu przykładowi, w którym błąd 500 Internal Server Error jest spowodowany błędem w zasadzie wyodrębniania zmiennych. Zobaczmy, jak rozwiązać ten problem.

1. Ten ślad w sesji interfejsu pokazuje kod stanu 500 spowodowany błędem w zasadzie wyodrębniania zmiennych:

   

2. Wybierz zasadę wyodrębniania zmiennych, która się nie powiodła, przewiń w dół i sprawdź sekcję "Error Content", aby uzyskać więcej informacji:
   
   
3. Treść błędu wskazuje, że zmienna„serviceCallout.oamCookieValidationResponse” nie jest dostępna w zasadzie wyodrębniania zmiennych. Jak wskazuje nazwa zmiennej, powinna ona zawierać odpowiedź poprzedniej zasady wywołania usługi.
4. W śledzeniu wybierz zasadę wywołania usługi. Może się okazać, że zmienna "serviceCallout.oamCookieValidationResponse" nie została ustawiona. Oznacza to, że wywołanie usługi backendu nie powiodło się, co spowodowało, że zmienna odpowiedzi jest pusta.
5. Mimo że zasada wywołania usługi nie powiodła się, wykonywanie zasad po zasadzie wywołania usługi jest kontynuowane, ponieważ flaga „continueOnError” w zasadzie wywołania usługi jest ustawiona na true, jak pokazano poniżej:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>

6. Zanotuj unikalny identyfikator wiadomości "X-Apigee.Message-ID" dla tego konkretnego żądania interfejsu API ze śledzenia:
   1. Wybierz fazę „Analytics Data Recorded” (Zapisane dane Analytics) z żądania.
   2. Przewiń w dół i zanotuj wartość X-Apigee.Message-ID.

   

7. Wyświetl dziennik procesora komunikatów (/opt/apigee/var/log/edge-message-processor/system.log) i wyszukaj w nim unikalny identyfikator wiadomości zanotowany w kroku 6. W przypadku tego konkretnego żądania interfejsu API zaobserwowano ten komunikat o błędzie:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

   Powyższy błąd wskazuje, że zasada wywołania usługi nie powiodła się z powodu błędu przekroczenia limitu czasu połączenia podczas łączenia z serwerem backendu.

8. Aby określić przyczynę błędu przekroczenia limitu czasu połączenia, wykonaj polecenie telnet na serwerze backendu z procesorów komunikatów. Polecenie telnet zwróciło błąd „Connection timed out” (Przekroczono limit czasu połączenia), jak pokazano poniżej:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

   Ten błąd występuje zwykle w tych okolicznościach:

   • Gdy serwer backendu nie jest skonfigurowany tak, aby zezwalał na ruch z procesorów wiadomości Edge.
   • Jeśli serwer backendu nie nasłuchuje na określonym porcie.

   W powyższym przykładzie, mimo że zasada wyodrębniania zmiennych nie powiodła się, rzeczywistą przyczyną było to, że Edge nie mógł połączyć się z serwerem backendu w zasadzie wywołania usługi. Przyczyną tego niepowodzenia było to, że serwer backendu nie był skonfigurowany tak, aby zezwalał na ruch z procesorów wiadomości Edge.

   Twoja zasada wyodrębniania zmiennych będzie działać inaczej i może się nie powieść z innego powodu. Możesz odpowiednio rozwiązać problem w zależności od przyczyny niepowodzenia zasady wyodrębniania zmiennych, sprawdzając komunikat we właściwości error.

Rozwiązanie przykładu 2

1. Odpowiednio napraw przyczynę błędu lub niepowodzenia w zasadzie wyodrębniania zmiennych.
2. W powyższym przykładzie rozwiązaniem było poprawienie konfiguracji sieci, aby zezwolić na ruch z procesorów wiadomości Edge na serwer backendu. W tym celu dodano adresy IP procesorów wiadomości do listy dozwolonych na konkretnym serwerze backendu. Na przykład, w systemie Linux możesz użyć iptables, aby zezwolić na ruch z adresów IP procesora wiadomości na serwerze backendu.

Przykład 3. Niepowodzenie zasady JavaCallout

Przyjrzyjmy się teraz jeszcze jednemu przykładowi, w którym błąd 500 Internal Server Error jest spowodowany błędem w zasadzie Java Callout. Zobaczmy, jak rozwiązać ten problem.

1. Ten ślad interfejsu pokazuje kod stanu 500 spowodowany błędem w zasadzie Java Callout:

   

2. Wybierz przepływ o nazwie „Error” (Błąd), a następnie zasadę Java Callout, która się nie powiodła aby uzyskać szczegóły błędu, jak pokazano na ilustracji poniżej:

   

3. W tym przykładzie właściwość "error" w sekcji Właściwości wskazuje że niepowodzenie jest spowodowane użyciem wygasłego hasła podczas łączenia z bazą danych Oracle z poziomu zasady JavaCallout. Twoje wywołanie Java będzie działać inaczej i będzie wypełniać inny komunikat we właściwości error.
4. Sprawdź kod zasady JavaCallout i potwierdź prawidłową konfigurację, której należy użyć.

Rozwiązanie przykładu 3

Odpowiednio popraw kod lub konfigurację wywołania Java, aby uniknąć wyjątku środowiska wykonawczego. W powyższym przykładzie niepowodzenia wywołania Java, aby rozwiązać problem, należy użyć prawidłowego hasła do połączenia z bazą danych Oracle.

Błąd na serwerze backendu

Błąd 500 Internal Server Error może też pochodzić z serwera backendu. W tej sekcji wyjaśniamy, jak rozwiązać problem, jeśli błąd pochodzi z serwera backendu.

Diagnostyka

Czynności diagnostyczne dla wszystkich użytkowników

Przyczyny innych błędów backendu mogą być bardzo różne. Każdą sytuację musisz zdiagnozować osobno.

1. Sprawdź, czy błąd został spowodowany przez serwer backendu. Szczegółowe informacje znajdziesz w artykule Określanie źródła problemu.
2. Jeśli błąd został spowodowany przez serwer backendu, kontynuuj. Jeśli błąd wystąpił podczas wykonywania zasady, przejdź do sekcji Błąd wykonania zasady Edge Policy.
3. Wykonaj te czynności w zależności od tego, czy masz dostęp do sesji śledzenia dla nieudanego interfejsu API, czy też backend jest serwerem Node.js:

Jeśli nie masz sesji śledzenia dla nieudanego wywołania interfejsu API:

1. Jeśli ślad interfejsu nie jest dostępny w przypadku nieudanego żądania, sprawdź dzienniki serwera backendu aby uzyskać szczegółowe informacje o błędzie.
2. Jeśli to możliwe, włącz tryb debugowania na serwerze backendu, aby uzyskać więcej informacji o błędzie i jego przyczynie.

Jeśli masz sesję śledzenia dla nieudanego wywołania interfejsu API:

Jeśli masz sesję śledzenia, te czynności pomogą Ci zdiagnozować problem.

1. W narzędziu śledzenia wybierz żądanie do interfejsu API, które nie powiodło się z powodu błędu 500 Internal Server Error.
2. W nieudanym żądaniu do interfejsu API wybierz fazę „Response received from target server” (Otrzymano odpowiedź z serwera docelowego), jak pokazano na ilustracji poniżej:

   

3. Aby uzyskać szczegółowe informacje o błędzie, sprawdź sekcję "Response Content" (Treść odpowiedzi).

   

4. W tym przykładzie treść odpowiedzi, która jest kopertą SOAP, zawiera ciąg błędu „Not Authorized” (Brak autoryzacji). Najbardziej prawdopodobną przyczyną tego problemu jest to, że użytkownik nie przekazuje do serwera backendu prawidłowych danych logowania (nazwy użytkownika/hasła, tokena dostępu itp.). Ten problem można rozwiązać, przekazując do serwera backendu prawidłowe dane logowania.

Jeśli backend jest serwerem Node.js:

1. Jeśli backend jest serwerem backendu Node.js, sprawdź dzienniki Node.js dla konkretnego serwera proxy interfejsu API w interfejsie Edge (zarówno użytkownicy chmury publicznej, jak i prywatnej mogą sprawdzać dzienniki Node.js). Jeśli jesteś użytkownikiem chmury prywatnej Edge, możesz też sprawdzić dzienniki procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby uzyskać więcej informacji o błędzie.
   
   

   Opcja dzienników NodeJS w interfejsie Edge – karta Przegląd serwera proxy interfejsu API

   

Rozwiązanie

1. Gdy poznasz przyczynę błędu, napraw problem na serwerze backendu.
2. Jeśli jest to serwer backendu Node.js:
   1. Sprawdź, czy błąd jest zgłaszany przez Twój kod niestandardowy, i jeśli to możliwe, rozwiąż problem.
   2. Jeśli błąd nie jest zgłaszany przez Twój kod niestandardowy lub potrzebujesz pomocy, skontaktuj się z zespołem pomocy Apigee .

Jeśli potrzebujesz dodatkowej pomocy w rozwiązywaniu błędu 500 Internal Server Error lub podejrzewasz że problem występuje w Edge, skontaktuj się z zespołem pomocy Apigee Support.

Określanie źródła problemu

Aby sprawdzić, czy błąd 500 Internal Server Error został zgłoszony podczas wykonywania zasady w serwerze proxy interfejsu API czy przez serwer backendu, wykonaj jedną z tych procedur.

Korzystanie ze śledzenia w interfejsie

Uwaga: czynności opisane w tej sekcji mogą wykonywać zarówno użytkownicy chmury publicznej, jak i prywatnej.

1. Jeśli problem nadal występuje, włącz śledzenie w interfejsie dla danego interfejsu API.
2. Gdy zarejestrujesz ślad, wybierz żądanie do interfejsu API, które pokazuje kod odpowiedzi jako 500.
3. Przejdź przez wszystkie fazy nieudanego żądania do interfejsu API i sprawdź, która faza zwraca błąd 500 Internal Server Error:
   1. Jeśli błąd jest zgłaszany podczas wykonywania zasady, przejdź do sekcji Błąd wykonania zasady Edge.
   2. Jeśli serwer backendu odpowiedział błędem 500 Internal Server Error, przejdź do sekcji Błąd na serwerze backendu.

Korzystanie z monitorowania interfejsu API

Uwaga: czynności opisane w tej sekcji mogą wykonywać tylko użytkownicy chmury publicznej.

Monitorowanie interfejsu API umożliwia szybkie wyodrębnianie obszarów problemowych w celu diagnozowania błędów, problemów z wydajnością i opóźnieniami oraz ich źródła, np. aplikacji deweloperów, serwerów proxy interfejsu API, serwerów docelowych backendu lub platformy interfejsu API.

Wykonaj przykładowy scenariusz, który pokazuje, jak rozwiązywać problemy 5xx z interfejsami API za pomocą monitorowania interfejsu API. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba kodów stanu 500 lub błędów steps.servicecallout.ExecutionFailed przekroczy określony próg.

Korzystanie z dzienników dostępu NGINX

Uwaga: czynności opisane w tej sekcji są przeznaczone tylko dla użytkowników chmury prywatnej Edge.

Możesz też sprawdzić dzienniki dostępu NGINX, aby określić, czy kod stanu 500 został zgłoszony podczas wykonywania zasady w serwerze proxy interfejsu API czy przez serwer backendu. Jest to szczególnie przydatne, jeśli problem wystąpił w przeszłości lub jeśli występuje sporadycznie i nie możesz zarejestrować śladu w interfejsie. Aby określić te informacje na podstawie dzienników dostępu NGINX:

1. Sprawdź dzienniki dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
2. Sprawdź, czy w określonym czasie występują błędy 500 w przypadku konkretnego serwera proxy interfejsu API.
3. Jeśli występują błędy 500, sprawdź, czy jest to błąd zasady czy serwera docelowego, jak pokazano poniżej:

   Przykładowy wpis pokazujący błąd zasady

   

   Przykładowy wpis pokazujący błąd serwera docelowego

   

4. Gdy ustalisz, czy jest to błąd zasady czy serwera docelowego:
   1. Jeśli jest to błąd zasady, przejdź do sekcji Błąd wykonania zasady Edge jeśli jest to błąd zasady.
   2. Jeśli jest to błąd serwera docelowego przejdź do sekcji Błąd na serwerze backendu.