500 Wewnętrzny błąd serwera

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

Filmy

Obejrzyj poniższe filmy, aby dowiedzieć się więcej o rozwiązywaniu 500 wewnętrznych błędów serwera.

Wideo Opis
Wprowadzenie Zawiera wprowadzenie do artykułu 500 wewnętrznych błędów serwera i możliwych przyczyn. Dodatkowo pokazuje błąd 500 wewnętrznego serwera w czasie rzeczywistym oraz instrukcje rozwiązywania problemów.
Obsługa błędów dotyczących wywołań usługi i wyodrębniania zmiennych Demonstracja dwóch 500 wewnętrznych błędów serwera spowodowanych przez zasady dotyczące wywołań usługi i wyodrębniania zmiennej oraz sposobów rozwiązywania tych problemów i rozwiązywania problemów.
Obsługa błędów zasad JavaScript Wyświetla wewnętrzny błąd serwera 500 spowodowany przez zasadę JavaScript oraz instrukcje rozwiązywania tego problemu.
Obsługa awarii serwerów backendu Pokazuje przykładowe 500 wewnętrznych błędów serwera spowodowanych przez awarię serwera backendu i pokazuje, jak naprawić błędy.

Krótki opis problemu

W odpowiedzi na wywołania interfejsu API aplikacja kliencka otrzymuje kod stanu HTTP 500 z komunikatem „Wewnętrzny błąd serwera”. Przyczyną wewnętrznego błędu serwera 500 może być błąd podczas wykonywania dowolnej zasady w Edge lub błąd na serwerze docelowym lub backendu.

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

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

HTTP/1.1 500 Internal Server Error

W niektórych przypadkach może pojawić się 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

Ten błąd może wystąpić z wielu różnych przyczyn. W Edge przyczyny błędu można podzielić na 2 główne kategorie w zależności od miejsca wystąpienia błędu:

Przyczyna Szczegóły Przedstawiliśmy szczegółowe instrukcje rozwiązywania problemów
Błąd wykonywania w zasadzie brzegowej Z jakiegoś powodu działanie zasady na serwerze proxy interfejsu API może nie działać. Użytkownicy chmury prywatnej i publicznej Cloud
Błąd na serwerze backendu Z jakiegoś powodu serwer backendu może nie działać. Użytkownicy chmury prywatnej i publicznej Cloud

Błąd wykonywania w zasadzie brzegowej

Z jakiegoś powodu działanie zasady na serwerze proxy interfejsu API może nie działać. W tej sekcji opisujemy, jak rozwiązać problem, jeśli podczas wykonywania zasady wystąpi wewnętrzny błąd serwera 500.

Diagnostyka

Etapy diagnostyczne dla użytkowników chmury prywatnej i publicznej

Jeśli masz sesję interfejsu śledzenia związaną z błędem, to:

  1. Sprawdź, czy błąd był spowodowany uruchomieniem zasady. Więcej informacji znajdziesz w artykule Określanie źródła problemu.
  2. Jeśli błąd wystąpił podczas wykonywania zasady, przejdź dalej. Jeśli błąd został spowodowany przez serwer backendu, przejdź do sekcji Błąd na serwerze backendu.
  3. Wybierz żądanie do interfejsu API, w przypadku którego występuje błąd 500 „Wewnętrzny błąd serwera”.
  4. Sprawdź żądanie i wybierz konkretną zasadę, której nie udało się zweryfikować, lub proces o nazwie „Błąd”, który bezpośrednio następuje po nieudanej zasadzie w logu czasu.
  5. Aby uzyskać więcej informacji o błędzie, sprawdź pole „błąd” w sekcji Właściwości lub treść błędu.
  6. Na podstawie zebranych informacji o błędzie spróbuj ustalić jego przyczynę.

Kroki diagnostyczne tylko dla użytkowników Private Cloud

Jeśli nie masz sesji interfejsu śledzenia, wtedy:

  1. Sprawdź, czy błąd wystąpił podczas wykonywania zasady. Więcej informacji znajdziesz w artykule Określanie źródła problemu.
  2. Jeśli błąd był spowodowany wykonaniem zasady, przejdź dalej. Jeśli błąd wystąpił podczas wykonywania zasady, przejdź dalej. Jeśli błąd został spowodowany przez serwer backendu, przejdź do artykułu Błąd na serwerze backendu.
  3. Użyj logów dostępu NGINX zgodnie z instrukcjami w sekcji Określanie źródła problemu, aby określić zasady, które nie działają na serwerze proxy interfejsu API, oraz unikalny identyfikator wiadomości żądania.
  4. Sprawdź logi procesora wiadomości (/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 na temat przyczyny niepowodzenia.

Rozdzielczość

Po znalezieniu przyczyny problemu z zasadą spróbuj rozwiązać problem, naprawiając zasadę i ponownie wdrażając serwer proxy.

Poniższe przykłady pokazują, jak ustalić przyczynę i rozwiązać problemy różnych typów.

Jeśli potrzebujesz dalszej pomocy w rozwiązywaniu problemów z wewnętrznym błędem serwera 500 lub podejrzewasz, że jest to problem w Edge, skontaktuj się z zespołem pomocy Apigee.

Przykład 1. Niepowodzenie w zasadach dotyczących objaśnień usługi z powodu błędu na serwerze backendu

Jeśli wywołanie serwera backendu nie powiedzie się z powodu wystąpienia błędu 4XX lub 5XX w ramach zasady objaśnienia usługi, zostanie potraktowane jako błąd 500 „Wewnętrzny błąd serwera”.

  1. Oto przykład, w którym usługa backendu ulega awarii i wyświetla błąd 404 w zasadzie objaśnienia usługi. Do użytkownika 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 objaśnień usługi:

  3. W tym przykładzie właściwość „error” podaje przyczynę błędu zasady dotyczącego objaśnienia usługi jako „ResponseCode 404 is traktowany jako błąd”. Ten błąd może wystąpić, jeśli zasób, do którego uzyskuje się dostęp przez adres URL serwera backendu w zasadzie objaśnienia usługi, jest niedostępny.
  4. Sprawdź dostępność zasobu na serwerze backendu. Może nie być dostępna tymczasowo lub na stałe albo została przeniesiona do innej lokalizacji.

Przykład 1 Rozwiązanie

  1. Sprawdź dostępność zasobu na serwerze backendu. Może nie być dostępna tymczasowo lub na stałe albo została przeniesiona do innej lokalizacji.
  2. Napraw adres URL serwera backendu w zasadzie objaśnienia 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. Błąd w zasadach wyodrębniania zmiennych

Spójrzmy teraz na inny przykład, w którym przyczyną jest błąd 500 spowodowany błędem w zasadzie Wyodrębnianie zmiennych. Zobaczmy, jak rozwiązać ten problem.

  1. Ten log czasu w sesji interfejsu pokazuje kod stanu 500 z powodu błędu w zasadzie wyodrębniania zmiennych:

  2. Wybierz nieudaną zasadę Wyodrębnianie zmiennych, przewiń w dół i sprawdź sekcję „Treść błędu”, aby uzyskać więcej informacji:

  3. Treść błędu wskazuje, że zmienna "serviceCallout.oamCookieValidationResponse" jest niedostępna w zasadzie Wyodrębnianie zmiennych. Jak wskazuje nazwa zmiennej, powinna ona przechowywać odpowiedź z poprzedniej zasady dotyczącej objaśnień usługi.
  4. Wybierz w logu czasu zasadę objaśnienia usługi. Może się okazać, że zmienna „serviceCallout.oamCookieValidationResponse” nie została ustawiona. Wskazuje on, że nie udało się wywołać usługi backendu, co spowodowało, że zmienna odpowiedzi była pusta.
  5. Chociaż nie udało się zrealizować zasady dotyczącej objaśnienia usługi, to po jej wprowadzeniu nadal są wykonywane, ponieważ flaga „continueOnError” w zasadach dotyczących objaśnienia usługi ma wartość Prawda, 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. Zwróć uwagę na unikalny identyfikator komunikatu "X-Apigee.Message-ID" dla tego konkretnego żądania interfejsu API ze logu czasu:
    1. Wybierz w żądaniu etap „Rejestrowane dane Analytics”.
    2. Przewiń w dół i zanotuj wartość X-Apigee.Message-ID.

  7. Wyświetl dziennik procesora wiadomości (/opt/apigee/var/log/edge-message-processor/system.log) i wyszukaj unikalny identyfikator wiadomości wymieniony w kroku nr 6. W przypadku konkretnego żądania do 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 oznacza, że nie udało się zastosować zasady objaśnienia usługi z powodu błędu przekroczenia limitu czasu połączenia podczas nawiązywania połączenia z serwerem backendu.

  8. Aby określić przyczynę błędu przekroczenia limitu czasu połączenia, wykonaj na serwerze backendu polecenie telnet z procesora wiadomości. Polecenie telnet zwróciło błąd „Osiągnięto limit czasu połączenia”, jak na tym przykładzie: 
    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 następujących sytuacjach:

    • Gdy serwer backendu nie jest skonfigurowany do zezwalania na ruch z procesorów wiadomości brzegowych.
    • Jeśli serwer backendu nie nasłuchuje na tym porcie.

    W powyższym przykładzie, chociaż zasada Wyodrębnianie zmiennych nie powiodła się, faktyczną przyczyną było to, że program Edge nie mógł połączyć się z serwerem backendu w ramach zasady objaśnienia usługi. Przyczyną tego błędu było to, że serwer końcowy backendu nie został skonfigurowany pod kątem zezwalania na ruch z serwerów brzegowych obsługujących wiadomości.

    Twoja zasada Wyodrębnianie zmiennych będzie działać inaczej i może zakończyć się niepowodzeniem z innego powodu. Możesz rozwiązać ten problem w zależności od przyczyny niepowodzenia zasady Wyodrębnianie zmiennych, sprawdzając komunikat we właściwości error.

Przykład 2 – Rozdzielczość

  1. Napraw przyczynę błędu lub błędu w zasadzie Wyodrębnianie zmiennych.
  2. W podanym powyżej przykładzie rozwiązaniem było skorygowanie konfiguracji sieci, aby umożliwić ruch z brzegowych systemów przetwarzania wiadomości do serwera backendu. W tym celu dodano adresy IP procesorów wiadomości do listy dozwolonych na określonym serwerze backendu. Na przykład w systemie Linux możesz użyć polecenia iptables, aby zezwolić na ruch z adresów IP procesora wiadomości na serwerze backendu.

Przykład 3. Błąd w zasadach JavaCallout

Spójrzmy teraz na jeszcze jeden przykład, w którym błąd 500 w zasadzie objaśnień w języku Java powoduje błąd wewnętrzny serwera 500. Zobaczmy też, jak rozwiązać ten problem.

  1. Ten ślad interfejsu pokazuje kod stanu 500 z powodu błędu w zasadach objaśnień w języku Java:

  2. Wybierz proces o nazwie „Error” i niewłaściwą zasadzie objaśnień w Javie, aby uzyskać szczegółowe informacje o błędzie, tak jak na ilustracji poniżej:

  3. W tym przykładzie właściwość "error" w sekcji Właściwości wskazuje, że błąd wynika z użycia wygasłego hasła podczas nawiązywania połączenia z bazą danych Oracle z poziomu zasady JavaCallout. Twoje objaśnienie w Javie będzie działać inaczej i pojawi się inny komunikat we właściwości error.
  4. Sprawdź kod zasady JavaCallout i potwierdź, że ma być używana prawidłowa konfiguracja.

Przykład 3 – Rozdzielczość

Popraw kod lub konfigurację objaśnienia Java, aby uniknąć wyjątku w czasie działania. W przedstawionym powyżej przykładzie błędu wywołania Javy w celu rozwiązania problemu trzeba użyć poprawnego hasła do połączenia z bazą danych Oracle.

Błąd na serwerze backendu

Błąd 500 – wewnętrzny błąd serwera może również pochodzić z serwera backendu. W tej sekcji dowiesz się, jak rozwiązać problem, jeśli błąd pochodzi z serwera backendu.

Diagnostyka

Kroki diagnostyczne dla wszystkich użytkowników

Przyczyny innych błędów backendu mogą być bardzo różne. Musisz zdiagnozować każdą sytuację oddzielnie.

  1. Sprawdź, czy błąd został spowodowany przez serwer backendu. Więcej informacji znajdziesz w artykule Określanie źródła problemu.
  2. Jeśli błąd był spowodowany przez serwer backendu, przejdź dalej. Jeśli błąd wystąpił podczas wykonywania zasady, przejdź do sekcji Błąd wykonywania w zasadzie brzegowej.
  3. Wykonaj poniższe czynności w zależności od tego, czy masz dostęp do sesji śledzenia dla nieudanego interfejsu API lub czy backendem jest serwer Node.js:

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

  1. Jeśli w przypadku nieudanego żądania śledzenie UI jest niedostępne, sprawdź logi 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, poniższe czynności pomogą Ci zdiagnozować problem.

  1. W narzędziu do śledzenia wybierz żądanie do interfejsu API, które zakończyło się niepowodzeniem (wewnętrzny błąd serwera 500).
  2. Wybierz etap „Odpowiedź otrzymana z serwera docelowego” w nieudanym żądaniu do interfejsu API, jak pokazano na ilustracji poniżej:

  3. Sprawdź sekcję „Treść odpowiedzi”, aby uzyskać szczegółowe informacje o błędzie.

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

Jeśli backendem jest serwer Node.js:

  1. Jeśli backendem jest serwer backendu Node.js, sprawdź logi Node.js dla konkretnego serwera proxy interfejsu API w interfejsie użytkownika Edge (użytkownicy chmury publicznej i prywatnej mogą sprawdzić logi Node.js). Jeśli jesteś użytkownikiem chmury prywatnej Edge, możesz też sprawdzić logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby dowiedzieć się więcej o błędzie.

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

Rozwiązanie

  1. Po znalezieniu przyczyny błędu napraw go na serwerze backendu.
  2. Jeśli jest to serwer backendu Node.js:
    1. Sprawdź, czy błąd jest wywoływany przez kod niestandardowy, i w miarę możliwości rozwiąż problem.
    2. Jeśli błąd nie jest wywoływany z Twojego kodu niestandardowego lub jeśli potrzebujesz pomocy, skontaktuj się z zespołem pomocy Apigee.

Jeśli potrzebujesz dalszej pomocy w rozwiązywaniu problemów z wewnętrznym błędem serwera 500 lub podejrzewasz, że jest to problem w Edge, skontaktuj się z zespołem pomocy Apigee.

Określenie źródła problemu

Użyj jednej z poniższych procedur, aby określić, czy podczas wykonywania zasady na serwerze proxy interfejsu API czy przez serwer backendu został zgłoszony wewnętrzny błąd serwera 500.

Używanie logu czasu w interfejsie użytkownika

Uwaga: czynności z 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 API, którego dotyczy problem.
  2. Po przechwyceniu logu czasu wybierz żądanie do interfejsu API wyświetlające kod odpowiedzi 500.
  3. Przejdź przez wszystkie etapy nieudanego żądania do interfejsu API i sprawdź, który z nich zwraca wewnętrzny błąd serwera 500:
    1. Jeśli błąd jest zgłaszany podczas wykonywania zasady, przejdź do artykułu Błąd wykonywania w zasadzie brzegowej.
    2. Jeśli serwer backendu zgłosił odpowiedź 500 – wewnętrzny serwer, przejdź do sekcji Błąd na serwerze backendu.

Korzystanie z monitorowania interfejsów API

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

Monitorowanie interfejsów API umożliwia szybkie wyizolowanie problematycznych obszarów w celu diagnozowania problemów dotyczących błędów, wydajności i opóźnień oraz ich źródeł, takich jak aplikacje dla programistów, serwery proxy interfejsów API, cele backendu czy platforma API.

Przejrzyj przykładowy scenariusz pokazujący, jak rozwiązać problemy 5xx z interfejsami API przy użyciu API Monitoring. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba 500 kodów stanu lub błędów steps.servicecallout.ExecutionFailed przekroczy określony próg.

Korzystanie z logów dostępu NGINX

Uwaga: czynności w tej sekcji dotyczą tylko użytkowników chmury Edge Private Cloud.

Możesz też sprawdzić w logach dostępu NGINX, czy podczas wykonywania zasady został zgłoszony kod stanu 500 podczas wykonywania zasady na serwerze proxy interfejsu API czy przez serwer backendu. Jest to szczególnie przydatne, jeśli problem występował w przeszłości lub występuje sporadycznie i nie możesz przechwycić logu czasu w interfejsie użytkownika. Aby określić te informacje w logach dostępu NGINX, wykonaj te czynności:

  1. Sprawdź logi dostępu do NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. Wyszukaj, czy w danym okresie wystąpiło jakieś 500 błędów dla określonego serwera proxy interfejsu API.
  3. Jeśli wystąpiło jakiekolwiek błędy 500, sprawdź, czy jest to błąd zasady czy serwera docelowego, jak pokazano poniżej:

    Przykładowy wpis z błędem dotyczącym zasad

    Przykładowy wpis z błędem 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 wykonywania w zasadzie brzegowej.
    2. Jeśli jest to błąd serwera docelowego, przejdź do sekcji Błąd na serwerze backendu.