Przeglądasz dokumentację Apigee Edge.
Przejdź do
Dokumentacja Apigee X. informacje.
Krótki opis problemu
Aplikacja kliencka otrzymuje kod stanu odpowiedzi HTTP 500 z w przypadku wywołań interfejsu API wyświetla się komunikat Wewnętrzny błąd serwera.
Komunikaty o błędach
Aplikacje klienckie mogą otrzymać odpowiedź o błędzie, jak pokazano poniżej:
HTTP/1.1 500 Internal Server Error
Może się wtedy pojawić następujący komunikat o błędzie:
{
"fault":{
"faultstring":"Expecting } at line 1"
"detail":{
"errorcode":"Internal Server Error"
}
}
}
OR
{
"fault":{
"faultstring":"Expecting ] at line 1"
"detail":{
"errorcode":"Internal Server Error"
}
}
}
Możliwe przyczyny
Wewnętrzny błąd serwera 500 może mieć wiele różnych przyczyn. Ten scenariusz skupia się na wewnętrznym błędzie serwera 500 spowodowanym uzyskaniem dostępu do żądania/odpowiedzi ładunek podczas strumieniowego przesyłania danych jest włączona.
| Przyczyna | Opis | Kto może wykonywać czynności związane z rozwiązywaniem problemów |
| Dostęp do ładunku za pomocą Odtwarzanie strumieniowe włączone | Wystąpił błąd, ponieważ dostęp do ładunku żądania/odpowiedzi jest włączony, gdy włączone jest strumieniowe przesyłanie danych. | Użytkownicy chmury prywatnej i publicznej na serwerach brzegowych |
Przyczyna: dostęp do ładunku z włączonym strumieniowaniem
Diagnostyka
Procedura nr 1. Korzystanie ze śledzenia
- Włącz śledzenie session i wykonać wywołanie interfejsu API, aby odtworzyć problem – „500 Wewnętrzny błąd serwera”.
- Wybierz jedno z nieudanych żądań i sprawdź log czasu.
- Przejdź przez różne fazy śledzenia i znajdź miejsca, w których wystąpił błąd.
- Ten błąd mógł wystąpić, gdy zasada analizuje ładunek żądania/odpowiedzi.
- Oto przykładowy zrzut ekranu z logiem JSONThreatProtection
zasada nie wystąpiła z błędem „Oczekiwana jest wartość } w wierszu 1”:
Zanotuj te informacje z danych wyjściowych logu czasu, jak pokazano powyżej zrzut ekranu:
Niezgodna zasada: JSONThreatProtection
Flow: żądanie serwera proxy
- Sprawdź definicję zasady z błędem i sprawdź ładunek, który jest analizowany.
W przykładowym scenariuszu zapoznaj się z zasadą JSONThreatProtection o nazwie JSON-Threat-Protection, w którym wystąpił błąd i sprawdź element
<Source>.<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection"> <DisplayName>JSON Threat Protection</DisplayName> <ArrayElementCount>20</ArrayElementCount> <ContainerDepth>10</ContainerDepth> <ObjectEntryCount>15</ObjectEntryCount> <ObjectEntryNameLength>50</ObjectEntryNameLength> <Source>request</Source> <StringValueLength>1000</StringValueLength> </JSONThreatProtection>
Zwróć uwagę, że element
<Source>wskazujerequest.. Oznacza to, że wystąpił błąd podczas analizowania ładunku żądania. - Ustal typ ładunku analizowanego przez sprawdzenie żądania do interfejsu API.
- Sprawdź, czy ładunek ma prawidłowy format. Ten błąd może wystąpić, gdy ładunek jest nieprawidłowy.
Jeśli ładunek jest prawidłowy, ale nadal pojawiają się błędy wymienione w Komunikaty o błędach, a potem przyczyny tych błędów. jest taki, że dostęp do ładunku jest uzyskiwany po włączeniu strumieniowego przesyłania danych.
W zależności od ładunku analizowanego przez zasadę (jak określono w kroku 6): sprawdzić zawartość ładunku w narzędziu do śledzenia w odpowiedniej fazie.
W tym przykładzie ładunek żądania jest analizowany, więc przyjrzyj się etap „Request Received from Client” (Prośba otrzymana od klienta) w śledzeniu i sprawdź Poproś o treści.
Jeśli zawartość żądania jest pusta, jak pokazano na zrzucie ekranu powyżej, mimo że z wysłanego przez Ciebie ładunku, co oznacza, że prawdopodobna przyczyna tego problemu żądania strumieniowego przesyłania danych jest włączone.
Dzieje się tak, ponieważ po włączeniu strumieniowego przesyłania danych ładunek żądania nie będzie widoczny w śledzeniu.
Podobnie, jeśli w momencie wystąpienia błędu ładunek odpowiedzi jest analizowany, sprawdź treść odpowiedzi na etapie „Odpowiedź otrzymana z serwera docelowego”.
Następnie sprawdź definicje serwera proxy i docelowego punktu końcowego w zależności od tego, gdzie występuje błąd jest używana w procesie API Proxy. Sprawdź, czy strumieniowe przesyłanie danych jest włączone.
W przykładowym scenariuszu w przepływie żądań serwera proxy została zastosowana zasada z błędem. (jak określono w kroku 5 powyżej); sprawdź punkt końcowy serwera proxy:
<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/v1/weather</BasePath> <VirtualHost>secure</VirtualHost> <Properties> <Property name="response.streaming.enabled">true</Property> <Property name="request.streaming.enabled">true</Property> </Properties> </HTTPProxyConnection> </ProxyEndpoint>Jak widać w przykładzie powyżej, strumieniowanie żądań zostało włączone zgodnie z tabelą właściwość
"request.streaming.enabled"ma wartość true (prawda).Dlatego przyczyną błędu jest użycie zasady JSONThreatProtection na serwerze proxy interfejsu API który uzyskuje dostęp do ładunku żądania, gdy włączona jest transmisja strumieniowa. Powoduje to błędy, ponieważ aktywuje buforowanie na serwerze proxy API i eliminuje cel korzystania ze strumieniowania w Apigee Edge.
Ten błąd może być niewidoczny w przypadku mniejszych ładunków, ale gdy używasz większych ładunków, nie mogą zobaczyć tych błędów.
- Aby upewnić się, że błąd 500 jest spowodowany zasadą, sprawdź wartość
"X-Apigee-fault-source" w „AX”
(zarejestrowane dane Analytics) faza śledzenia, wykonując te czynności:
- Kliknij fazę "AX" (Dane Analytics zarejestrowane)
jak na zrzucie ekranu poniżej:
- Przewiń w dół szczegóły etapu do sekcji „Error Headers” (Nagłówki błędów). i
określ wartości „X-Apigee-fault-code”,
"X-Apigee-fault-source" i „X-Apigee-fault-policy” jak poniżej:
- Jeśli wartość parametru "X-Apigee-fault-source" to "policy" zgodnie z informacjami na powyższej ilustracji, oznacza to, że błąd jest spowodowany dostępem zasad do ładunek podczas strumieniowego przesyłania danych.
- Kliknij fazę "AX" (Dane Analytics zarejestrowane)
jak na zrzucie ekranu poniżej:
Zawartość ładunku żądania i nagłówka Content-Type możesz sprawdzić w tym artykule:
żądania do interfejsu API. W poniższym przykładowym poleceniu curl użyto ładunku JSON.
curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \ -X POST -d @request-payload.json
Możesz również sprawdzić zasadę, która powoduje błąd, i określić typ ładunku przeanalizowano. W przykładzie powyżej nie działa zasada JSON-Threat-Protection. Oznacza to, że ładunek musi być w formacie JSON.
Rozdzielczość
Dostęp do ładunku z włączonym strumieniowaniem jest antywzorcem, jak wyjaśniliśmy w artykule Antipattern: dostęp do ładunku żądania/odpowiedzi, gdy włączona jest transmisja strumieniowa.
- Jeśli chcesz przetworzyć ładunek, musisz wyłączyć strumieniowe przesyłanie danych na serwerze proxy/docelowym
Punkt końcowy, usuwając właściwości,
"request.streaming.enabled" and "response.streaming.enabled"jak pokazano w przykładzie ProxyEndpoint poniżej:<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/v1/weather</BasePath> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection> </ProxyEndpoint>LUB
- Jeśli chcesz używać strumieniowania na potrzeby serwerów proxy interfejsu API, nie używaj żadnych zasad w pliku Serwer proxy interfejsu API mający dostęp do ładunku żądania/odpowiedzi.
Uwaga:
- W tym scenariuszu do przetworzenia ładunku żądania z użyciem zasady JSONThreatProtection użyto zasady JSONThreatProtection w tym przykładzie. Doprowadziło to do wystąpienia wewnętrznego błędu serwera 500 z różnymi błędami.
- Błędy te można również zobaczyć w zasadach, takich jak JSONToXML i XMLToJSON, które przetwarzają ładunków żądań lub odpowiedzi, gdy strumieniowe przesyłanie danych jest włączone.
- Zdecydowanie odradzamy stosowanie takich zasad na serwerach proxy, które wymagają dostępu do ładunków podczas przesyłania strumieniowego.
- Jest to antywzorcem, jak opisano w Antipattern: dostęp do ładunku żądania/odpowiedzi, gdy włączona jest transmisja strumieniowa.
Diagnozowanie problemów przy użyciu monitorowania interfejsów API
Jeśli jesteś użytkownikiem chmury prywatnej, pomiń tę procedurę.
Monitorowanie interfejsów API umożliwia szybkie wyizolowanie problematycznych obszarów w celu diagnozowania problemów z błędami, wydajnością i opóźnieniami oraz ich źródła, takich jak aplikacje dla programistów, serwery proxy API, cele 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 błędów przekroczy określony próg.
Jeśli chcesz otrzymywać powiadomienia o zgłoszeniu odpowiedzi o błędzie 500 z zasady, skonfiguruj alert dla kodu stanu 500 z ustawieniem źródło błędów jako Proxy.
Musi zbierać informacje diagnostyczne
Jeśli po wykonaniu powyższych czynności problem nie ustąpi, zbierz poniższe informacje diagnostyczne. Skontaktuj się z nimi i udostępnij je zespołowi pomocy Apigee.
Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:
- Nazwa organizacji
- Nazwa środowiska
- Nazwa serwera proxy interfejsu API
- Wykonaj polecenie curl wraz z ładunkiem żądania (jeśli dotyczy), aby odtworzyć błąd 500
- Plik śledzenia zawierający żądania z wewnętrznym błędem serwera 500
- Jeśli błędy 500 nie występują obecnie, podaj przedział czasu z informacjami o strefie czasowej, w której 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, w przypadku których występują błędy 500
- Pakiet serwerów proxy API
- Ładunek użyty w żądaniu (jeśli istnieje)
- Plik śledzenia zawierający żądania z wewnętrznym błędem serwera 500
- Logi dostępu NGINX (
/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log) - Logi 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.