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

504 – limit czasu bramy – przekroczenie limitu czasu routera

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 w odpowiedzi na wywołania interfejsu API.

Ta odpowiedź błędu oznacza, że klient nie otrzymał na czas odpowiedzi z Apigee Edge lub serwer backendu podczas wykonywania wywołania interfejsu API.

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 504 Gateway Time-out

Gdy wywołujesz taki serwer proxy, używając cURL lub przeglądarki, może pojawić się następujący błąd:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Co powoduje przekroczenia czasu oczekiwania?

Typowa ścieżka żądania API przesyłanego przez platformę Edge to Klient > Router > Wiadomość Procesor > Serwer backendu zgodnie z tą ilustracją:

Wszystkie komponenty w procesie środowiska wykonawczego Apigee Edge, w tym klienty, routery i wiadomości Procesory i serwery backendu są skonfigurowane z uwzględnieniem odpowiednich domyślnych wartości czasu oczekiwania, aby aby upewnić się, że realizacja żądań do interfejsu API nie trwa zbyt długo. Jeśli którykolwiek z komponentów przepływ nie otrzyma odpowiedzi z komponentu nadrzędnego w okresie podanym w kolumnie , to określony komponent przekroczy limit czasu i zwykle zwraca 504 Gateway Timeout.

Z tego poradnika dowiesz się, jak rozwiązać problemy z błędem 504 spowodowanym przez: routera.

Upłynął czas oczekiwania na routerze

Domyślny limit czasu skonfigurowany w routerach w Apigee Edge to 57 sekund. Jest to maksymalna czas, przez jaki serwer proxy API może być wykonywany od momentu otrzymania żądania API na urządzeniu Edge do odpowiedź jest odsyłana wraz z odpowiedzią backendu i wszystkimi wykonywanymi zasadami. Domyślny limit czasu można zastąpić w routerze/hostach wirtualnych, zgodnie z opisem w sekcji Konfiguruję czas oczekiwania na operacje wejścia-wyjścia w routerach.

Możliwe przyczyny

W Edge typowe przyczyny błędu 504 Gateway Timeout spowodowanego przez Czas oczekiwania routera wynosi:

Przyczyna	Opis	Instrukcje rozwiązywania problemów dotyczące
Nieprawidłowa konfiguracja limitu czasu w routerze	Dzieje się tak, jeśli router jest skonfigurowany z nieprawidłowym czasem oczekiwania na operacje wejścia-wyjścia.	Użytkownicy chmury publicznej i prywatnej Edge

Typowe kroki diagnostyki

Użyj jednego z tych narzędzi lub metod, aby zdiagnozować ten błąd:

Monitorowanie interfejsów API
Logi dostępu NGINX

Monitorowanie interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsów API:

Przejdź do przycisku Analiza > Monitorowanie interfejsów API > Zbadaj stronę.
Odfiltruj błędy (5xx) i wybierz przedział czasu.
Porównaj Kod stanu z czasem.
Kliknij komórkę z 504 błędami, aby zobaczyć więcej szczegółów i wyświetlić jak poniżej znajdziesz dzienniki o tych błędach:

Przykład błędu 504
W panelu po prawej stronie kliknij Wyświetl logi.

W oknie Logi ruchu zwróć uwagę na te szczegóły niektórych błędów typu 504:
- Żądanie: udostępnia metodę żądania i identyfikator URI używane do wykonywania wywołań.
- Czas odpowiedzi: podaje łączny czas realizacji żądania.
W przykładzie powyżej
- Żądanie wskazuje GET /test-timeout.
- Czas odpowiedzi to 57.001 s. Oznacza to, że router przekroczono limit czasu, zanim procesor wiadomości mógł odpowiedzieć, ponieważ wartość jest bardzo bliska na domyślny limit czasu wejścia-wyjścia ustawiony w routerze, który wynosi 57 sek.
Wszystkie logi można też pobrać za pomocą interfejsu API Monitoring interfejsu API pobierania logów. Na przykład, jeśli wyślesz zapytania dotyczące logów org, env, timeRange, i status, możesz pobrać wszystkie dzienniki transakcji, dla których przekroczył limit czasu.

Monitorowanie interfejsów API ustawia serwer proxy na - (nie ustawiono) dla tych 504 można użyć interfejsu API (Logs API), aby pobrać powiązany serwer proxy dla hosta wirtualnego i ścieżki.

Na przykład:
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
. Uwaga: wartość - dla tego błędu 504 pojawi się w tych polach:
- Źródło błędu
- Kod błędu
- Przepływ błędu
- Zasady dotyczące błędów
- Serwer proxy z błędem
Te pola są wypełniane przez procesor komunikatów i zostaną ustawione z odpowiednimi wartościami tylko wtedy, gdy router otrzyma odpowiedź z procesora wiadomości. W tym przypadku router Upłynął limit czasu przed procesorem wiadomości, ponieważ nie odpowiedział w odpowiednim czasie. Zmusza to router do ustawienia kodu stanu na 504. W rezultacie wszystkie wymienionych powyżej pól jest wyświetlane jako -.
Sprawdź Czas odpowiedzi pod kątem dodatkowych błędów (504) i sprawdź aby sprawdzić, czy czas odpowiedzi jest spójny (wartość limitu czasu wejścia-wyjścia ustawiona w routerze czyli 57 sekund) we wszystkich błędach typu 504.

Logi dostępu NGINX

Aby zdiagnozować błąd przy użyciu logów dostępu NGINX:

Sprawdź logi dostępu NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Wyszukaj błędy (504) w tym okresie (jeśli problem wystąpił w przeszłości) lub jeśli masz jakieś żądania, które nadal kończą się niepowodzeniem 504
W przypadku niektórych błędów 504 zapoznaj się z tymi informacjami:
- Czas odpowiedzi
- Identyfikator URI żądania
W tym przykładzie widzimy te informacje:
- Czas żądania: 57.001 s. Oznacza to, że Router przekroczył limit czasu po 57,001 sekundach.
  
  Uwaga: reprezentuje pole request_time w logach NGINX. Oznacza czas przetwarzania żądania w sekundach; czas, który upłynął między pierwszym Bajty zostały odczytane przez klienta i zapis logu po wysłaniu ostatnich bajtów do klienta.
- Prośba: GET /test-timeout
- Alias hosta: myorg-test.apigee.net
Uwaga: następujące pola będą wyświetlać wartość - dla tego 504 błąd:
- Źródło błędu
- Kod błędu
- Przepływ błędu
- Zasady dotyczące błędów
- Serwer proxy z błędem
Te pola są wypełniane przez procesor wiadomości i zostaną ustawione wyłącznie z odpowiednimi wartościami jeśli router otrzyma odpowiedź od procesora wiadomości. W tym przypadku router odliczył czas przed procesorem wiadomości, ponieważ nie odpowiedział w odpowiednim czasie. Wymusza to ustaw router na ustawienie kodu stanu na 504, w wyniku czego wszystkie powyższe są wyświetlane jako -.
Sprawdź, czy czas żądania jest taki sam jak limit czasu wejścia-wyjścia. skonfigurowany w routerze lub hoście wirtualnym. Jeśli tak, oznacza to, że router przekroczył limit czasu przed Procesor wiadomości nie odpowiedział w tym okresie.

W przykładowym wpisie logu dostępu NGINX pokazanym powyżej Żądanie Czas wynoszący 57.001 s jest bardzo bliski ustawionego domyślnego czasu oczekiwania na operacje wejścia-wyjścia w routerze. Wyraźnie wskazuje to, że router przekroczył limit czasu przed wysłaniem wiadomości Procesor może odpowiedzieć.
Określ serwer proxy interfejsu API, dla którego wysłano żądanie, używając ścieżki podstawowej w pliku Request (Żądanie).

Przyczyna: nieprawidłowa konfiguracja limitu czasu w routerze

Diagnostyka

Sprawdź, czy błąd 504 jest spowodowany przekroczeniem limitu czasu routera przed procesor wiadomości mógł odpowiedzieć. Aby to zrobić, sprawdź, czy Response Time (Czas odpowiedzi) w interfejsie API Monitoring (Monitorowanie API) / Request Time (Czas żądania) w routerze (oba pola) przedstawiają te same informacje,ale są nazywane innymi nazwami) jest taka sama jak Limit czasu wejścia-wyjścia skonfigurowany na routerze lub hoście wirtualnym oraz pola Źródło błędu i Błąd błędu Serwer proxy i kod błędu są ustawione na - przy użyciu monitorowania API lub dostępu NGINX dzienników, zgodnie z opisem w sekcji Typowe kroki diagnostyki.
Sprawdź, czy limit czasu wejścia-wyjścia skonfigurowany w routerze lub na konkretnym hoście wirtualnym jest niższa niż ta skonfigurowana w procesorze wiadomości lub na konkretnym serwerze proxy API.

W tym celu wykonaj czynności opisane w tej sekcji.

Weryfikowanie czasu oczekiwania na operacje wejścia-wyjścia w hostach wirtualnych

Interfejs Edge

Aby sprawdzić limit czasu oczekiwania hosta wirtualnego za pomocą interfejsu Edge:

Zaloguj się w interfejsie Edge.
Wybierz kolejno Administracja > Hosty wirtualne.
Wybierz środowisko, w którym występuje problem z limitem czasu.
Wybierz konkretnego hosta wirtualnego, dla którego chcesz sprawdzić wartość limitu czasu wejścia-wyjścia.
W sekcji Właściwości wyświetl wartość Limit czasu odczytu serwera proxy w sekundach.

W tym przykładzie Limit czasu odczytu serwera proxy jest skonfigurowany z wartością 120 Oznacza to, że limit czasu wejścia-wyjścia skonfigurowany na tym hoście wirtualnym wynosi 120 sekund.

Uwaga: jeśli parametr Limit czasu odczytu serwera proxy nie ma żadnej wartości, oznacza to, że zostanie wartość domyślna wynosząca 57 sekund skonfigurowana w routerze (chyba że limit czasu wejścia-wyjścia jest ustawiony na zastąpione w instancjach routera).

Interfejsy API do zarządzania

Możesz też sprawdzić Limit czasu odczytu serwera proxy przy użyciu tych interfejsów API do zarządzania:

Wykonaj Pobierz interfejs API hosta wirtualnego, aby uzyskać konfigurację virtualhost, jak pokazano poniżej:

Użytkownik Public Cloud

curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Użytkownik Private Cloud

curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Gdzie:

ORGANIZATION_NAME to nazwa organizacji

ENVIRONMENT_NAME to nazwa środowiska.

VIRTUALHOST_NAME to nazwa hosta wirtualnego

Sprawdź wartość skonfigurowaną dla właściwości proxy_read_timeout

Przykładowa definicja hosta wirtualnego

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

W tym przykładzie proxy_read_timeout jest skonfigurowana z wartością 120 Oznacza to, że limit czasu wejścia-wyjścia skonfigurowany na tym hoście wirtualnym wynosi 120 sek.

Uwaga: Jeśli usługi proxy_read_timeout nie ma w danych wyjściowych zarządzania API, przyjmuje wartość domyślną wartość wynosząca 57 sekund (chyba że limit czasu wejścia-wyjścia zostanie zastąpiony w instancjach routera).

Sprawdzam limit czasu wejścia/wyjścia w pliku router.properties

Zaloguj się na routerze.
Wyszukaj usługę proxy_read_timeout w /opt/nginx/conf.d i sprawdź, czy została w nim ustawiona nowa wartość. w następujący sposób:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Sprawdź wartość ustawioną dla właściwości proxy_read_timeout w konkretnym pliku konfiguracji hosta.

Przykładowy wynik z polecenia grep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
Zwróć uwagę, że w przykładowych danych wyjściowych powyżej właściwość proxy_read_timeout została ustawiona z nową wartością 57 w 0-default.conf, która jest dla domyślnego hosta wirtualnego. Oznacza to, że limit czasu wejścia-wyjścia jest skonfigurowany na 57 sekund w routerze dla domyślnego hosta wirtualnego. Jeśli jest więcej niż 1 hostem wirtualnym, zobaczysz te informacje dla każdego z nich. Poznaj wartość proxy_read_timeout dla konkretnego hosta wirtualnego użytego do utworzenia interfejsu API Niepowodzenia z 504 błędami.

Weryfikuję limit czasu wejścia-wyjścia na serwerze proxy API

Limit czasu I/O możesz sprawdzić w tych miejscach:

Docelowy punkt końcowy serwera proxy interfejsu API
Zasada ServiceCallout serwera proxy interfejsu API

Wyświetl limit czasu wejścia-wyjścia w docelowym punkcie końcowym serwera proxy interfejsu API

W interfejsie Edge wybierz konkretny serwer proxy interfejsu API, na którym chcesz wyświetlać wejścia/wyjścia. limit czasu.
Wybierz konkretny docelowy punkt końcowy, który chcesz sprawdzić.
Wyświetl właściwość io.timeout.millis z odpowiednią wartością w kolumnie Element <HTTPTargetConnection> w TargetEndpoint konfiguracji.
Na przykład limit czasu wejścia-wyjścia w poniższym kodzie jest ustawiony na 120 sekund:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

Wyświetl czas oczekiwania na operacje wejścia-wyjścia w zasadach objaśnienia usługi interfejsu API serwera proxy

W interfejsie Edge wybierz konkretny serwer proxy interfejsu API, na którym chcesz wyświetlić nowe I/O. limit czasu zasady ServiceCallout.
Wybierz zasadę dotyczącą objaśnienia usługi, którą chcesz sprawdzić.
Zobacz element <Timeout> z odpowiednią wartością w kolumnie Konfiguracja <ServiceCallout>.

Na przykład limit czasu wejścia-wyjścia poniższego kodu wyniesie 120 sekund:
```
<Timeout>120000</Timeout>
```

Weryfikowanie limitu czasu wejścia-wyjścia w procesorach wiadomości

Zaloguj się na komputerze z procesorem wiadomości.

Wyszukaj usługę HTTPTransport.io.timeout.millis w /opt/apigee/edge-message-processor/conf przy użyciu tego polecenia:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

Przykładowe dane wyjściowe

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

Zwróć uwagę na to, że w przykładowych danych wyjściowych powyżej Parametr HTTPTransport.io.timeout.millis został ustawiony na wartość 55000 w http.properties Oznacza to, że limit czasu wejścia-wyjścia został poprawnie skonfigurowany 55 sekund na procesorze wiadomości.

Po określeniu limitu czasu skonfigurowanego na routerze i procesorze wiadomości sprawdź, czy Router/host wirtualny został skonfigurowany z niższą wartością limitu czasu niż w Procesor komunikatów/serwer proxy interfejsu API.

Zanotuj wartości ustawione na wszystkich warstwach, tak jak w tabeli poniżej:

Limit czasu na routerze (sekundy)	Limit czasu na hoście wirtualnym (sekundy)	Czas oczekiwania na procesor wiadomości (sekundy)	Limit czasu na serwerze proxy API (sekundy)
57	-	55	120

W tym przykładzie

Wartość domyślna (57 sekund) jest skonfigurowana w routerze.
Limit czasu nie jest ustawiony dla konkretnego hosta wirtualnego. Oznacza to, że będzie korzystać z funkcji domyślna wartość 57 sekund skonfigurowana na routerze.
W procesorze wiadomości skonfigurowana jest wartość domyślna wynosząca 55 sekund.
Jednak na konkretnym serwerze proxy interfejsu API skonfigurowano wartość 120 sekund.

Zwróć uwagę, że większa wartość czasu oczekiwania jest skonfigurowana tylko na serwerze proxy API, a router nadal jest 57 sekund. Dlatego router przekracza limit czasu po upływie 57 sekund, Procesor/backend nadal przetwarza Twoje żądanie. Spowoduje to, że router będzie odpowiadać za pomocą polecenia 504 Gateway Timeout błąd w aplikacji klienckiej.

Rozdzielczość

Wykonaj poniższe czynności, aby skonfigurować odpowiedni limit czasu wejścia-wyjścia w routerze i wiadomości Podmiot przetwarzający, aby rozwiązać ten problem.

Więcej informacji: Sprawdzone metody konfigurowania limitu czasu wejścia-wyjścia, które pozwalają zrozumieć wartości limitu czasu należy ustawić na różnych komponentach zaangażowanych w przepływ żądania do interfejsu API przez Apigee Edge.
Jeśli w przykładzie powyżej stwierdzisz, że należy ustawić większą wartość limitu czasu ponieważ serwer backendu wymaga dłuższego czasu, a limit czasu został wydłużony na 120 sekund, a następnie ustaw większą wartość limitu czasu dla przykład: 123 seconds w routerze. Aby uniknąć wpływu na wszystkie serwery proxy interfejsów API ze względu na nową wartość limitu czasu ustaw wartość 123 seconds tylko w określonego hosta wirtualnego, który jest używany na konkretnym serwerze proxy interfejsu API.
Postępuj zgodnie z instrukcjami podanymi w artykule Skonfiguruj czas oczekiwania na operacje wejścia-wyjścia na routerach, aby ustawić czas oczekiwania na hoście wirtualnym.