Ta strona została przetłumaczona przez Cloud Translation API.

500 Wewnętrzny błąd serwera – strumieniowe przesyłanie danych włączone

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

Krótki opis problemu

Aplikacja kliencka odbiera kod stanu odpowiedzi HTTP 500 z komunikatem Wewnętrzny błąd serwera w przypadku wywołań interfejsu API.

Komunikaty o błędach

Aplikacje klienckie mogą otrzymać odpowiedź o błędzie, jak w tym przykładzie:

HTTP/1.1 500 Internal Server Error

Po tym czasie może pojawić się komunikat o błędzie podobny do tego:

{
   "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

Błąd 500 – wewnętrzny błąd serwera może mieć wiele różnych przyczyn. Ten scenariusz dotyczy wewnętrznego błędu serwera 500 spowodowanego dostępem do ładunku żądania/odpowiedzi przy włączeniu strumieniowania.

Przyczyna	Opis	Kto może rozwiązywać problemy
Dostęp do ładunku przy włączonym strumieniowaniu	Wystąpił błąd, ponieważ dostęp do ładunku żądania/odpowiedzi jest uzyskiwany po włączeniu strumieniowania.	Użytkownicy chmury prywatnej i publicznej Cloud

Przyczyna: dostęp do ładunku przy włączonym strumieniowaniu

Diagnostyka

Procedura nr 1. Korzystanie z logu czasu

Włącz sesję śledzenia i wykonaj wywołanie interfejsu API, aby odtworzyć problem – 500 wewnętrzny błąd serwera.
Wybierz 1 z nieudanych żądań i sprawdź log czasu.
Przejdź przez różne fazy śledzenia i znajdź miejsce błędu.
Ten błąd mógł wystąpić, gdy zasada analizuje ładunek żądania/odpowiedzi.
Oto przykładowy zrzut ekranu z zrzutem ekranu, który pokazuje, jak JSONThreatProtection JSONThreatProtection nie realizuje błędów i pojawia się błąd JSONThreatProtection :

Zanotuj następujące informacje w wynikach śledzenia, tak jak na powyższym zrzucie ekranu:

Zasada z błędami: JSONThreatProtection

Przepływ: żądanie serwera proxy

Sprawdź definicję zasady z błędami i sprawdź ładunek, który jest analizowany.

W przykładowym scenariuszu sprawdź zasadę JSONThreatProtection o nazwie JSON-Threat-Protection, w przypadku której 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> wskazuje na element request.Oznacza to, że podczas analizowania ładunku żądania wystąpił błąd.

Określ typ analizowanego ładunku, sprawdzając żądanie do interfejsu API.

Możesz sprawdzić zawartość ładunku żądania i nagłówek Content-Type w żądaniu do interfejsu API. W poniższym przykładowym poleceniu curl używany jest ładunek JSON.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

Możesz też sprawdzić zasadę, w której występują błędy, i określić typ analizowanego ładunku. W przykładowym scenariuszu powyżej występuje błąd zasady ochrony przed zagrożeniami JSON. Oznacza to, że ładunek musi być w formacie JSON.

Sprawdź, czy ładunek ma prawidłowy format. Ten błąd może się pojawić, jeśli ładunek jest nieprawidłowy.

Uwaga: jeśli ładunek jest duży, do sprawdzenia formatu ładunku możesz użyć dowolnego narzędzia do formatowania online.
Jeśli ładunek jest prawidłowy, ale nadal pojawiają się błędy wymienione w sekcji Komunikaty o błędach, przyczyną tych błędów jest uzyskiwanie dostępu do ładunku przy włączonym strumieniowaniu.

W zależności od ładunku, który jest analizowany przez zasadę (jak określono w kroku 6), sprawdź zawartość ładunku w narzędziu do śledzenia na odpowiedniej fazie.

W przykładowym scenariuszu ładunek żądania jest analizowany, więc sprawdź w logu czasu etap „Żądanie odebrane od klienta” i sprawdź żądanie treści.

Jeśli żądanie treści okaże się puste, jak widać na zrzucie ekranu powyżej, mimo że został wysłany prawidłowy ładunek, oznacza to, że prawdopodobną przyczyną tego problemu jest włączenie strumieniowego przesyłania żądania.

Dzieje się tak, ponieważ przy włączonym strumieniowaniu ładunek żądania nie pojawi się w logu czasu.

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 miejsca, w którym w procesie przesyłania serwera proxy interfejsu API jest używana nieprawidłowa zasada. Sprawdź, czy strumieniowe przesyłanie danych zostało włączone.

W przykładowym scenariuszu zasada błędu serwera proxy została wykonana w trakcie procesu żądania serwera proxy (jak określono w kroku 5 powyżej). Dlatego 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, co wskazuje właściwość "request.streaming.enabled" z wartością „true”.

Dlatego przyczyną błędu jest użycie zasady JSONThreatProtection w serwerze proxy interfejsu API, która uzyskuje dostęp do ładunku żądania przy włączonym strumieniowaniu. Uniemożliwia to korzystanie z przesyłania strumieniowego w Apigee Edge, ponieważ aktywuje buforowanie w serwerze proxy interfejsu API.

Ten błąd może nie być widoczny w przypadku mniejszych ładunków, ale gdy używasz większych ładunków, możesz zobaczyć te błędy.
Możesz sprawdzić, czy błąd 500 jest spowodowany przez zasadę, sprawdzając wartość "X-Apigee-fault-source" na etapie "X-Apigee-fault-source". Wykonaj te czynności:
1. Kliknij fazę „AX” (rejestrowanie danych Analytics), jak pokazano na zrzucie ekranu poniżej:
2. Przewiń w dół do sekcji Nagłówki błędów i określ wartości pól X-Apigee-fault-code, X-Apigee-fault-source i X-Apigee-fault-policy, jak pokazano poniżej:
3. Jeśli wartość "X-Apigee-fault-source" to "policy", jak widać na ilustracji powyżej, oznacza to, że błąd jest spowodowany używaniem zasady uzyskującej dostęp do ładunku przy włączonym strumieniowaniu.

Rozdzielczość

Uzyskiwanie dostępu do ładunku z włączonym strumieniowaniem stanowi antywzorzec opisany w artykule Antipattern: uzyskiwanie dostępu do ładunku żądania/odpowiedzi przy włączonym strumieniowaniu.

Jeśli chcesz przetworzyć ładunek, wyłącz strumieniowanie w punkcie końcowym serwera proxy/docelowego. Aby to zrobić, usuń właściwości "request.streaming.enabled" and "response.streaming.enabled"jak w przykładowym punkcie ProxyEndpoint poniżej:
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
LUB
Jeśli chcesz korzystać ze strumieniowania na potrzeby serwerów proxy interfejsu API, nie stosuj na serwerze proxy interfejsu API żadnych zasad, które uzyskują dostęp do ładunku żądań/odpowiedzi.

Uwaga:

W tym scenariuszu do przetwarzania ładunku żądania z włączonym strumieniowaniem została włączona zasada JSONThreatProtection. Prowadziło to do wystąpienia błędu 500 (wewnętrzny błąd serwera) z różnymi błędami.
Błędy te mogą być też widoczne w zasadach takich jak JSONToXML i XMLToJSON, które przetwarzają ładunki żądań lub odpowiedzi przy włączonym strumieniowaniu.
Zdecydowanie odradzamy używanie takich zasad w serwerach proxy, które wymagają dostępu do ładunków przy włączonym strumieniowaniu.
Jest to antywzorzec, zgodnie z opisem w sekcji Antipattern: uzyskiwanie dostępu do ładunku żądania/odpowiedzi przy włączonym streamingu.

Diagnozowanie problemów za pomocą monitorowania interfejsów API

Jeśli jesteś użytkownikiem Private Cloud, pomiń tę procedurę.

Monitorowanie interfejsów API umożliwia szybkie wyizolowanie problematycznych obszarów w celu diagnozowania problemów dotyczących błędów, wydajności i czasu oczekiwania oraz ich źródeł, takich jak aplikacje dla programistów, serwery proxy interfejsu 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 błędów przekroczy określony próg.

Jeśli chcesz otrzymywać powiadomienia, gdy zasada wyświetli odpowiedź o błędzie 500, musisz skonfigurować alert dla kodu stanu 500, podając jako źródło błędu ustawienie Serwer proxy.

Musi gromadzić informacje diagnostyczne

Jeśli problem nie ustąpi mimo wykonania powyższych instrukcji, zbierz poniższe informacje diagnostyczne. Skontaktuj się z zespołem pomocy Apigee i udostępnij je.

Jeśli jesteś użytkownikiem chmury publicznej, podaj te informacje:

Nazwa organizacji
Nazwa środowiska
Nazwa serwera proxy interfejsu API
Dokończ polecenie curl wraz z ładunkiem żądania (jeśli dotyczy), aby odtworzyć błąd 500
Plik śledzenia zawierający żądania z błędem 500 „Wewnętrzny błąd serwera”
Jeśli błędy 500 nie występują obecnie, podaj informacje o strefie czasowej dla okresu, w którym w przeszłości wystąpiły błędy 500.

Jeśli jesteś użytkownikiem Private Cloud, podaj te informacje:

Zaobserwowany pełny komunikat o błędzie dotyczący nieudanych żądań
Organizacja, nazwa środowiska i nazwa serwera proxy interfejsu API, w przypadku których występują błędy 500
Pakiet proxy API
Ładunek użyty w żądaniu (jeśli występuje)
Plik śledzenia zawierający żądania z błędem 500 „Wewnętrzny błąd serwera”
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)
Okres z informacjami o strefie czasowej, w których wystąpiły błędy 500.