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

504 Przekroczenie limitu czasu bramy

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

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 504 z komunikatem Gateway Timeout jako odpowiedź na wywołania interfejsu API.

Błąd kodu stanu HTTP – 504 Gateway Timeout wskazuje, że klient nie otrzymała na czas odpowiedzi z bramy brzegowej lub serwera backendu podczas wykonywania interfejs API

Komunikaty o błędach

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 504 Gateway Timeout

W niektórych przypadkach może też pojawić się ten komunikat o błędzie:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

Co powoduje przekroczenie czasu oczekiwania bramy?

Typowa ścieżka dla żądania do interfejsu API przesyłanego przez platformę Edge to Klient -> Frezarka -> Procesor wiadomości -> Serwer backendu, jak pokazano na ilustracji poniżej:

Aplikacja kliencka, routery i procesory wiadomości na platformie Edge są skonfigurowane przy użyciu odpowiednie wartości limitu czasu. Platforma Edge oczekuje, że odpowiedź zostanie wysłana w określonym czasie czasu dla każdego żądania API na podstawie wartości limitu czasu. Jeśli nie otrzymasz odpowiedzi w ciągu w podanym okresie, zwracana jest wartość 504 Gateway Timeout Error.

W tej tabeli znajdziesz więcej informacji o tym, kiedy w Edge mogą wystąpić przekroczenia limitu czasu:

Wystąpienie przekroczenia limitu czasu	Szczegóły
Przekroczono limit czasu w procesorze wiadomości	Serwer backendu nie odpowiada procesorowi komunikatów w określonym czasie oczekiwania w procesorze wiadomości. Przekroczenie limitu czasu procesora wiadomości i wysłanie przez router stanu odpowiedzi `504 Gateway Timeout`.
Upłynął limit czasu routera	Procesor komunikatów nie odpowiada routerowi w wyznaczonym czasie oczekiwania w routerze. Router przekracza limit czasu i wysyła do aplikacji klienckiej stan odpowiedzi jako `504 Gateway Timeout`.
Przekroczono limit czasu dla aplikacji klienckiej	Router nie odpowiada aplikacji klienckiej w określonym czasie oczekiwania na routerze. Aplikacja kliencka przekracza limit czasu i kończy dla użytkownika stan odpowiedzi jako `504 Gateway Timeout`.

Możliwe przyczyny

W Edge typowe przyczyny błędu 504 Gateway Timeout:

Przyczyna	Szczegóły	Kroki podane dla
Powolny serwer backendu	Serwer backendu, który przetwarza żądanie do interfejsu API, działa zbyt wolno ze względu na duże obciążenie lub niskiej wydajności.	Użytkownicy chmury publicznej i prywatnej
Powolne przetwarzanie żądań do interfejsu API przez Edge	Edge długo przetwarza żądanie do interfejsu API z powodu dużego obciążenia lub słabej jakości skuteczność reklam.

Wolne serwer backendu

Jeśli serwer backendu jest bardzo powolny lub przetwarza żądanie do interfejsu API za długo, wystąpi 504 Gateway Timeout błąd. Jak wyjaśniliśmy w sekcji powyżej, limit czasu może mogą wystąpić w jednym z tych scenariuszy:

Upłynął limit czasu przetwarzania wiadomości, zanim serwer backendu odpowie.
Upłynął limit czasu routera, zanim odpowie procesor wiadomości/serwer backendu.
Upłynął limit czasu aplikacji klienckiej, zanim odpowie router, procesor wiadomości lub serwer backendu.

W sekcjach poniżej opisano, jak zdiagnozować i rozwiązać problem w przypadku każdego z tych w różnych sytuacjach.

Scenariusz 1 Przekroczenie limitu czasu oczekiwania procesora wiadomości przed odpowiedzią serwera backendu

Diagnostyka

Aby sprawdzić, czy wystąpił błąd 504 Gateway Timeout, możesz skorzystać z tych procedur przez powolny serwer backendu.

Procedura 1. z użyciem logu czasu

Jeśli problem jest nadal aktywny (postępują 504 błędy), wykonaj czynności opisane poniżej kroki:

Sprawdź interfejs API, którego dotyczy problem, w interfejsie Edge. Poczekaj na wystąpienie błędu lub jeśli masz już wywołanie interfejsu API, a następnie kilka wywołań interfejsu API i odtwarzanie błędu 504 Gateway Timeout.
Gdy wystąpi błąd, sprawdź konkretne żądanie, które wyświetla kod odpowiedzi jako 504
Sprawdź czas, który upłynął w każdej fazie i zanotuj, który z nich trwa wydatki na reklamę.
Jeśli błąd jest najdłuższy, tuż po jednej z kolejnych fazach, oznacza to, że serwer backendu działa wolno lub zajmuje dużo czasu Przetworzenie żądania:
- Żądanie wysłane do serwera docelowego
- Zasady dotyczące wywołań usługi

Poniżej znajdziesz przykładowy log czasu pokazujący, że serwer backendu nie odpowiedział nawet po 55 sekundach, co spowoduje pojawienie się błędu 504 Gateway Timeout:

W powyższym logu czasu działanie procesora wiadomości przekracza 55 002 ms, ponieważ to robi serwer backendu. nie odpowiadać.

Procedura 2. Korzystanie z logów procesora wiadomości

Sprawdź dziennik procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Jeśli znajdziesz błędy Gateway Timeout i onTimeoutRead dotyczące konkretnego żądania serwera proxy interfejsu API w określonym czasie, oznacza to, że upłynął limit czasu procesora wiadomości.

Przykładowy dziennik procesora wiadomości pokazujący błąd związany z limitem czasu bramy

2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

W powyższym dzienniku procesora wiadomości widzisz, że serwer backendu jest oznaczony adresem IP Adres XX.XX.XX.XX nie odpowiada nawet po 55 sekundach (lastIO=55000ms). W rezultacie procesor wiadomości przekroczył limit czasu i wysłał 504 Gateway Timeout błąd.

Sprawdź to: jak odbywa się limit czasu oczekiwania w procesorze wiadomości?

Jak odbywa się limit czasu oczekiwania w procesorze wiadomości. Procesory wiadomości są zwykle ustawiony z domyślną wartością limitu czasu 55 sekund) za pośrednictwem usługi HTTPTransport.io.timeout.millis Ta wartość limitu czasu wynosi dotyczy wszystkich serwerów proxy interfejsów API należących do organizacji obsługiwanej przez ten Procesor komunikatów.
- Jeśli serwer backendu nie odpowie w ciągu 55 sekund, komunikat Przekroczenie limitu czasu procesora i wysyła do klienta 504 Gateway Timeout błąd.
Wartość czasu oczekiwania określona w procesorze wiadomości może być zastąpione przez właściwość io.timeout.millis określony w interfejsie API Proxy. Ta wartość limitu czasu dotyczy konkretnego interfejsu API Serwer proxy, dla którego określono powyższą właściwość. Na przykład, jeśli plik io.timeout.millis jest ustawione na 10 sekund na serwerze proxy API, a następnie W przypadku tego konkretnego serwera proxy interfejsu API zostanie użyta wartość czasu oczekiwania wynosząca 10 sekund.
- Jeśli serwer backendu nie odpowie w ciągu 10 sekund w przypadku Proxy API, wtedy procesor wiadomości przekracza limit czasu i wysyła 504 Gateway Timeout klientowi.

Rozdzielczość

Sprawdź, dlaczego serwer backendu trwa dłużej niż 55 sekund i czy to możliwe naprawiono/zoptymalizowano ją pod kątem szybszego reagowania.
Jeśli nie można naprawić/zoptymalizować serwera backendu lub wiadomo, że serwer backendu serwer trwa dłużej niż ustawiony limit czasu, wtedy Zwiększ limit czasu oczekiwania w routerze i procesorze wiadomości do odpowiedniej wartości.

Sytuacja 2. Przekroczenie limitu czasu oczekiwania routera przed udzieleniem odpowiedzi przez procesor wiadomości/serwer backendu

Jeśli router przekroczy limit czasu przed wysłaniem wiadomości, może wystąpić 504 Gateway Timeout błędów. Odpowiada procesor/serwer backendu. Może się tak zdarzyć w jednej z tych sytuacji:

Limit czasu ustawiony na routerze jest krótszy niż limit czasu ustawiony w wiadomości Procesor. Załóżmy na przykład, że limit czasu oczekiwania na routerze wynosi 50 sekund, a komunikat Procesor trwa 55 sekund.

Upłynął czas oczekiwania na routerze	Upłynął czas oczekiwania na procesor wiadomości
50 sekund	55 sekund

Wartość limitu czasu na procesorze wiadomości jest zastępowana wyższą wartością czasu oczekiwania za pomocą metody właściwość io.timeout.millis ustawiona w konfiguracji docelowego punktu końcowego serwera proxy interfejsu API:

Jeśli na przykład ustawiono takie wartości limitu czasu:

Upłynął czas oczekiwania na routerze	Upłynął czas oczekiwania na procesor wiadomości	Czas oczekiwania w obrębie serwera proxy interfejsu API
57 sekund	55 sekund	120 sekund

Jednak parametr io.timeout.millis na serwerze proxy API ma wartość 120 sekund:

<HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

Następnie procesor wiadomości nie przekroczy limitu czasu po 55 sekundach, mimo że upłynął limit czasu. (55 sekund) jest mniejsza niż limit czasu na routerze (57 sekund). Dzieje się tak, ponieważ wartość limitu czasu wynosząca 55 sekund na procesorze wiadomości zostaje zastąpiona wartością 120 sekund ustawianych na serwerze proxy interfejsu API. A więc wartość limitu czasu procesora wiadomości dla tego konkretnego serwera proxy interfejsu API będzie wynosić 120 sekund.

Router ma niższą wartość limitu czasu (57 sekund) niż 120 sekund ustawiony w serwera proxy API, router przekroczy limit czasu, jeśli serwer backendu nie odpowie po 57 sek.

Diagnostyka

Sprawdź dziennik dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Jeśli przekroczenie limitu czasu oczekiwania routera przed procesorem wiadomości, wyświetli się stan 504 w logach dostępu NGINX dla konkretnego żądania do interfejsu API oraz message id z procesor wiadomości zostanie ustawiony na -. Dzieje się tak, ponieważ router nie otrzymał żadnej odpowiedzi z procesora wiadomości w czasie oczekiwania ustawionym na routerze.

Przykładowy wpis logu NGINX wyświetlający błąd 504 z powodu przekroczenia limitu czasu routera
W powyższym przykładzie zwróć uwagę na stan 504 w NGINX, czyli identyfikator wiadomości z wiadomości Procesor to -, a całkowity czas odtwarzania to 57,001 sekundy. Dzieje się tak, ponieważ przekroczono limit czasu routera po 57 001 sekundzie nie otrzymaliśmy żadnej odpowiedzi.

W takim przypadku zobaczysz Broken Pipe wyjątków w wiadomości Logi procesora (/opt/apigee/var/log/edge-message-processor/logs/system.log).)

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Ten błąd jest wyświetlany, ponieważ po przekroczeniu limitu czasu router zamyka połączenie z Procesor komunikatów. Gdy procesor wiadomości zakończy przetwarzanie, spróbuje zapisać odpowiedź do routera. Ponieważ połączenie z routerem zostało już zamknięte, Broken Pipe exception w procesorze wiadomości.

Taki wyjątek powinien wystąpić w okolicznościach opisanych powyżej. Zatem faktyczna wartość przyczyną błędu 504 Gateway Timeout nadal jest to, że odpowiedź serwera backendu trwa dłużej niż zwykle i trzeba się nim zająć.

Rozdzielczość

Jeśli jest to niestandardowy serwer backendu,

Sprawdź, dlaczego serwer backendu tak długo odpowiada, i zobacz, czy to możliwe. naprawiono/zoptymalizowano ją pod kątem szybszego reagowania.

Jeśli nie można naprawić/zoptymalizować serwera backendu lub wiadomo, że serwer backendu zajmuje dużo czasu, a następnie zwiększ wartość limitu czasu na Router i procesor wiadomości.

Propozycja: Ustaw wartość limitu czasu dla różnych komponentów w zamówienie:

Limit czasu na kliencie > Limit czasu na routerze > Upłynął czas oczekiwania na odpowiedź Procesor > Limit czasu w przypadku serwera proxy interfejsu API

Jeśli jest to serwer backendu NodeJS:
1. Sprawdź, czy kod NodeJS wywołuje inne serwery backendu i czy przejmuje zbyt długi czas na zwrócenie odpowiedzi. sprawdzić, dlaczego serwery backendu potrzebują więcej czasu; rozwiąż problem stosownie do potrzeb.
2. Sprawdź, czy procesory wiadomości nie obciążają procesora lub pamięcią nadmiernie:
  1. Jeśli którykolwiek z procesorów wiadomości odnotowuje duże obciążenie CPU, wygeneruj trzy wątek dumps co 30 sekund, korzystając z następującego polecenia:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jeśli jakikolwiek procesor wiadomości doświadcza dużego wykorzystania pamięci, wygeneruj sterta dump za pomocą tego polecenia:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Ponownie uruchom procesor wiadomości, korzystając z poniższego polecenia. To powinno zmniejszyć obciążenie procesora i pamięć:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Monitoruj wywołania interfejsu API, aby potwierdzić, czy problem nadal występuje.
  5. Skontaktuj się z zespołem pomocy Apigee Edge i podaj zrzuty stosu, zrzuty stosu i logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log)aby uzyskać pomoc zbadać przyczynę wysokiego wykorzystania procesora/pamięci.

Sprawdź to: jak kontrolowane jest limit czasu dla serwerów backendu NodeJS w wiadomości Procesor

Serwer backendu NodeJS działa w ramach procesu JVM procesora wiadomości. limit czasu dla serwerów backendu NodeJS jest sterowany za pomocą właściwości http.request.timeout.seconds w pliku nodejs.properties. Ten ma domyślnie wartość 0, co oznacza, że limit czasu jest domyślnie wyłączony dla wszystkich Serwery proxy interfejsów API należące do organizacji obsługiwanej przez ten procesor komunikatów. Nawet jeśli gdy serwer backendu NodeJS potrzebuje dużo czasu, procesor komunikatów nie przekroczy limitu czasu.
Jeśli jednak serwer backendu NodeJS trwa długo i czas działania interfejsu API żądanie to > 57 sekund, wtedy router przekroczy limit czasu i wyśle 504 Gateway Timeout klientowi.

Scenariusz 3. Przekroczenie limitu czasu aplikacji klienckiej przed routerem, procesorem wiadomości lub serwerem backendu odpowiada

Błędy 504 Gateway Timeout mogą wystąpić, jeśli przekroczenie limitu czasu aplikacji klienckiej przed odpowiada serwer backendu. Może się tak zdarzyć, jeśli:

Limit czasu ustawiony w aplikacji klienckiej jest krótszy niż limit czasu ustawiony w routera i procesor wiadomości:

Jeśli na przykład ustawiono takie wartości limitu czasu:

Upłynął limit czasu klienta	Upłynął czas oczekiwania na routerze	Upłynął czas oczekiwania na procesor wiadomości
50 sekund	57 sekund	55 sekund

W tym przypadku łączny czas, w którym można otrzymać odpowiedź na żądanie do interfejsu API przez Edge wynosi <= 50 sekund. Obejmuje to czas potrzebny na wysłanie żądania do interfejsu API, przetwarzane przez serwer Edge (router, procesor wiadomości) żądanie wysyłane do serwera backendu (w stosownych przypadkach), backend przetwarza żądanie i wysyła odpowiedź, i wysyłanie jej do klienta.

Jeśli router nie odpowie klientowi w ciągu 50 sekund, przekroczenie limitu czasu i zamknięcie połączenia z routerem. Klient otrzyma kod odpowiedzi 504

Spowoduje to, że NGINX ustawi kod stanu 499 wskazujący, że klient zamknął połączenia.

Diagnostyka

Jeśli aplikacja kliencka przekroczy limit czasu, zanim otrzyma odpowiedź z routera, to zrobi Zakończ połączenie z routerem. W takim przypadku w filmie pojawi się kod stanu 499 logi dostępu NGINX dla konkretnego żądania do interfejsu API.
Przykładowy wpis logu NGINX z kodem stanu 499
W powyższym przykładzie stan 499 w NGINX i całkowity czas, który upłynął, to 50,001 sekundy. Oznacza to, że przekroczono limit czasu klienta po 50,001 sekundy.

W takim przypadku w wiadomości zobaczysz Broken Pipe wyjątków Logi procesora (/opt/apigee/var/log/edge-message-processor/logs/system.log).
)

2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

Po upływie limitu czasu routera zamyka połączenie z procesorem wiadomości. Gdy Procesor wiadomości kończy przetwarzanie i próbuje zapisać odpowiedź do routera. Połączenie z routerem jest już zamknięte, dlatego pakiet Broken Pipe exception jest dostępny na procesorze wiadomości.
Taki wyjątek jest normalny w opisanych powyżej okolicznościach. Zatem faktyczna przyczyna błąd 504 Gateway Timeout nadal polega na tym, że odpowiedź serwera backendu zajmuje dużo czasu i musisz się tym zająć.

Rozdzielczość

Jeśli jest to Twój niestandardowy serwer backendu:

Sprawdź serwer backendu, aby ustalić, dlaczego trwa to dłużej niż 57 sekund, i sprawdź, można ją naprawić lub zoptymalizować, by szybciej reagować.

Jeśli nie można naprawić/zoptymalizować serwera backendu lub jeśli wiesz, że serwer backendu zajmie dużo czasu, po czym zwiększ wartość limitu czasu na routerem i procesorem wiadomości.

Propozycja: Ustaw wartość limitu czasu dla różnych komponentów w zamówienie:

Limit czasu na kliencie > Limit czasu na routerze > Upłynął czas oczekiwania na odpowiedź Procesor > Limit czasu w przypadku serwera proxy interfejsu API

Jeśli jest to backend NodeJS, to:
1. Sprawdź, czy kod NodeJS wywołuje inne serwery backendu, a jeśli to ich powrót zajmuje dużo czasu. Sprawdź, dlaczego te serwery backendu potrzebują więcej czasu.
2. Sprawdź, czy procesory wiadomości nie obciążają procesora lub pamięcią nadmiernie:
  1. Jeśli procesor wiadomości mocno obciąża CPU, wygeneruj trzy wątek dumps co 30 sekund, korzystając z następującego polecenia:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jeśli procesor wiadomości notuje duże wykorzystanie pamięci, zrzut stosu za pomocą tego polecenia:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Ponownie uruchom procesor wiadomości, korzystając z poniższego polecenia. Powinno to zmniejszyć Procesor i pamięć:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Monitoruj wywołania interfejsu API, aby potwierdzić, czy problem nadal występuje.
  5. Skontaktuj się z zespołem pomocy Apigee Edge i podaj zrzuty stosu, zrzuty stosu i logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log)aby im pomóc, zbadać przyczynę wysokiego wykorzystania procesora/pamięci.

Zwiększ limit czasu Router i procesor wiadomości

Starannie wybierz wartości czasu oczekiwania, które będą ustawione w routerze i procesorze wiadomości, zależnie od tego, swoje wymagania. Nie ustawiaj arbitralnie dużych wartości limitu czasu. Jeśli potrzebujesz pomocy, skontaktuj się z Obsługa Apigee Edge

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties

Utwórz plik /opt/apigee/customer/application/router.properties w Router (jeśli jeszcze nie istnieje).

Dodaj do tego pliku ten wiersz:

conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

Jeśli na przykład chcesz ustawić limit czasu na 120 sekund, ustaw go jako następujące:

conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

Sprawdź, czy ten plik należy do Apigee:

Ponownie uruchom router:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Jeśli masz więcej niż 1 router, powtórz powyższe kroki na wszystkich z nich.

procesor komunikatów

Utwórz plik /opt/apigee/customer/application/message-processor.properties i komputera z procesorem wiadomości, jeśli jeszcze nie istnieje.
Dodaj do tego pliku ten wiersz:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Jeśli na przykład chcesz ustawić limit czasu na 120 sekund, ustaw go jako następujące:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Sprawdź, czy ten plik należy do Apigee:

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

Ponownie uruchom procesor wiadomości:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Jeśli masz więcej niż jeden procesor wiadomości, powtórz powyższe kroki dla wszystkich Procesory.

Propozycja: Ustaw wartość limitu czasu dla różnych komponentów w następującej kolejności:

Limit czasu na kliencie > Limit czasu na routerze > Upłynął czas oczekiwania na procesor wiadomości > Limit czasu w przypadku serwera proxy interfejsu API

Powolne przetwarzanie żądań do interfejsu API przez Edge

Jeśli Edge działa bardzo wolno i przetwarzanie żądania do interfejsu API zajmuje dużo czasu, otrzymasz 504 Gateway Timeout błąd.

Diagnostyka

Sprawdź interfejs API, którego dotyczy problem, w interfejsie Edge.
Poczekaj na wystąpienie błędu lub jeśli masz wywołanie interfejsu API, a następnie wykonaj kilka wywołań interfejsu API. i odtworzyć błąd 504 Gateway Timeout.
Uwaga: w takim przypadku w śledzeniu może się wyświetlać pomyślna odpowiedź.
1. Upłynął limit czasu routera/klienta, ponieważ procesor wiadomości nie odpowiada w określony czas oczekiwania w routerze/kliencie (w zależności od tego, który okres jest najkrótszy). Procesor wiadomości kontynuuje jednak przetwarzanie żądania i może zakończyć .
2. Dodatkowo wartość HTTPTransport.io.timeout.millis ustawiona w Procesor wiadomości jest wyzwalany tylko wtedy, gdy procesor wiadomości komunikuje się z protokołem HTTP/HTTPS z serwera backendu. Innymi słowy, limit czasu nie zostanie aktywowany, gdy którakolwiek zasada (inna niż zasady ServiceCallout), w obrębie serwera proxy interfejsu API zajmuje dużo czasu.
Po wystąpieniu błędu sprawdź konkretne żądanie, które ma najdłuższy upływ czasu.
Sprawdź czas, który upłynął w każdej fazie i zanotuj, w której fazy trwa najdłuższy czas. wydanej na reklamę.
Jeśli Użytkownik zaobserwuje najdłuższy czas w ramach którejkolwiek z zasad innych niż Usługa Callout policy, oznacza to, że przetwarzanie przez Edge dużo czasu zajmuje użytkownika.
Oto przykładowy log czasu interfejsu pokazujący bardzo długi czas, jaki upłynął od zasady JavaScript:
W powyższym przykładzie zauważasz, że zasada JavaScriptu pobiera nienormalnie długi czas trwa około 245 sekund.

Rozdzielczość

Sprawdź, czy oczekiwanie na odpowiedź z zasadami trwa zbyt długo i czy nie ma żadnego niestandardowego kodu, który może zająć dużo czasu. Jeśli masz taki kod, sprawdź, czy możesz poprawić/zoptymalizować zidentyfikowany kod.
Jeśli nie ma niestandardowego kodu, który może powodować długi czas przetwarzania, sprawdź, czy komunikat Procesory znacznie obciążają procesor lub pamięć:
1. Jeśli którykolwiek z procesorów wiadomości odnotowuje duże obciążenie CPU, wygeneruj trzy wątek dumps co 30 sekund, korzystając z następującego polecenia:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Jeśli dowolny procesor wiadomości wykorzystuje dużo pamięci, zrzut stosu za pomocą tego polecenia:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Ponownie uruchom procesor wiadomości, korzystając z poniższego polecenia. To powinno zmniejszyć obciążenie procesora i Pamięć.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Monitoruj wywołania interfejsu API i sprawdź, czy problem nadal występuje.
5. Skontaktuj się z zespołem pomocy Apigee Edge i podaj wątek zrzuty stosu, zrzuty stosu i dzienniki procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log)aby im pomóc, zbadać przyczynę wysokiego wykorzystania procesora/pamięci.

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

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 kodów stanu 504 przekroczy określony próg.