504 Przekroczenie limitu czasu bramy

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

Krótki opis problemu

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

Kod stanu HTTP – błąd 504 Gateway Timeout oznacza, że podczas wykonywania interfejsu API klient nie otrzymał na czas odpowiedzi z bramy brzegowej lub serwera backendu.

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ę taki komunikat o błędzie:

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

Co powoduje przekroczenia limitu czasu bramy?

Typowa ścieżka żądania interfejsu API wysyłanego przez platformę brzegową to Client -> Router -> Message Processor -> Backend Server, jak pokazano na ilustracji poniżej:

Aplikacja kliencka, routery i procesory wiadomości na platformie Edge są skonfigurowane z odpowiednimi wartościami czasu oczekiwania. Platforma Edge wymaga, aby odpowiedź na każde żądanie do interfejsu API została wysłana w określonym czasie, zgodnie z wartościami limitów czasu oczekiwania. Jeśli nie otrzymasz odpowiedzi w określonym czasie, zwracana jest wartość 504 Gateway Timeout Error.

Poniższa tabela zawiera więcej informacji na temat tego, kiedy w Edge mogą wystąpić limity czasu:

Upłynął limit czasu Szczegóły
Przekroczono limit czasu w procesorze wiadomości
  • Serwer backendu nie odpowiada na procesor wiadomości przez określony czas oczekiwania.
  • Upłynął limit czasu procesora wiadomości i wysyła do routera stan odpowiedzi jako 504 Gateway Timeout.
Upłynął limit czasu na routerze
  • Procesor wiadomości nie odpowiada na router przez określony w nim czas oczekiwania.
  • Router przekroczył limit czasu, dlatego wysyła do aplikacji klienckiej stan odpowiedzi jako 504 Gateway Timeout.
Upłynął limit czasu w aplikacji klienckiej
  • Router nie odpowiada na aplikację kliencką przez określony czas oczekiwania na routerze.
  • Aplikacja kliencka przekracza limit czasu i kończy stan odpowiedzi użytkownika 504 Gateway Timeout.

Możliwe przyczyny

Typowe przyczyny błędu 504 Gateway Timeout w Edge:

Przyczyna Szczegóły Kroki podane dla
Powolny serwer backendu Serwer backendu, który przetwarza żądanie do interfejsu API, działa zbyt wolno z powodu dużego obciążenia lub niskiej wydajności. Publiczni i prywatni użytkownicy chmury
Powolne przetwarzanie żądań do interfejsu API przez Edge Edge zajmuje dużo czasu z powodu dużego obciążenia lub niskiej wydajności.

Powolny serwer backendu

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

  1. Upłynął limit czasu przetwarzania wiadomości, zanim serwer backendu odpowie.
  2. Limit czasu routera został przekroczony przed udzieleniem odpowiedzi przez procesor wiadomości/serwer backendu.
  3. Upłynął limit czasu aplikacji klienckiej, zanim odpowiedź routera/procesora wiadomości/serwera backendu.

Poniżej opisujemy, jak diagnozować i rozwiązywać problemy w każdym z tych scenariuszy.

Scenariusz nr 1 Upłynął limit czasu przetwarzania wiadomości, zanim serwer backendu odpowie

Diagnostyka

Aby sprawdzić, czy wystąpił błąd 504 Gateway Timeout z powodu powolnego serwera backendu, możesz skorzystać z poniższych procedur.

Procedura nr 1 z korzystaniem z systemu śledzenia

Jeśli problem jest nadal aktywny (występuje 504 błędów), wykonaj te czynności:

  1. Znajdź interfejs API, którego dotyczy problem, w interfejsie użytkownika Edge. 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.
  2. Po wystąpieniu błędu sprawdź konkretne żądanie wyświetlające kod odpowiedzi jako 504.
  3. Sprawdź czas trwania poszczególnych faz i zanotuj, w których z nich spędzasz najwięcej czasu.
  4. Jeśli błąd występuje najdłużej bezpośrednio po jednej z poniższych faz, oznacza to, że serwer backendu działa wolno lub długo przetwarza żądanie:
    • Żądanie wysłane do serwera docelowego
    • Zasady dotyczące objaśnień dotyczących usług

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

W powyższym logu czas oczekiwania procesora wiadomości po 55 002 ms został przekroczony, ponieważ serwer backendu nie odpowiada.

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

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

  2. Jeśli w określonym momencie zauważysz błędy Gateway Timeout i onTimeoutRead dla konkretnego żądania serwera proxy interfejsu API, oznacza to, że przetwarzanie wiadomości przekroczyło limit czasu.

    Przykładowy dziennik procesora wiadomości zawierający błąd 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 logu procesora wiadomości można zauważyć, że serwer backendu oznaczony adresem IP XX.XX.XX.XX nie odpowiedział nawet po 55 sekundach (lastIO=55000ms). W rezultacie procesor wiadomości przekroczył limit czasu i wysłał błąd 504 Gateway Timeout.

    Sprawdź to: w jaki sposób kontrolowane jest czas oczekiwania w procesorze wiadomości?

    • W jaki sposób kontrolowane jest czas oczekiwania w procesorze wiadomości. Procesory wiadomości zwykle ustawiają domyślny limit czasu wynoszący 55 sekund) za pomocą właściwości HTTPTransport.io.timeout.millis. Ta wartość czasu oczekiwania dotyczy wszystkich serwerów proxy interfejsu API należących do organizacji obsługiwanej przez ten procesor wiadomości.
      • Jeśli serwer backendu nie odpowiada w ciągu 55 sekund, przetwarzanie wiadomości przekroczy limit czasu i wysyła do klienta błąd 504 Gateway Timeout.
    • Wartość limitu czasu określoną w procesorze wiadomości można zastąpić właściwością io.timeout.millis podaną w serwerze proxy interfejsu API. Ta wartość limitu czasu dotyczy konkretnego serwera proxy interfejsu API, w którym określona jest powyższa właściwość. Jeśli na przykład io.timeout.millis w serwerze proxy interfejsu API jest ustawiona na 10 sekund, dla tego konkretnego serwera proxy interfejsu API zostanie użyta wartość 10 sekund.
      • Jeśli serwer backendu nie odpowie w ciągu 10 sekund na użycie określonego serwera proxy interfejsu API, procesor wiadomości przekroczy limit czasu i wyśle do klienta błąd 504 Gateway Timeout.

Rozdzielczość

  1. Sprawdź, dlaczego serwer backendu trwa dłużej niż 55 sekund, i sprawdź, czy można go naprawić/zoptymalizować, by szybciej reagować.
  2. Jeśli nie można naprawić/zoptymalizować serwera backendu lub wiadomo, że czas oczekiwania serwera backendu jest dłuższy niż skonfigurowany czas oczekiwania, zwiększ wartość limitu czasu w routerze i procesorze wiadomości do odpowiedniej wartości.

Scenariusz nr 2 – limit czasu routera został przekroczony, zanim procesor wiadomości/serwer backendu odpowie

Jeśli router przekroczy limit czasu oczekiwania przed odpowiedzią procesora wiadomości/serwera backendu, może wystąpić błąd 504 Gateway Timeout. Może się tak zdarzyć w jednej z tych sytuacji:

  • Wartość czasu oczekiwania ustawiona w routerze jest krótsza niż wartość czasu oczekiwania ustawiona w procesorze wiadomości. Załóżmy na przykład, że limit czasu na routerze to 50 sekund, a procesor wiadomości – 55 sekund.
    Przekroczony limit czasu na routerze Upłynął limit czasu przetwarzania wiadomości
    50 sekund 55 sekund
  • Wartość limitu czasu procesora wiadomości 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 serwera proxy interfejsu API:

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

    Przekroczony limit czasu na routerze Upłynął limit czasu przetwarzania wiadomości Przekroczenie limitu czasu w ramach serwera proxy interfejsu API
    57 sekund 55 sekund 120 sekund

    Jednak wartość io.timeout.millis w interfejsie API serwera proxy jest ustawiona na 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 oczekiwania po 55 sekundach, nawet jeśli jego wartość czasu oczekiwania (55 sekund) jest krótsza niż limit czasu routera (57 sekund). Wynika to z tego, że 55-sekundowy limit czasu działania procesora wiadomości jest zastępowany wartością 120 sekund ustawioną w serwerze proxy interfejsu API. W związku z tym wartość limitu czasu procesora wiadomości dla tego konkretnego serwera proxy interfejsu API wynosi 120 sekund.

    Ponieważ router ma krótszy czas oczekiwania (57 sekund) w porównaniu do 120 sekund ustawionych w serwerze proxy interfejsu API, router przekroczy limit czasu, jeśli serwer backendu nie odpowie w ciągu 57 sekund.

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 wiadomości, w logach dostępu NGINX zobaczysz stan 504 dla konkretnego żądania do interfejsu API, a message id z procesora wiadomości będzie ustawiony na -. Dzieje się tak, ponieważ router nie otrzymał żadnej odpowiedzi od procesora wiadomości w okresie oczekiwania ustawionym w routerze.

    Przykładowy wpis logu NGINX pokazujący błąd 504 z powodu przekroczenia limitu czasu routera

  3. W przykładzie powyżej zwróć uwagę na stan 504 w NGINX, identyfikator wiadomości z procesora wiadomości to -, a łączny czas, który upłynął, to 57,001 sekundy. Wynika to z tego, że router przekroczył limit czasu po 57,001 sekundy, a procesor wiadomości nie otrzymał żadnej odpowiedzi.
  4. W takim przypadku w logach procesora wiadomości zobaczysz Broken Pipe wyjątków (/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 procesorem wiadomości. Gdy procesor wiadomości zakończy przetwarzanie, spróbuje zapisać odpowiedź do routera. Połączenie z routerem jest już zamknięte, dlatego otrzymasz Broken Pipe exception na procesorze wiadomości.

Ten wyjątek zwykle ma miejsce w określonych wyżej okolicznościach. Zatem faktyczną przyczyną błędu 504 Gateway Timeout jest dłuższy czas odpowiedzi serwera backendu i konieczność rozwiązania tego problemu.

Rozdzielczość

  1. Jeśli jest to niestandardowy serwer backendu:
    1. Sprawdź, dlaczego serwer backendu zbyt długo odpowiada, i zobacz, czy da się go naprawić/zoptymalizować, aby odpowiadał szybciej.
    2. Jeśli nie można naprawić/zoptymalizować serwera backendu lub wiadomo, że działanie serwera backendu zajmuje dużo czasu, zwiększ wartość limitu czasu w routerze i procesorze wiadomości.

      Propozycja: ustaw wartość limitu czasu dla różnych komponentów w tej kolejności:

      Limit czasu klienta > Przekroczony limit czasu routera > Przekroczony limit czasu przetwarzania wiadomości > Przekroczony limit czasu w ramach serwera proxy interfejsu API
  2. Jeśli jest to serwer backendu NodeJS, wtedy:
    1. Sprawdź, czy kod NodeJS wywołuje inne serwery backendu i czy zwracanie odpowiedzi zajmuje dużo czasu. Sprawdź, dlaczego serwery backendu potrzebują więcej czasu, i rozwiąż problem, jeśli to konieczne.
    2. Sprawdź, czy procesory wiadomości obsługują duże wykorzystanie procesora lub pamięci:
      1. Jeśli którykolwiek z procesorów wiadomości uzyskuje duże obciążenie procesora, co 30 sekund wygeneruj 3 zrzuty wątków za pomocą tego polecenia: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Jeśli którykolwiek podmiot przetwarzający wiadomości wykazuje duże wykorzystanie pamięci, wygeneruj 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 przy użyciu tego polecenia. Powinno to zmniejszyć liczbę procesorów i ilość 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 udostępnij zrzuty wątków, zrzut stosu oraz logi procesora wiadomości (/opt/apigee/var/log/edge-message-processor/logs/system.log), aby pomóc zbadać przyczynę wysokiego wykorzystania procesora lub pamięci).

Sprawdź to: w jaki sposób kontrolowane jest czas oczekiwania na serwery backendu NodeJS w procesorze wiadomości

  • Serwer backendu NodeJS działa w ramach procesu JVM procesora wiadomości. Wartość czasu oczekiwania serwerów backendu NodeJS jest określana za pomocą właściwości http.request.timeout.seconds w pliku nodejs.properties. Ta właściwość ma domyślnie wartość 0, co oznacza, że limit czasu jest domyślnie wyłączony dla wszystkich serwerów proxy interfejsu API należących do organizacji udostępnianej przez ten podmiot przetwarzający wiadomości. Dlatego nawet jeśli działanie serwera backendu NodeJS zajmuje dużo czasu, procesor wiadomości nie przekroczy limitu czasu oczekiwania.
  • Jeśli jednak serwer backendu NodeJS zajmuje dużo czasu, a czas potrzebny na realizację żądania do interfejsu API wynosi więcej niż 57 sekund, router przekroczy limit czasu i wyśle do klienta błąd 504 Gateway Timeout.

Scenariusz 3. Czas oczekiwania aplikacji klienckiej został przekroczony, zanim router, procesor wiadomości lub serwer backendu odpowiedzi

Jeśli upłynął limit czasu aplikacji klienckiej, zanim serwer backendu odpowie, może wystąpić błąd 504 Gateway Timeout. Może się tak zdarzyć, jeśli:

  1. Wartość limitu czasu ustawiona w aplikacji klienckiej jest mniejsza niż wartość limitu czasu ustawiona na routerze i procesorze wiadomości:

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

    Upłynął limit czasu po stronie klienta Przekroczony limit czasu na routerze Upłynął limit czasu przetwarzania wiadomości
    50 sekund 57 sekund 55 sekund

    W tym przypadku łączny czas, w którym można uzyskać odpowiedź na żądanie do interfejsu API przez Edge, wynosi <= 50 sekund. Obejmuje to czas potrzebny na wysłanie żądania do API, przetwarzanie żądania przez Edge (router, procesor wiadomości), wysłanie żądania do serwera backendu (w stosownych przypadkach), przetwarzanie żądania przez backend i wysłanie odpowiedzi, przetwarzanie przez brzegowy odpowiedzi, a następnie na wysłanie jej z powrotem do klienta.

    Jeśli router nie odpowie na klienta 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 wskazującego, że klient zamknął połączenie.

Diagnostyka

  1. Jeśli aplikacja kliencka przekroczy limit czasu, zanim otrzyma odpowiedź od routera, zamknie połączenie z routerem. W takiej sytuacji w logach dostępu NGINX związanych z konkretnym żądaniem do interfejsu API pojawi się kod stanu 499.

    Przykładowy wpis logu NGINX z kodem stanu 499

  2. W tym przykładzie stan 499 w NGINX i łączny czas, który upłynął, to 50,001 sekundy. Oznacza to, że upłynął limit czasu klienta po 50,001 sekundy.
  3. W tym przypadku zobaczysz wyjątki Broken Pipe w logach procesora wiadomości (/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>
    ).
  4. Po przekroczeniu limitu czasu router zamyka połączenie z procesorem wiadomości. Gdy procesor wiadomości zakończy przetwarzanie, spróbuje zapisać odpowiedź do routera. Połączenie z routerem jest już zamknięte, więc zobaczysz Broken Pipe exception na procesorze wiadomości.
  5. Taki wyjątek jest normalny w podanych wyżej okolicznościach. Rzeczywistą przyczyną błędu 504 Gateway Timeout nadal jest długi czas odpowiedzi serwera backendu i problem, który należy rozwiązać.

Rozdzielczość

  1. Jeśli Twój niestandardowy serwer backendu:
    1. Sprawdź serwer backendu, aby ustalić, dlaczego trwa to dłużej niż 57 sekund, i sprawdź, czy można go poprawić/zoptymalizować, by szybciej reagować.
    2. Jeśli nie możesz naprawić/zoptymalizować serwera backendu lub jeśli wiesz, że działanie serwera backendu będzie bardzo pracochłonne, zwiększ wartość czasu oczekiwania na routerze i procesorze wiadomości.

      Propozycja: ustaw wartość limitu czasu dla różnych komponentów w tej kolejności:

      Limit czasu klienta > Przekroczony limit czasu routera > Przekroczony limit czasu przetwarzania wiadomości > Przekroczony limit czasu w ramach serwera proxy interfejsu API
  2. Jeśli jest to backend NodeJS, to:
    1. Sprawdź, czy kod NodeJS wywołuje inne serwery backendu i czy zwracanie tego zajmuje dużo czasu. Sprawdź, dlaczego działanie tych serwerów backendu trwa dłużej.
    2. Sprawdź, czy procesory wiadomości nie intensywnie korzystają z procesora lub pamięci:
      1. Jeśli procesor wiadomości intensywnie korzysta z 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 wiadomości ma duże wykorzystanie pamięci, wygeneruj 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 przy użyciu tego polecenia. Powinno to zmniejszyć liczbę procesorów i ilość 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 udostępnij zrzuty wątków, zrzut stosu oraz logi procesora wiadomości, /opt/apigee/var/log/edge-message-processor/logs/system.log)aby pomóc im zbadać przyczynę wysokiego wykorzystania procesora lub pamięci.

Zwiększ wartość czasu oczekiwania w routerze i procesorze wiadomości

Starannie wybierz wartości czasu oczekiwania, które mają zostać ustawione w routerze i procesorze wiadomości, w zależności od potrzeb. Nie ustawiaj dowolnie dużych wartości czasu oczekiwania. 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 routerze, 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ć limit czasu na 120 sekund, ustaw go w ten sposób:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Sprawdź, czy ten plik należy do 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 z nich.

procesor komunikatów

  1. Utwórz plik /opt/apigee/customer/application/message-processor.properties na komputerze procesora wiadomości, 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ć limit czasu na 120 sekund, ustaw go w ten sposób:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Sprawdź, czy ten plik należy do apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Ponownie uruchom procesor wiadomości: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Jeśli masz więcej niż 1 procesor wiadomości, powtórz powyższe kroki na wszystkich procesorach.

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

Limit czasu klienta > Przekroczony limit czasu routera > Przekroczony limit czasu przetwarzania wiadomości > Przekroczony limit czasu w ramach serwera proxy interfejsu API

Powolne przetwarzanie żądań do interfejsu API przez Edge

Jeśli Edge działa bardzo wolno lub długo przetwarza żądanie do interfejsu API, pojawi się błąd 504 Gateway Timeout.

Diagnostyka

  1. Znajdź interfejs API, którego dotyczy problem, w interfejsie użytkownika 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. W takim przypadku w logu czasu może pojawić się pomyślna odpowiedź.
    1. Upłynął limit czasu routera/klienta, ponieważ procesor wiadomości nie odpowiada po upływie określonego czasu oczekiwania na routerze/kliencie (w zależności od tego, który okres oczekiwania jest najkrótszy). Podmiot przetwarzający wiadomości nadal będzie przetwarzać żądanie i może je zakończyć pomyślnie.
    2. Dodatkowo wartość HTTPTransport.io.timeout.millis ustawiona w procesorze wiadomości jest wyzwalana tylko wtedy, gdy komunikuje się on z serwerem backendu HTTP/HTTPS. Inaczej mówiąc, ten limit czasu nie zostanie aktywowany, gdy którakolwiek zasada (inna niż zasada ServiceCallout) w serwerze proxy interfejsu API będzie długotrwała.
  4. Po wystąpieniu błędu sprawdź konkretne żądanie, które ma najdłuższy czas trwania.
  5. Sprawdź czas trwania poszczególnych faz i zanotuj, w których z nich spędzasz najwięcej czasu.
  6. Jeśli zauważysz najdłuższy czas, który upłynął w którejkolwiek z zasad innych niż zasada objaśnienia usługi, oznacza to, że przetwarzanie żądania przez Edge zajmuje dużo czasu.
  7. Oto przykładowy zrzut interfejsu użytkownika z widocznym bardzo długim czasem w zasadzie JavaScript:

  8. W powyższym przykładzie widać, że działanie zasady JavaScript trwa nietypowo długo – około 245 sekund.

Rozdzielczość

  1. Sprawdź, czy odpowiedź zasady trwała zbyt długo i czy istnieje kod niestandardowy, którego przetwarzanie może zająć dużo czasu. Jeśli występuje taki kod, sprawdź, czy możesz go naprawić lub zoptymalizować.
  2. Jeśli nie ma niestandardowego kodu, który mógłby wydłużyć czas przetwarzania, sprawdź, czy procesory wiadomości nie intensywnie korzystają z procesora lub pamięci:
    1. Jeśli którykolwiek z procesorów wiadomości uzyskuje duże obciążenie procesora, co 30 sekund wygeneruj 3 zrzuty wątków za pomocą tego polecenia: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Jeśli dowolny procesor wiadomości ma duże wykorzystanie pamięci, wygeneruj 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 przy użyciu tego polecenia. Powinno to zmniejszyć wydajność 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 udostępnij zrzuty wątków, zrzut stosu oraz logi procesora wiadomości, /opt/apigee/var/log/edge-message-processor/logs/system.log)aby pomóc im zbadać przyczynę wysokiego wykorzystania procesora lub 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 problemów dotyczących błędów, wydajności i opóźnień oraz ich źródeł, takich jak aplikacje dla programistów, serwery proxy interfejsów 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 504 kodów stanu przekroczy określony próg.