500 Wewnętrzny błąd serwera

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

Filmy

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

Wideo Opis
Wprowadzenie Wprowadzenie do 500 wewnętrznych błędów serwera i możliwych przyczyn. Oprócz tego demonstruje błąd 500 wewnętrznego serwera w czasie rzeczywistym wraz z instrukcjami rozwiązywania problemów.
Obsługa błędów zmiennych wywołań usługi i wyodrębniania zmiennych Demonstracja 2 500 wewnętrznych błędów serwera spowodowanych przez zasady dotyczące wywołań usługi i wyodrębniania zmiennych oraz pokazuje, jak je naprawić.
Obsługa błędów związanych z zasadami JavaScript Pokazuje wewnętrzny błąd serwera 500 spowodowany przez zasadę JavaScriptu i opis kroków w celu naprawienia tego błędu.
Obsługa awarii serwerów backendu Przedstawia przykładowe wewnętrzne błędy serwera (500) spowodowane awarią serwera backendu oraz kroki do wykonania. aby usunąć błędy.

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 500 z komunikatem „Wewnętrzny błąd serwera” w odpowiedzi na wywołania interfejsu API. 500 Internal Server błąd może być spowodowany błędem podczas wykonywania dowolnej zasady w Edge lub przez błąd na serwerze docelowym/backendowym.

Kod stanu HTTP 500 to ogólna odpowiedź na błąd. 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 wyświetlić 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 będzie zawierał bardziej szczegółowe informacje. Oto przykład 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

Wewnętrzny błąd serwera 500 może być zgłaszany z wielu różnych przyczyn. W Edge przyczyny błędu można podzielić na 2 główne kategorie w zależności od miejsca, w którym wystąpił błąd:

Przyczyna Szczegóły Znajdziesz tu szczegółowe instrukcje rozwiązywania problemów
Błąd wykonania w zasadzie brzegowej Zasady serwera proxy interfejsu API może z jakiegoś powodu spowodować błąd. Użytkownicy Edge Private Cloud i użytkownicy chmury publicznej
Błąd serwera backendu Z jakiegoś powodu serwer backendu może ulec awarii. Użytkownicy Edge Private Cloud i użytkownicy chmury publicznej

Błąd wykonania w zasadzie brzegowej

Zasadę w serwer proxy interfejsu API może z jakiegoś powodu nie działać. Z tej sekcji dowiesz się, jak rozwiązać problem, jeśli podczas wykonywania zasady występuje wewnętrzny błąd serwera 500.

Diagnostyka

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

Jeśli masz sesję w interfejsie śledzenia błędu, która występuje w przypadku tego błędu:

  1. Sprawdź, czy błąd został spowodowany wykonaniem zasady. Szczegółowe informacje znajdziesz w punkcie Określanie źródła problemu.
  2. Jeśli błąd wystąpił podczas wykonywania zasady, przejdź dalej. Jeśli błąd był spowodowany przez serwera 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 w śledzeniu.
  4. Sprawdź żądanie i wybierz konkretną zasadę, która została odrzucona, lub proces o nazwie „Błąd” który jest bezpośrednio po śledzeniu zasady z błędami.
  5. Dowiedz się więcej o błędzie, zaznaczając pole „Błąd” w obszarze Właściwości lub treści o błędzie.
  6. Korzystając z zebranych informacji o błędzie, spróbuj ustalić jego przyczynę.

Kroki diagnostyczne tylko dla użytkowników chmury prywatnej

Jeśli nie masz sesji interfejsu śledzenia, wykonaj te czynności:

  1. Sprawdź, czy błąd wystąpił podczas wykonywania zasady. Szczegółowe informacje znajdziesz w punkcie Określanie źródła problemu.
  2. Jeśli błąd był spowodowany wykonaniem zasady, przejdź dalej. Jeśli błąd wystąpił podczas korzystania z zasad , kontynuuj. Jeśli błąd jest spowodowany przez serwer backendu, przejdź do sekcji Błąd serwera backendu.
  3. Użyj logów dostępu NGINX zgodnie z opisem w sekcji Określanie źródła problemu w celu określenia niedziałających zasad na serwerze proxy API, a także unikalny identyfikator wiadomości żądania
  4. Sprawdzanie logów procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log) i wyszukaj niepowtarzalny identyfikator wiadomości żądania.
  5. Jeśli znajdziesz unikalny identyfikator wiadomości żądania, sprawdź, czy możesz uzyskać więcej informacji na temat przyczyna niepowodzenia.

Rozdzielczość

Jeśli udało Ci się ustalić przyczynę problemu z zasadami, spróbuj rozwiązać problem przez poprawienie zasady i ponowne wdrożenie serwera proxy.

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

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

Przykład 1. Błąd w zasadach dotyczących wywołań usługi z powodu błędu w backendzie serwer

Jeśli wywołanie serwera backendu nie powiedzie się zgodnie z zasadą objaśnienia usługi z takim błędem jak jako 4XX lub 5XX, wtedy zostanie ona potraktowana jako błąd 500 Wewnętrzny błąd serwera.

  1. Oto przykład, w przypadku którego usługa backendu uległa awarii z powodu błędu 404 w usłudze Zasady dotyczące objaśnień. Do użytkownika końcowego zostanie wysł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. Poniższa sesja UI śledzenia wyświetla kod stanu 500 z powodu błędu w usłudze Zasady dotyczące objaśnień:

  3. W tym przykładzie „error” właściwość zawiera listę powodów, dla których zostały wprowadzone zasady dotyczące wywołań usługi błąd jako „ResponseCode 404 jest traktowany jako błąd”. Ten błąd może wystąpić, jeśli: zasób, do którego dostęp jest uzyskiwany przez adres URL serwera backendu w zasadzie objaśnienia usługi nie jest i dostępności informacji.
  4. Sprawdź dostępność zasobu na serwerze backendu. Może być niedostępna tymczasowo lub na stałe lub mogły zostać przeniesione w inne miejsce.

Rozdzielczość przykładu 1

  1. Sprawdź dostępność zasobu na serwerze backendu. Może być niedostępna tymczasowo lub na stałe lub mogły zostać przeniesione w inne miejsce.
  2. Napraw adres URL serwera backendu w zasadzie objaśnień usługi, tak aby wskazywał prawidłową i istniejącą .
  3. Jeśli zasób jest tylko tymczasowo niedostępny, spróbuj wysłać żądanie do interfejsu API, gdy .

Przykład 2. Błąd w zasadach wyodrębniania zmiennych

Przyjrzyjmy się teraz innemu przykładowi, w którym błąd 500 „Wewnętrzny błąd serwera” jest spowodowany błędem. w zasadach Wyodrębnianie zmiennych oraz zobacz, jak rozwiązać ten problem.

  1. Poniższy log czasu w sesji interfejsu użytkownika pokazuje kod stanu 500 z powodu błędu w wyodrębnianiu Zasady dotyczące zmiennych:

  2. Wybierz niedziałającą zasadę wyodrębniania zmiennych, przewiń w dół i poszukaj komunikatu „Błąd” Content”, aby dowiedzieć się więcej:

  3. Treść błędu wskazuje, że Zmienna "serviceCallout.oamCookieValidationResponse" nie jest dostępna w zasady wyodrębniania zmiennych. Zgodnie z nazwą zmiennej powinna ona zawierać odpowiedź poprzedniej zasady dotyczącej wywołań usługi.
  4. Wybierz w logu zasadę dotyczącą objaśnień usługi. Być może zauważysz, że "serviceCallout.oamCookieValidationResponse" nie ustawiono zmiennej. Ten wskazuje, że wywołanie usługi backendu się nie powiodło, w wyniku czego odpowiedź jest pusta .
  5. Chociaż zasady dotyczące wywołań usługi nie zostały spełnione, wykonanie tych zasad po korzystaniu z usługi Zasada objaśnień jest kontynuowana, ponieważ parametr „continueOnError” flaga w zasadzie objaśnień usługi jest ustawiona wartość prawda, jak 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 niepowtarzalny identyfikator wiadomości &quot;X-Apigee.Message-ID&quot; dla tego konkretnego interfejsu API. żądania ze śledzenia w następujący sposób:
    1. Zaznacz pole wyboru „Analytics Data Recorded” (Rejestrowane dane Analytics). z procedury.
    2. Przewiń w dół i zanotuj wartość X-Apigee.Message-ID.

  7. Wyświetlanie dziennika procesora wiadomości (/opt/apigee/var/log/edge-message-processor/system.log) i wyszukaj unikalny zanotowany w kroku 6. Zaobserwowany ten komunikat o błędzie dotyczy konkretnego interfejsu API żądanie: 
    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ć zasad dotyczących wywołań usługi z powodu połączenia. podczas nawiązywania połączenia z serwerem backendu wystąpił błąd przekroczenia limitu czasu.

  8. Aby określić przyczynę błędu przekroczenia limitu czasu połączenia, wykonaj polecenie telnet do serwera backendu z procesorów komunikatów. Telnet z komunikatem „Connection timed out” (Osiągnięto limit czasu połączenia) jak poniżej: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    Zwykle ten błąd występuje w następujących sytuacjach:

    • Gdy serwer backendu nie jest skonfigurowany pod kątem zezwalania na ruch z wiadomości brzegowej Procesory.
    • Jeśli serwer backendu nie nasłuchuje na określonym porcie.

    W powyższym przykładzie, mimo że działanie zasady Wyodrębnij zmienne nie powiodło się, rzeczywista wartość było przyczyną, dla której Edge nie mógł połączyć się z serwerem backendu w objaśnieniu usługi . Przyczyną tego błędu było to, że serwer końcowy backendu nie został skonfigurowany tak, zezwala na ruch z procesorów wiadomości na serwerach brzegowych.

    Twoje własne zasady wyodrębniania zmiennych będą działać inaczej i w przypadku innych . Możesz rozwiązać problem odpowiednio w zależności od przyczyny awarii zasady wyodrębniania zmiennych, sprawdzając komunikat w błędzie. usłudze.

Rozdzielczość przykładu 2

  1. Napraw przyczynę błędu lub błędu w zasadzie wyodrębniania zmiennych.
  2. W przykładzie powyżej rozwiązaniem jest przeredagowanie konfiguracji sieci, zezwala na ruch z procesorów komunikatów brzegowych do serwera backendu. Autor dodanie do listy dozwolonych procesorów wiadomości Adresy IP na konkretnym serwerze backendu. Przykład: w Linuksie możesz użyć iptables, by zezwolić na ruch Adresy IP procesora wiadomości na serwerze backendu.

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

Przeanalizujmy teraz jeszcze jeden przykład, w którym powstaje z powodu błędu „Wewnętrzny błąd serwera 500”. w zasadach dotyczących wywołań Javy.

  1. Ten log czasu interfejsu pokazuje kod stanu 500 z powodu błędu w zasadach objaśnień w Javie:

  2. Wybierz przepływ o nazwie "Error", a po nim błędną zasadę objaśnień w Javie. w celu uzyskania szczegółów błędu, tak jak na ilustracji poniżej:

  3. W tym przykładzie właściwość "error" w sekcji Właściwości ujawnia że błąd wynika z użycia nieważnego hasła przy połączeniu z bazą danych Oracle z poziomu zasady JavaCallout. Twoje własne objaśnienie w Javie będzie działać inaczej i będzie wpisz inny komunikat we właściwości error.
  4. Sprawdź kod zasad JavaCallout i potwierdź prawidłową konfigurację .

Rozdzielczość przykładu 3

Popraw kod lub konfigurację objaśnienia w Javie, aby uniknąć wyjątku w środowisku wykonawczym. W przedstawionego powyżej przykładu błędu objaśnienia w Javie, trzeba podać poprawne hasło dotyczące połączenia z bazą danych Oracle w celu rozwiązania problemu.

Błąd serwera backendu

Wewnętrzny błąd serwera 500 może również być inicjowany z serwera backendu. Ta sekcja wyjaśnia, 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. Konieczne będzie diagnozowanie każdej sytuacji dzięki czemu mogą pracować niezależnie.

  1. Sprawdź, czy błąd został spowodowany przez serwer backendu. Szczegółowe informacje znajdziesz w punkcie Określanie źródła problemu.
  2. Jeśli błąd został spowodowany przez serwer backendu, przejdź dalej. Jeśli błąd wystąpił w trakcie wykonanie zasady, przejdź do sekcji Błąd wykonywania w Edge Zasady.
  3. Wykonaj poniższe czynności w zależności od tego, czy masz dostęp do sesji Trace dla w przypadku błędu API lub jeśli backend jest serwerem Node.js:

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

  1. Jeśli dla nieudanego żądania nie ma dostępu do logu czasu, sprawdź serwer 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 metodzie błędu i przyczyny.

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

Jeśli masz sesję Trace, poniższe kroki pomogą Ci zdiagnozować problem.

  1. W narzędziu Trace wybierz żądanie do interfejsu API, które zakończyło się niepowodzeniem (serwer wewnętrzny 500). Błąd.
  2. Wybierz etap „Odpowiedź otrzymana z serwera docelowego” dla etapu, w którym wystąpił błąd żądania do interfejsu API zgodnie z poniższą ilustracją:

  3. Sprawdź sekcję „Response Content” (Treść odpowiedzi), by poznać szczegółowe informacje o błędzie.

  4. W tym przykładzie zawartość odpowiedzi, która jest kopertą SOAP, wyświetla ciąg błędu jako Komunikat „Brak autoryzacji”. Najbardziej prawdopodobna przyczyna Problem polega na tym, że do usługi nie są przekazywane odpowiednie dane uwierzytelniające (nazwa użytkownika/hasło, token dostępu itp.). serwer backendu przez użytkownika. Ten problem można rozwiązać, przekazując prawidłowe dane logowania do do serwera backendu.

Jeśli backendem jest serwer Node.js:

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

    Opcja Logi NodeJS w interfejsie Edge – karta przeglądu interfejsu API Proxy

Rozwiązanie

  1. Po znalezieniu przyczyny błędu rozwiąż problem na serwerze backendu.
  2. Jeśli jest to serwer backendu Node.js:
    1. Sprawdź, czy błąd nie pochodzi z niestandardowego kodu, i jeśli to możliwe, rozwiąż problem.
    2. Jeśli błąd nie pochodzi z niestandardowego kodu lub potrzebujesz pomocy, skontaktuj się z Zespół pomocy Apigee

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

Określanie źródła problemu

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

Używanie śledzenia w interfejsie

Uwaga: czynności opisane w tej sekcji mogą być wykonywane zarówno w trybie publicznym, jak i przez użytkowników chmury prywatnej.

  1. Jeśli problem jest nadal aktywny, włącz śledzenie w UI dla interfejsu API, którego dotyczy problem.
  2. Po przechwyceniu logu czasu wybierz żądanie do interfejsu API, które wyświetla kod odpowiedzi jako 500)
  3. Przejdź przez wszystkie fazy nieudanego żądania do interfejsu API i sprawdź, która faza zwraca 500 – wewnętrzny błąd serwera:
    1. Jeśli błąd zostanie zgłoszony podczas wykonywania zasady, przejdź do sekcji Błąd wykonywania w zasadzie brzegowej.
    2. Jeśli serwer backendu wysłał odpowiedź z kodem wewnętrznym 500, 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 błędów, wydajności i opóźnień oraz ich źródła. takich jak aplikacje dla programistów, serwery proxy API, środowiska docelowe backendu czy platforma API.

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

Korzystanie z dostępu do NGINX Dzienniki

Uwaga: instrukcje w tej sekcji dotyczą użytkowników Edge Private Cloud

W logach dostępu NGINX możesz też sprawdzić, czy został zgłoszony kod stanu 500 podczas wykonywania zasady na serwerze proxy interfejsu API lub przez serwer backendu. To jest szczególnie przydatne, jeśli problem wystąpił w przeszłości lub jest przejściowy nie mogą zarejestrować logu czasu w UI. Aby określić te informacje z: Logi dostępu NGINX:

  1. Sprawdź logi dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. Wyszukaj 500 błędów dla konkretnego serwera proxy interfejsu API w konkretnym miejscu czas trwania kampanii.
  3. Jeśli pojawi się błąd 500, sprawdź, czy jest to błąd związany z zasadami, czy z serwera docelowego. jak poniżej:

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

    Przykładowy wpis z błędem serwera docelowego

  4. Gdy ustalisz, czy błąd jest związany z zasadami, czy z serwerem docelowym:
    1. Przejdź do sekcji Błąd wykonywania w zasadzie brzegowej, jeśli na którym jest błąd związany z zasadami.
    2. Przejdź do sekcji Błąd serwera backendu, jeśli jest elementem docelowym wystąpił błąd serwera.