504 Przekroczenie limitu czasu bramy

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Krótki opis problemu

Aplikacja kliencka otrzymuje kod stanu HTTP 504 z komunikatem Gateway Timeout w odpowiedzi na wywołania interfejsu API.

Błąd kodu stanu HTTP – 504 Gateway Timeout oznacza, że klient nie otrzymał w odpowiednim czasie odpowiedzi z bramy brzegowej lub serwera backendu podczas wykonywania interfejsu 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 limitu czasu bramy?

Typowa ścieżka żądania do interfejsu API za pomocą platformy Edge to Klient –> Router –> Procesor komunikatów –> Serwer backendu, jak pokazano na rysunku poniżej:

Aplikacja kliencka, routery i procesory wiadomości na platformie Edge są skonfigurowane z odpowiednimi wartościami limitu czasu. Platforma Edge oczekuje, że w przypadku każdego żądania do interfejsu API w określonym czasie zostanie wysłana odpowiedź na podstawie wartości limitu czasu. Jeśli nie otrzymasz odpowiedzi w określonym czasie, zwracana jest wartość 504 Gateway Timeout Error.

Więcej informacji o tym, kiedy w Edge mogą wystąpić przekroczenia limitu czasu, znajdziesz w tabeli poniżej:

Możliwe przyczyny

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

Powolny serwer backendu

Jeśli serwer backendu działa bardzo wolno lub długo przetwarza żądanie do interfejsu API, pojawi się błąd 504 Gateway Timeout. Jak wyjaśniliśmy w sekcji powyżej, limit czasu może zostać przekroczony w jednej z tych sytuacji:

1. Procesor komunikatów przekracza limit czasu, zanim serwer backendu odpowie.
2. Router przekracza limit czasu, zanim procesor komunikatów lub serwer backendu odpowie.
3. Aplikacja kliencka przekracza limit czasu, zanim router, procesor komunikatów lub serwer backendu odpowie.

W sekcjach poniżej znajdziesz informacje o tym, jak zdiagnozować i rozwiązać problem w każdym z tych scenariuszy.

Scenariusz 1 Procesor komunikatów przekracza limit czasu, zanim serwer backendu odpowie

Diagnostyka

Aby sprawdzić, czy błąd 504 Gateway Timeout wystąpił z powodu powolnego serwera backendu, wykonaj te czynności:

Procedura 1. Używanie narzędzia Trace

Jeśli problem nadal występuje (nadal pojawiają się błędy 504), wykonaj te czynności:

1. Śledź interfejs API, którego dotyczy problem, w interfejsie Edge. Poczekaj na wystąpienie błędu lub, jeśli masz wywołanie interfejsu API, wykonaj kilka wywołań i odtwórz błąd 504 Gateway Timeout.
2. Gdy wystąpi błąd, sprawdź konkretne żądanie, w którym kod odpowiedzi to 504.
3. Sprawdź czas, jaki upłynął w każdej fazie, i zanotuj, w której fazie spędzasz najwięcej czasu.
4. Jeśli błąd z najdłuższym czasem trwania występuje bezpośrednio po jednej z tych faz, oznacza to, że serwer backendu działa wolno lub długo przetwarza żądanie:
   • Żądanie zostało wysłane na serwer docelowy
   • Zasada ServiceCallout

Poniżej znajduje się przykładowy ślad pokazujący, że serwer backendu nie odpowiedział nawet po 55 sekundach, co spowodowało błąd 504 Gateway Timeout:

W powyższym logu czasu procesor komunikatów przekracza limit czasu po 55002 ms, ponieważ serwer backendu nie odpowiada.

Procedura 2. Korzystanie z logów procesora komunikatów

1. Sprawdź dziennik procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2. Jeśli w przypadku konkretnego żądania proxy interfejsu API w określonym czasie wystąpią błędy Gateway Timeout i onTimeoutRead, oznacza to, że przekroczono limit czasu procesora komunikatów.

   Przykładowy dziennik procesora komunikatów z błędem przekroczenia limitu 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 komunikatów widać, że serwer backendu oznaczony adresem IP XX.XX.XX.XX nie odpowiedział nawet po 55 sekundach (lastIO=55000ms). W rezultacie procesor komunikatów przekroczył limit czasu i wysłał błąd 504 Gateway Timeout.

   Sprawdź: Jak kontrolować limit czasu w procesorze komunikatów? Jak kontrolowany jest limit czasu w procesorze komunikatów? Procesory wiadomości są zwykle konfigurowane z domyślną wartością limitu czasu wynoszącą 55 sekund za pomocą właściwości HTTPTransport.io.timeout.millis. Ten czas oczekiwania dotyczy wszystkich serwerów proxy interfejsu API należących do organizacji obsługiwanej przez ten procesor komunikatów. Jeśli serwer backendu nie odpowie w ciągu 55 sekund, procesor wiadomości przekroczy limit czasu i wyśle do klienta błąd 504 Gateway Timeout. Wartość limitu czasu określona w procesorze komunikatów może zostać zastąpiona przez właściwość io.timeout.millis określoną w proxy interfejsu API. Ten limit czasu dotyczy konkretnego serwera proxy interfejsu API, w którym określono wspomnianą powyżej właściwość. Jeśli na przykład w proxy interfejsu API parametr io.timeout.millis ma wartość 10 sekund, to w przypadku tego konkretnego proxy interfejsu API będzie używana wartość limitu czasu wynosząca 10 sekund. Jeśli serwer backendu nie odpowie w ciągu 10 sekund w przypadku konkretnego proxy interfejsu API, procesor komunikatów przekroczy limit czasu i wyśle do klienta błąd 504 Gateway Timeout.

Rozdzielczość

1. Sprawdź, dlaczego serwer backendu potrzebuje więcej niż 55 sekund, i zobacz, czy można to naprawić lub zoptymalizować, aby szybciej odpowiadał.
2. Jeśli nie można naprawić lub zoptymalizować serwera backendu albo wiadomo, że serwer backendu działa dłużej niż skonfigurowany limit czasu, zwiększ limit czasu na routerze i procesorze komunikatów do odpowiedniej wartości.

Scenariusz nr 2 – router przekracza limit czasu, zanim procesor komunikatów lub serwer backendu odpowie

Jeśli router przekroczy limit czasu, zanim odpowie procesor wiadomości lub serwer backendu, mogą wystąpić 504 Gateway Timeoutbłędy. Może się tak zdarzyć w jednej z tych sytuacji:

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

  Przekroczony czas oczekiwania na routerze	Upłynął limit czasu oczekiwania na procesor komunikatów
  50 sekund	55 sekund

• Wartość limitu czasu w procesorze komunikatów jest zastępowana wyższą wartością limitu czasu za pomocą właściwości io.timeout.millis ustawionej w konfiguracji docelowego punktu końcowego proxy interfejsu API:

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

  Przekroczony czas oczekiwania na routerze	Upłynął limit czasu oczekiwania na procesor komunikatów	Przekroczenie limitu czasu w proxy interfejsu API
  57 sekund	55 sekund	120 sekund

  W przypadku proxy interfejsu API wartość io.timeout.millis jest ustawiona na 120 sekund:

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

  W takim przypadku procesor komunikatów nie przekroczy limitu czasu po 55 sekundach, mimo że jego wartość limitu czasu (55 sekund) jest mniejsza niż wartość limitu czasu na routerze (57 sekund). Dzieje się tak, ponieważ wartość limitu czasu 55 sekund w procesorze komunikatów jest zastępowana wartością 120 sekund ustawioną w proxy interfejsu API. W przypadku tego konkretnego proxy interfejsu API wartość limitu czasu procesora komunikatów wyniesie 120 sekund.

  Ponieważ router ma niższy limit czasu oczekiwania (57 sekund) niż 120 sekund ustawionych w proxy interfejsu API, przekroczy on limit czasu, jeśli serwer backendu nie odpowie po 57 sekundach.

Diagnostyka

1. Sprawdź log dostępu NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. Jeśli router przekroczy limit czasu przed procesorem komunikatów, w logach dostępu NGINX dla konkretnego żądania do interfejsu API zobaczysz stan 504, a wartość message id z procesora komunikatów zostanie ustawiona jako -. Dzieje się tak, ponieważ router nie otrzymał żadnej odpowiedzi z procesora komunikatów w okresie oczekiwania ustawionym na routerze.

   Przykładowy wpis w logu NGINX pokazujący błąd 504 spowodowany przekroczeniem limitu czasu przez router

   

3. W powyższym przykładzie zwróć uwagę na stan 504 na serwerze NGINX, identyfikator wiadomości z procesora wiadomości - i łączny czas, który upłynął – 57,001 sekundy. Wynika to z faktu, że po 57,001 sekundy router przekroczył limit czasu i nie otrzymaliśmy odpowiedzi z procesora komunikatów.
4. W takim przypadku w logach procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).) zobaczysz wyjątki Broken Pipe.

   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 upływie limitu czasu router zamyka połączenie z procesorem komunikatów. Gdy procesor komunikatów zakończy przetwarzanie, próbuje zapisać odpowiedź w routerze. Połączenie z routerem jest już zamknięte, więc na procesorze komunikatów pojawi się symbol Broken Pipe exception.

Ten wyjątek powinien być widoczny w okolicznościach opisanych powyżej. Prawdziwą przyczyną błędu 504 Gateway Timeout jest to, że serwer backendu potrzebuje więcej czasu na odpowiedź. Musisz rozwiązać ten problem.

Rozdzielczość

1. Jeśli jest to niestandardowy serwer backendu:
   1. Sprawdź, dlaczego serwer backendu długo odpowiada, i zobacz, czy można to naprawić lub zoptymalizować, aby szybciej odpowiadał.
   2. Jeśli nie można naprawić lub zoptymalizować serwera backendu albo wiadomo, że serwer backendu działa długo, zwiększ wartość limitu czasu na routerze i procesorze komunikatów.

      Pomysł: ustaw wartość czasu bezczynności w różnych komponentach w tej kolejności: Przekroczenie limitu czasu po stronie klienta > Przekroczenie limitu czasu na routerze > Przekroczenie limitu czasu w procesorze wiadomości > Przekroczenie limitu czasu w proxy interfejsu API

2. Jeśli jest to serwer backendu NodeJS:
   1. Sprawdź, czy kod NodeJS wywołuje inne serwery backendu i czy długo trwa zwracanie odpowiedzi. Sprawdź, dlaczego serwery backendu działają wolniej, i rozwiąż problem.
   2. Sprawdź, czy procesory komunikatów wykazują wysokie wykorzystanie procesora lub wykorzystanie pamięci:
      1. Jeśli którykolwiek procesor komunikatów wykazuje wysokie wykorzystanie procesora, wygeneruj 3 zrzuty wątków co 30 sekund za pomocą tego polecenia:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Jeśli którykolwiek z procesorów komunikatów wykazuje wysokie wykorzystanie pamięci, wygeneruj zrzut sterty za pomocą tego polecenia:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Uruchom ponownie procesor komunikatów za pomocą tego polecenia. Powinno to zmniejszyć obciążenie procesora i pamięci:

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

      4. Monitoruj wywołania interfejsu API, aby sprawdzić, czy problem nadal występuje.
      5. Skontaktuj się z zespołem pomocy Apigee Edge i prześlij zrzuty wątków, zrzut sterty i logi procesora komunikatów/opt/apigee/var/log/edge-message-processor/logs/system.log), aby pomóc w zbadaniu przyczyny wysokiego wykorzystania procesora lub wykorzystania pamięci.

Scenariusz 3. Aplikacja kliencka przekracza limit czasu oczekiwania, zanim router, procesor komunikatów lub serwer backendu odpowie

Jeśli aplikacja kliencka przekroczy limit czasu przed odpowiedzią serwera backendu, możesz otrzymać błędy 504 Gateway Timeout. Może się tak zdarzyć, jeśli:

1. Wartość limitu czasu ustawiona w aplikacji klienckiej jest niższa niż wartość limitu czasu ustawiona w routerze i procesorze komunikatów:

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

   Przekroczenie limitu czasu na urządzeniu klienta	Przekroczony czas oczekiwania na routerze	Upłynął limit czasu oczekiwania na procesor komunikatów
   50 sekund	57 sekund	55 sekund

   W tym przypadku łączny czas dostępny na uzyskanie odpowiedzi na żądanie do interfejsu API za pomocą Edge wynosi ≤ 50 sekund. Obejmuje to czas potrzebny na wysłanie żądania do interfejsu API, przetworzenie żądania przez Edge (router, procesor wiadomości), wysłanie żądania do serwera backendu (w stosownych przypadkach), przetworzenie żądania przez backend i wysłanie odpowiedzi, przetworzenie odpowiedzi przez Edge i ostateczne wysłanie jej z powrotem do klienta.

   Jeśli router nie odpowie klientowi w ciągu 50 sekund, klient przekroczy limit czasu i zamknie połączenie z routerem. Klient otrzyma kod odpowiedzi 504.

   Spowoduje to ustawienie przez NGINX kodu stanu 499, który wskazuje, że klient zamknął połączenie.

Diagnostyka

1. Jeśli aplikacja kliencka przekroczy limit czasu, zanim otrzyma odpowiedź z routera, zamknie połączenie z routerem. W takiej sytuacji w logach dostępu NGINX dla konkretnego żądania do interfejsu API zobaczysz kod stanu 499.

   Przykładowy wpis w dzienniku NGINX z kodem stanu 499
   
   

2. W powyższym przykładzie zwróć uwagę, że stan 499 na serwerze NGINX i łączny czas, który upłynął, to 50,001 sekundy. Oznacza to, że klient przekroczył limit czasu po 50,001 sekundy.
3. W takim przypadku w logach procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   ) zobaczysz Broken Pipe Wyjątki.

   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>

4. Po upłynięciu limitu czasu router zamyka połączenie z procesorem komunikatów. Gdy procesor komunikatów zakończy przetwarzanie, próbuje zapisać odpowiedź w routerze. Połączenie z routerem jest już zamknięte, więc na procesorze komunikatów pojawia się symbol Broken Pipe exception.
5. W okolicznościach opisanych powyżej ten wyjątek jest oczekiwany. Prawdziwą przyczyną błędu 504 Gateway Timeout jest to, że serwer backendu długo nie odpowiada, i musisz rozwiązać ten problem.

Rozdzielczość

1. Jeśli jest to Twój niestandardowy serwer backendu:
   1. Sprawdź serwer backendu, aby ustalić, dlaczego odpowiedź zajmuje mu ponad 57 sekund, i zobacz, czy można to naprawić lub zoptymalizować, aby serwer szybciej odpowiadał.
   2. Jeśli nie można naprawić ani zoptymalizować serwera backendu lub jeśli wiesz, że zajmie to dużo czasu, zwiększ wartość limitu czasu na routerze i procesorze komunikatów.
      
      

      Pomysł: ustaw wartość czasu bezczynności w różnych komponentach w tej kolejności: Przekroczenie limitu czasu po stronie klienta > Przekroczenie limitu czasu na routerze > Przekroczenie limitu czasu w procesorze wiadomości > Przekroczenie limitu czasu w proxy interfejsu API

2. Jeśli jest to backend NodeJS:
   1. Sprawdź, czy kod NodeJS wywołuje inne serwery backendu i czy długo trwa zwracanie przez nie odpowiedzi. Sprawdź, dlaczego serwery backendu działają wolniej.
   2. Sprawdź, czy procesory wiadomości mają wysokie wykorzystanie procesora lub pamięci:
      1. Jeśli procesor komunikatów wykazuje wysokie wykorzystanie procesora, wygeneruj 3 zrzuty wątków co 30 sekund za pomocą tego polecenia:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Jeśli procesor komunikatów wykazuje wysokie wykorzystanie pamięci, wygeneruj zrzut sterty za pomocą tego polecenia:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Uruchom ponownie procesor komunikatów za pomocą tego polecenia. Powinno to zmniejszyć wykorzystanie procesora i pamięci:

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

      4. Monitoruj wywołania interfejsu API, aby sprawdzić, czy problem nadal występuje.
      5. Skontaktuj się z zespołem pomocy Apigee Edge i prześlij zrzuty wątków, zrzut sterty i dzienniki procesora komunikatów/opt/apigee/var/log/edge-message-processor/logs/system.log), aby pomóc zespołowi w zbadaniu przyczyny wysokiego wykorzystania procesora lub wykorzystania pamięci.

Zwiększ wartość limitu czasu na routerze i procesorze komunikatów.

Wybierz wartości limitu czasu, które mają być ustawione w routerze i procesorze komunikatów, w zależności od wymagań. Nie ustawiaj dowolnie dużych wartości czasu bezczynności. Jeśli potrzebujesz pomocy, skontaktuj się z zespołem pomocy Apigee Edge.

Router

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

1. Utwórz plik /opt/apigee/customer/application/router.properties na komputerze routera, jeśli jeszcze nie istnieje.
2. 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ć wartość limitu czasu na 120 sekund, zrób to w ten sposób:

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

3. Upewnij się, że właścicielem tego pliku jest apigee:
4. Ponownie uruchom router:

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

5. Jeśli masz więcej niż 1 router, powtórz powyższe czynności na wszystkich routerach.

procesor komunikatów

1. Utwórz plik /opt/apigee/customer/application/message-processor.properties na komputerze procesora komunikatów, jeśli jeszcze nie istnieje.
2. Dodaj do tego pliku ten wiersz:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   Jeśli na przykład chcesz ustawić wartość limitu czasu na 120 sekund, zrób to w ten sposób:

   conf_http_HTTPTransport.io.timeout.millis=120000

3. Upewnij się, że właścicielem tego pliku jest apigee:

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

4. Uruchom ponownie procesor komunikatów:

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

5. Jeśli masz więcej niż 1 procesor komunikatów, powtórz powyższe czynności na wszystkich procesorach komunikatów.

Powolne przetwarzanie żądań do interfejsu API przez Edge

Jeśli Edge działa bardzo wolno lub przetworzenie żądania do interfejsu API zajmuje dużo czasu, pojawi się błąd 504 Gateway Timeout.

Diagnostyka

1. Śledź interfejs API, którego dotyczy problem, w interfejsie Edge.
2. Poczekaj na wystąpienie błędu lub, jeśli masz wywołanie interfejsu API, wykonaj kilka wywołań interfejsu API i odtwórz błąd 504 Gateway Timeout.
3. Pamiętaj, że w tym przypadku w śladzie możesz zobaczyć odpowiedź o sukcesie.
   1. Router lub klient przekracza limit czasu, ponieważ procesor komunikatów nie odpowiada w określonym czasie oczekiwania na routerze lub kliencie (w zależności od tego, który ma najkrótszy czas oczekiwania). Procesor komunikatów nadal przetwarza żądanie i może je ukończyć.
   2. Dodatkowo wartość HTTPTransport.io.timeout.millis ustawiona w procesorze komunikatów jest wywoływana tylko wtedy, gdy procesor komunikatów komunikuje się z serwerem backendu HTTP/HTTPS. Innymi słowy, ten limit czasu nie zostanie wywołany, gdy jakakolwiek zasada (inna niż zasada ServiceCallout) w ramach serwera proxy interfejsu API będzie działać zbyt długo.
4. Po wystąpieniu błędu sprawdź konkretne żądanie, które ma najdłuższy czas.
5. Sprawdź czas, który upłynął w każdej fazie, i zanotuj, w której fazie spędzasz najwięcej czasu.
6. Jeśli najdłuższy czas przetwarzania występuje w przypadku którejkolwiek z zasad innych niż zasada Service Callout, oznacza to, że Edge długo przetwarza żądanie.
7. Oto przykładowy ślad interfejsu pokazujący bardzo długi czas przetwarzania zasad JavaScript:

   

8. W powyższym przykładzie widać, że zasady JavaScript działają wyjątkowo długo, bo około 245 sekund.

Rozdzielczość

1. Sprawdź, czy zasady, które długo odpowiadały, nie zawierają niestandardowego kodu, którego przetworzenie może zająć dużo czasu. Jeśli taki kod istnieje, sprawdź, czy możesz go naprawić lub zoptymalizować.
2. Jeśli nie ma kodu niestandardowego, który mógłby powodować długi czas przetwarzania, sprawdź, czy procesory wiadomości wykazują wysokie wykorzystanie procesora lub pamięci:
   1. Jeśli którykolwiek procesor komunikatów wykazuje wysokie wykorzystanie procesora, wygeneruj 3 zrzuty wątków co 30 sekund za pomocą tego polecenia:

      JAVA_HOME/bin/jstack -l PID > FILENAME

   2. Jeśli którykolwiek z procesorów komunikatów ma wysokie wykorzystanie pamięci, wygeneruj zrzut sterty za pomocą tego polecenia:

      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

   3. Uruchom ponownie procesor komunikatów za pomocą tego polecenia. Powinno to zmniejszyć wykorzystanie procesora i pamięci.

      /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 przekaż mu zrzuty wątków, zrzut stosu i logi procesora komunikatów (/opt/apigee/var/log/edge-message-processor/logs/system.log)aby pomóc mu zbadać przyczynę wysokiego wykorzystania procesora lub wykorzystania pamięci.

Diagnozowanie problemów za pomocą monitorowania interfejsu API

Monitorowanie interfejsu API umożliwia szybkie odizolowanie obszarów, w których występują problemy, aby zdiagnozować błędy, problemy z wydajnością i czasem oczekiwania oraz ich źródło, takie jak aplikacje deweloperów, serwery proxy interfejsów API, docelowe systemy backendu lub platforma interfejsu API.

Przejdź przez przykładowy scenariusz, który pokazuje, jak rozwiązywać problemy z kodami błędów 5xx w interfejsach API za pomocą usługi API Monitoring. Możesz na przykład skonfigurować alert, aby otrzymywać powiadomienia, gdy liczba kodów stanu 504 przekroczy określony próg.