504 Przekroczenie limitu czasu bramy

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

Krótki opis problemu

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

Kod stanu HTTP – błąd 504 Gateway Timeout wskazuje, że klient nie otrzymał odpowiedzi od Edge Gateway ani serwera zaplecza 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 czasu oczekiwania bramy?

Typowa ścieżka żądania interfejsu API na platformie Edge to Klient -> Router -> Przetwarzanie wiadomości -> Serwer backendowy, jak pokazano na rysunku poniżej:

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

W tabeli poniżej znajdziesz więcej informacji o tym, kiedy może wystąpić limit czasu w Edge:

Wystąpienie limitu czasu Szczegóły
Czas oczekiwania na procesor komunikatów dobiegł końca
  • Serwer zaplecza nie odpowiada na komunikat procesora wiadomości w określonym czasie oczekiwania.
  • Przetwarzanie wiadomości kończy się przekroczeniem limitu czasu i serwer Router otrzymuje odpowiedź o stanie 504 Gateway Timeout.
Czas oczekiwania na routerze dobiegł końca
  • Przetwarzanie wiadomości nie odpowiada na router w określonym czasie oczekiwania.
  • Router osiąga limit czasu i wysyła stan odpowiedzi 504 Gateway Timeout do aplikacji klienckiej.
Przekroczono limit czasu dla aplikacji klienckiej
  • Router nie odpowiada na aplikację klienta w określonym czasie oczekiwania.
  • Czas oczekiwania na odpowiedź aplikacji klienta wygasa i usługa kończy stan odpowiedzi jako 504 Gateway Timeout dla użytkownika.

Możliwe przyczyny

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

Przyczyna Szczegóły Kroki podane dla
powolny serwer backendu, Serwer backendowy, który przetwarza żądanie interfejsu API, działa zbyt wolno z powodu dużego obciążenia lub niskiej wydajności. Użytkownicy chmury publicznej i prywatnej
Powolne przetwarzanie żądań interfejsu API przez Edge Z powodu dużego obciążenia lub niskiej wydajności przeglądarka Edge długo przetwarza żądanie interfejsu API.

Powolny serwer backendu

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

  1. Upłynął limit czasu przetwarzania wiadomości, zanim serwer backendu odpowie.
  2. Router osiąga limit czasu przed odpowiedzią serwera Message Processor lub serwera backendu.
  3. Czas oczekiwania na odpowiedź serwera pośredniczącego, procesora wiadomości lub serwera zaplecza wygasa przed upływem limitu czasu aplikacji klienta.

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

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

Diagnostyka

Aby sprawdzić, czy błąd 504 Gateway Timeout wystąpił z powodu wolnego serwera zaplecza, wykonaj podane niżej czynności.

Procedura 1. z użyciem logu czasu

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

  1. Śledź interfejs API, którego dotyczy problem, w interfejsie Edge. Poczekaj, aż wystąpi błąd, lub jeśli masz wywołanie interfejsu API, wykonaj kilka wywołań interfejsu API i powtórz błąd 504 Gateway Timeout.
  2. Po wystąpieniu błędu sprawdź konkretne żądanie, które ma kod odpowiedzi504.
  3. Sprawdź upływ czasu w każdej fazie i zapisz fazę, w której upłynęło najwięcej czasu.
  4. Jeśli błąd występuje najdłużej po zakończeniu jednej z poniższych faz, oznacza to, że serwer backendu działa wolno lub przetwarza żądanie przez długi czas:
    • Żądanie zostało wysłane do serwera docelowego
    • Zasady dotyczące ServiceCallout

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

W powyższym śladzie serwer Message Processor osiąga limit czasu po 55 002 ms, ponieważ serwer zaplecza nie odpowiada.

Procedura 2. Korzystanie z logów usługi Message Processor

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

  2. Jeśli w określonym momencie w przypadku konkretnego żądania zastępczego interfejsu API pojawią się błędy Gateway Timeout i onTimeoutRead, oznacza to, że upłynął limit czasu przetwarzania wiadomości.

    Przykładowy log usługi Message Processor pokazujący błąd 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 usługi Message Processor widać, że serwer zaplecza o adresie IP XX.XX.XX.XX nie odpowiadał nawet po 55 sekundach (lastIO=55000ms). W rezultacie usługa Message Processor przekroczyła limit czasu i wysłała błąd 504 Gateway Timeout.

    Sprawdź: Jak jest kontrolowany limit czasu w przetwarzaniu wiadomości?

    • Jak jest kontrolowany czas oczekiwania w przetwarzaniu wiadomości. Przetwarzanie wiadomości jest zwykle domyślnie ustawione na 55 sekund (w usłudze HTTPTransport.io.timeout.millis). Ta wartość limitu czasu jest stosowana w przypadku wszystkich serwerów proxy interfejsu API należących do organizacji obsługiwanej przez ten procesor wiadomości.
      • Jeśli serwer zaplecza nie odpowie w ciągu 55 sekund, serwer MessageProcessor przekroczy limit czasu i wyśle błąd 504 Gateway Timeout do klienta.
    • Limit czasu określony w procesorze wiadomości może zostać zastąpiony przez właściwość io.timeout.millis określoną na serwerze proxy API. Ta wartość limitu czasu dotyczy konkretnego interfejsu API Proxy, w którym określono tę właściwość. Jeśli na przykład parametr io.timeout.millis w proxy interfejsu API jest ustawiony na 10 sekund, dla tego konkretnego proxy interfejsu API będzie używana wartość limitu czasu 10 sekund.
      • Jeśli serwer zaplecza nie odpowie w ciągu 10 sekund w przypadku konkretnego interfejsu Proxy API, usługa Message Processor przekroczy limit czasu i wyśle klientowi błąd 504 Gateway Timeout.

Rozdzielczość

  1. Sprawdź, dlaczego serwer backendu potrzebuje więcej niż 55 sekund na odpowiedź, i sprawdź, czy można go naprawić lub zoptymalizować, aby działał szybciej.
  2. Jeśli nie można naprawić lub zoptymalizować serwera zaplecza albo wiadomo, że serwer zaplecza potrzebuje więcej czasu niż skonfigurowany limit czasu oczekiwania, zwiększ wartość limitu czasu oczekiwania na routerze i przetwarzaczu wiadomości do odpowiedniej wartości.

Scenariusz #2 – Router osiąga limit czasu przed odpowiedzią procesora wiadomości lub serwera backendu

Jeśli router przekroczy limit czasu, zanim odpowie serwer Message Processor/backend, mogą wystąpić błędy 504 Gateway Timeout. Może się tak zdarzyć w jednym z tych przypadków:

  • Limit czasu ustawiony w Routerze jest krótszy niż limit czasu ustawiony w Procesorze wiadomości. Załóżmy na przykład, że limit czasu na routerze wynosi 50 sekund, a na przetwarzanie wiadomości – 55 sekund.
    Czas oczekiwania na routerze Przekroczenie limitu czasu oczekiwania w procesorze komunikatów
    50 sekund 55 sekund
  • Wartość limitu czasu w procesorze wiadomości jest zastąpiona wyższą wartością limitu czasu za pomocą właściwości io.timeout.millis ustawionej w konfiguracji docelowego punktu końcowego w interfejsie API Proxy:

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

    Czas oczekiwania na routerze Przekroczenie limitu czasu oczekiwania w procesorze komunikatów Czas oczekiwania w 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, nawet jeśli ten limit (55 sekund) będzie mniejszy niż limit czasu na routerze (57 sekund). Dzieje się tak, ponieważ limit czasu wynoszący 55 sekund na procesorze wiadomości zostaje zastąpiony wartością 120 sekund ustawioną na serwerze proxy interfejsu API. Dlatego wartość limitu czasu przetwarzania wiadomości w przypadku tego konkretnego interfejsu API Proxy wyniesie 120 sekund.

    Router ma niższą wartość limitu czasu (57 sekund) niż 120 sekund ustawiony na serwerze proxy interfejsu API. Z tego powodu router przekroczy limit czasu, jeśli serwer backendu nie odpowie w ciągu 57 sekund.

Diagnostyka

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

  2. Jeśli przekroczono limit czasu oczekiwania routera przed procesorem wiadomości, w logach dostępu NGINX dla określonego żądania do interfejsu API zobaczysz stan 504, a message id z procesora wiadomości zostanie ustawiony jako -. Dzieje się tak, ponieważ router nie otrzymał żadnej odpowiedzi od procesora wiadomości w okresie ustawionym na routerze.

    Przykładowy wpis w logu NGINX, który pokazuje błąd 504 spowodowany przekroczeniem limitu czasu przez router

  3. W powyższym przykładzie stan NGINX to 504, identyfikator wiadomości z serwera Message Processor to -, a łączny upłynął czas to 57,001 sekundy. Wynika to z przekroczenia limitu czasu przez router po 57,001 sekundzie i braku odpowiedzi od procesora wiadomości.
  4. W takiej sytuacji w dziennikach Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log).) zobaczysz Broken Pipe wyjątków. 
    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 wiadomości. Gdy przetwarzanie zostanie zakończone, usługa przetwarzania wiadomości próbuje zapisać odpowiedź w routerze. Połączenie z routerem jest już zamknięte, dlatego na przetwarzaczu wiadomości zobaczysz komunikatBroken Pipe exception.

Ten wyjątek powinien być widoczny w wymienionych powyżej okolicznościach. Prawdziwa przyczyna błędu 504 Gateway Timeout to nadal zbyt długi czas odpowiedzi serwera backendu. Musisz rozwiązać ten problem.

Rozdzielczość

  1. Jeśli jest to niestandardowy serwer backendu,
    1. Sprawdź, dlaczego serwer backendu tak długo odpowiada i czy można go naprawić lub zoptymalizować, aby działał szybciej.
    2. Jeśli nie można naprawić ani zoptymalizować serwera zaplecza lub wiadomo, że serwer zaplecza działa wolno, zwiększ wartość limitu czasu w Routerze i przetwarzaczu wiadomości.

      Propozycja: ustaw wartość czasu oczekiwania w różnych komponentach w takim porządku:

      Limit czasu na kliencie > Limit czasu na routerze > Limit czasu na procesorze wiadomości > Limit czasu w serwerze proxy API
  2. Jeśli jest to serwer backendowy NodeJS:
    1. Sprawdź, czy kod NodeJS wykonuje wywołania do innych serwerów zaplecza i czy zajmuje mu to dużo czasu. Sprawdź, dlaczego serwery backendowe potrzebują więcej czasu, i odpowiednio rozwiąż problem.
    2. Sprawdź, czy procesory wiadomości mają wysokie wykorzystanie procesora lub pamięci:
      1. Jeśli dowolny procesor wiadomości notorycznie obciąża procesor, generuj 3 zrzuty wątków co 30 sekund za pomocą tego polecenia: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Jeśli jakikolwiek proces Message Processor zużywa dużo 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, korzystając z poniższego polecenia. Powinien on zmniejszyć wykorzystanie procesora i pamięci: 
        /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 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 w zbadaniu przyczyny wysokiego wykorzystania procesora/pamięci.

Sprawdź to: jak kontrolować limit czasu dla serwerów backendu NodeJS w Message Processor

  • Serwer backendu NodeJS działa w ramach procesu JVM procesora wiadomości. Wartość limitu czasu dla serwerów zaplecza NodeJS jest kontrolowana 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 obsługiwanej przez ten procesor wiadomości. Dlatego nawet jeśli serwer backendowy NodeJS potrzebuje dużo czasu, usługa Message Processor nie przekroczy limitu czasu.
  • Jeśli jednak serwer backendu NodeJS potrzebuje dużo czasu i czas potrzebny na wykonanie żądania interfejsu API przekracza 57 sekund, router przekroczy limit czasu i wyśle do klienta błąd 504 Gateway Timeout.

Scenariusz 3. Aplikacja klienta nie może uzyskać odpowiedzi od routera, procesora wiadomości lub serwera backendu

Jeśli upłyną limit czasu oczekiwania aplikacji klienckiej, zanim odpowie serwer backendu, możesz zobaczyć 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 przetwarzaczu wiadomości:

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

    Przekroczenie czasu oczekiwania na kliencie Czas oczekiwania na routerze Przekroczenie limitu czasu oczekiwania w procesorze komunikatów
    50 sekund 57 sekund 55 sekund

    W tym przypadku łączny czas potrzebny na otrzymanie odpowiedzi na żądanie interfejsu API przez Edge wynosi mniej niż 50 sekund. Obejmuje to czas potrzebny na wysłanie żądania do interfejsu API, przetworzenie żądania przez Edge (Router, Message Processor), wysłanie żądania do serwera backendu (w stosownych przypadkach), przetworzenie żądania przez backend i wysłanie odpowiedzi, przetworzenie odpowiedzi przez Edge i ostatecznie jej wysłanie 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 klienta przekroczy limit czasu, zanim otrzyma odpowiedź od routera, zamknie połączenie z routerem. W takim przypadku w logach dostępu NGINX dla konkretnego żądania interfejsu API zobaczysz kod stanu 499.

    Przykładowy wpis w dzienniku NGINX z kodem stanu 499

  2. W powyższym przykładzie stan 499 w NGINX i łączny upłynął czas to 50, 001 sekundy. Oznacza to, że klient przekroczył limit czasu po 50,001 sekundy.
  3. W takim przypadku w logach usługi Message Processor (/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-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ływie limitu czasu router zamyka połączenie z procesorem wiadomości. Gdy przetwarzanie przez przetwarzacz wiadomości zostanie zakończone, spróbuje on zapisać odpowiedź w przełączniku. Połączenie z routerem jest już zamknięte, dlatego pakiet Broken Pipe exception jest dostępny na procesorze wiadomości.
  5. Taki wyjątek jest normalny w opisanych powyżej okolicznościach. Mimo to rzeczywistą przyczyną błędu 504 Gateway Timeout nadal jest zbyt długi czas oczekiwania na odpowiedź serwera backendu i konieczność rozwiązania tego problemu.

Rozdzielczość

  1. Jeśli jest to Twój niestandardowy serwer backendu:
    1. Sprawdź serwer backendu, aby ustalić, dlaczego trwa to ponad 57 sekund, i sprawdź, czy można go naprawić lub zoptymalizować, aby szybciej odpowiadał.
    2. Jeśli nie można naprawić ani zoptymalizować serwera zaplecza lub jeśli wiesz, że serwer zaplecza będzie potrzebował dużo czasu, zwiększ wartość limitu czasu na routerze i w usłudze Message Processor.

      Propozycja: ustaw wartość czasu oczekiwania w różnych komponentach w następującej kolejności:

      Limit czasu na kliencie > Limit czasu na routerze > Limit czasu na procesorze wiadomości > Limit czasu w serwerze proxy API
  2. Jeśli jest to backend NodeJS:
    1. Sprawdź, czy kod NodeJS wykonuje wywołania do innych serwerów zaplecza i czy zajmuje to 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 usługa Message Processor wykorzystuje procesor w wysokim stopniu, wygeneruj 3 zrzuty wątku co 30 sekund za pomocą tego polecenia: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Jeśli procesor wiadomości wykorzystuje dużo pamięci, wygeneruj zrzut stosu za pomocą tego polecenia: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. Uruchom ponownie usługę Message Processor za pomocą tego polecenia. Powinien on 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. Aby pomóc zespołowi pomocy Apigee Edge w zbadaniu przyczyny wysokiego wykorzystania procesora lub pamięci, skontaktuj się z nim i prześlij mu dumpy wątków, dumpy stosu i logi usługi Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)).

Zwiększ wartość czasu oczekiwania na routerze i przetwarzaczu wiadomości

W zależności od wymagań wybierz wartości czasu oczekiwania, które mają być ustawione w routerze i procesorze wiadomości. Nie ustawiaj arbitralnie 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 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ć wartość limitu czasu na 120 sekund, wpisz:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. Upewnij się, że ten plik należy do apige:
  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 te czynności na każdym 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 np. chcesz ustawić wartość limitu czasu na 120 sekund, wpisz:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Upewnij się, że ten plik należy do apige: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Ponownie uruchom przetwarzanie wiadomości: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Jeśli masz więcej niż 1 przetwarzacz wiadomości, powtórz te czynności dla wszystkich przetwarzaczy wiadomości.

Propozycja: ustaw wartość czasu bezczynności w różnych komponentach w takim porządku:

Limit czasu na kliencie > Limit czasu na routerze > Limit czasu na procesorze wiadomości > Limit czasu w serwerze proxy API

Powolne przetwarzanie żądań do interfejsu API przez Edge

Jeśli Edge działa bardzo wolno lub przetwarza żądanie do interfejsu API bardzo długo, wystąpi 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, a potem wykonaj kilka wywołań interfejsu API i odtwórz błąd 504 Gateway Timeout.
  3. Uwaga: w takim przypadku w logu czasu może być wyświetlana poprawna odpowiedź.
    1. Router/klient osiąga limit czasu, ponieważ procesor wiadomości nie odpowiada w określonym czasie oczekiwania na routerze/kliencie (w zależności od tego, który ma najkrótszy czas oczekiwania). Przetwarzanie żądania przez usługę Message Processor jest jednak kontynuowane i może zakończyć się powodzeniem.
    2. Dodatkowo wartość HTTPTransport.io.timeout.millis ustawiona w procesorze wiadomości powoduje jego działanie tylko wtedy, gdy komunikuje się z serwerem zaplecza HTTP/HTTPS. Inaczej mówiąc, ten limit czasu nie zostanie uruchomiony, gdy jakakolwiek zasada (inna niż zasada ServiceCallout) w interfejsie API Proxy trwa długo.
  4. Po wystąpieniu błędu sprawdź konkretne żądanie, które najdłużej trwało.
  5. Sprawdź upływający czas w każdej fazie i zapisz fazę, w której upływa najwięcej czasu.
  6. Jeśli w którejkolwiek z zasad innych niż zasada dotycząca wywołań usługi zauważysz najdłuższy czas, oznacza to, że przetwarzanie żądania przez Edge trwa długo.
  7. Oto przykładowy log czasu interfejsu pokazujący bardzo długi czas, jaki upłynął od zasady JavaScript:

  8. W powyższym przykładzie zauważasz, że zasada JavaScriptu trwa nietypowo długi czas, wynoszący ok. 245 sekund.

Rozdzielczość

  1. Sprawdź, czy odpowiedź zasady trwa zbyt długo i czy nie ma żadnego niestandardowego kodu, którego przetwarzanie może wymagać dużo czasu. Jeśli taki kod jest, sprawdź, czy możesz go poprawić lub zoptymalizować.
  2. Jeśli nie ma niestandardowego kodu, który może powodować długi czas przetwarzania, sprawdź, czy procesory wiadomości nie obciążają procesora lub pamięcią zbyt dużą:
    1. Jeśli którykolwiek z procesów Message Processor ma wysokie wykorzystanie procesora, wygeneruj 3 zrzuty wątku co 30 sekund za pomocą tego polecenia: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Jeśli jakikolwiek proces Message Processor wykorzystuje dużo pamięci, wygeneruj zrzut stosu, używając tego polecenia: 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. Uruchom ponownie usługę Message Processor za pomocą tego polecenia. Powinien on 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. Aby pomóc zespołowi pomocy Apigee Edge w zbadaniu przyczyny wysokiego wykorzystania procesora lub pamięci, skontaktuj się z nim i prześlij mu zrzuty wątków, zrzuty stosu i logo procesu Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)).

Diagnozowanie problemów za pomocą Monitorowania interfejsu API

Monitorowanie interfejsu API umożliwia szybkie izolowanie obszarów problemowych, aby diagnozować błędy, wydajność i problemy z opóźnieniami oraz ich źródła, takie jak aplikacje deweloperów, serwery proxy interfejsu API, cele backendu czy platforma interfejsu 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.