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

504 – limit czasu bramy – przekroczenie limitu czasu routera

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

Krótki opis problemu

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

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

Komunikat o błędzie

Aplikacja kliencka otrzymuje ten kod odpowiedzi:

HTTP/1.1 504 Gateway Time-out

Podczas wywoływania takiego serwera proxy za pomocą cURL lub przeglądarki może pojawić się ten 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 przekroczenie limitu czasu?

Typowa ścieżka żądania interfejsu API wysyłanego przez platformę brzegową to Client > Router > Message Processor > Backend Server (Klient > Router > Procesor wiadomości > Serwer backendu) jak na tym ilustracji:

Wszystkie komponenty przepływu środowiska wykonawczego Apigee Edge, w tym klienty, routery, procesory wiadomości i serwery backendu, są skonfigurowane z odpowiednimi domyślnymi wartościami limitu czasu, aby żądania do interfejsu API nie trwały zbyt długo. Jeśli którykolwiek z komponentów w procesie nie otrzyma odpowiedzi od komponentu nadrzędnego w czasie określonym w konfiguracji limitu czasu, określony komponent przekroczy limit czasu i zwykle zwraca błąd 504 Gateway Timeout.

Ten scenariusz opisuje sposób rozwiązywania problemów z błędem 504 spowodowanym przekroczeniem limitu czasu routera.

Przekroczony limit czasu na routerze

Domyślny limit czasu skonfigurowany w routerach w Apigee Edge to 57 sekund. Jest to maksymalny czas, przez jaki serwer proxy interfejsu API może być wykonywany od momentu odebrania żądania do interfejsu API w Edge do momentu zwrócenia odpowiedzi. Obejmuje to odpowiedź backendu i wszystkie uruchomione zasady. Domyślny limit czasu można zastąpić w routerach i hostach wirtualnych zgodnie z opisem w sekcji Konfigurowanie limitu czasu wejścia/wyjścia w routerach.

Możliwe przyczyny

W Edge typowy błąd 504 Gateway Timeout spowodowany przekroczeniem limitu czasu routera to:

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

Najczęstsze kroki diagnostyki

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

Monitorowanie interfejsów API
Logi dostępu NGINX

Monitorowanie interfejsów API

Aby zdiagnozować błąd za pomocą monitorowania interfejsu API:

Otwórz stronę Analiza > Monitorowanie interfejsów API > Zbadaj.
Przefiltruj widok pod kątem 5xx błędów i wybierz przedział czasu.
Porównaj kod stanu z Czasem.
Kliknij komórkę z 504 błędami, aby wyświetlić więcej szczegółów i wyświetlić logi dotyczące tych błędów, jak pokazano poniżej:

Przykład wyświetlania błędów 504
W panelu po prawej stronie kliknij Wyświetl logi.

W oknie Logi ruchu zwróć uwagę na te informacje dotyczące niektórych błędów 504:
- Żądanie: określa metodę żądania i identyfikator URI używane do wykonywania wywołań.
- Czas odpowiedzi: łączny czas, jaki upłynął od realizacji żądania.
W powyższym przykładzie
- Żądanie wskazuje GET /test-timeout.
- Czas odpowiedzi to 57.001 s. Wskazuje to, że router przekroczył limit czasu, zanim procesor wiadomości mógł odpowiedzieć, ponieważ wartość jest bardzo zbliżona do domyślnego limitu czasu wejścia/wyjścia ustawionego w routerze, który wynosi 57 sekund.
Wszystkie logi możesz też pobrać za pomocą interfejsu API Monitoring GET. Jeśli na przykład wyślesz zapytanie do logów org, env, timeRange i status, możesz pobrać wszystkie logi transakcji, w przypadku których upłynął limit czasu klienta.

W przypadku tych błędów 504 Monitorowanie interfejsów API ustawia serwer proxy na - (nie ustawiono), więc możesz użyć interfejsu API (Logs API), aby uzyskać 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: w tych polach będzie wyświetlana wartość tego błędu 504:
- Źródło błędu
- Kod błędu
- Przepływ błędów
- Zasady dotyczące błędów
- Serwer proxy błędu
Te pola są wypełniane przez procesor wiadomości i zostaną ustawione na odpowiednie wartości tylko wtedy, gdy router otrzyma od niego odpowiedź. W tym przypadku router przekroczył limit czasu przed procesorem wiadomości, ponieważ nie odpowiedział w odpowiednim czasie. Wymusza to ustawienie przez router kodu stanu na 504, w wyniku czego wszystkie powyższe pola są wyświetlane jako -.
Sprawdź Czas reakcji pod kątem dodatkowych 504 błędów i czy Czas reakcji jest spójny (wartość limitu czasu wejścia-wyjścia ustawiona w routerze, który wynosi 57 sekund) we wszystkich błędach 504.

Logi dostępu NGINX

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

Sprawdź logi dostępu do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Sprawdź, czy w danym okresie wystąpiły jakieś błędy 504 (jeśli problem wystąpił w przeszłości) lub czy są jakieś żądania, które nadal kończą się niepowodzeniem z 504.
Zwróć uwagę na te informacje w przypadku niektórych błędów 504:
- Czas reakcji
- Identyfikator URI żądania
W tym przykładzie widzimy następujące informacje:
- Czas żądania: 57.001 s. Oznacza to, że upłynął limit czasu routera po 57.001 sekundy.
  
  Uwaga: to jest pole request_time w logach NGINX. Oznacza czas przetwarzania żądania w sekundach, czyli czas, który upłynął między odczytaniem pierwszych bajtów przez klienta a zapisem w logu od momentu wysłania do klienta ostatnich bajtów.
- Prośba: GET /test-timeout
- Alias hosta: myorg-test.apigee.net
Uwaga: w tych polach będzie wyświetlana wartość - dla tego błędu 504:
- Źródło błędu
- Kod błędu
- Przepływ błędów
- Zasady dotyczące błędów
- Serwer proxy błędu
Te pola są wypełniane przez procesor wiadomości i zostaną ustawione na odpowiednie wartości tylko wtedy, gdy router otrzyma od niego odpowiedź. W tym przypadku router przekroczył limit czasu przed procesorem wiadomości, ponieważ nie odpowiedział w odpowiednim czasie. Wymusza to ustawienie przez router kodu stanu na 504 i w efekcie wszystkie powyższe pola wyświetlają się jako -.
Sprawdź, czy czas żądania jest taki sam jak limit czasu wejścia-wyjścia skonfigurowany na routerze lub hoście wirtualnym. Jeśli tak, oznacza to, że router przekroczył limit czasu, zanim procesor wiadomości nie odpowiedział w tym okresie.

W przykładowym wpisie logu dostępu NGINX pokazanym powyżej Czas żądania wynoszący 57.001 s jest bardzo zbliżony do domyślnego limitu czasu wejścia/wyjścia ustawionego w routerze. Wskazuje to wyraźnie, że router przekroczył limit czasu, zanim procesor wiadomości mógł odpowiedzieć.
Określ serwer proxy interfejsu API, dla którego wysłano żądanie, korzystając ze ścieżki bazowej w polu Request (Żądanie).

Przyczyna: nieprawidłowa konfiguracja czasu oczekiwania routera

Diagnostyka

Sprawdź, czy błędy 504 są spowodowane tym, że router przekroczył limit czasu, zanim procesor wiadomości będzie mógł odpowiedzieć. Aby to zrobić, sprawdź, czy Czas odpowiedzi w interfejsie API Monitoring/Czas żądania w routerze (oba pola reprezentują te same informacje, ale są wywoływane przez różne nazwy) jest taki sam jak limit czasu wejścia-wyjścia skonfigurowany na routerze lub hoście wirtualnym, a pola Źródło błędu, Serwer proxy błędu i Typowe kroki są ustawione na - zgodnie z opisem w logach Monitorowania interfejsu API lub NGINX.
Sprawdź, czy wartość limitu czasu wejścia-wyjścia skonfigurowana w routerze lub na konkretnym hoście wirtualnym jest niższa niż wartość skonfigurowana w procesorze wiadomości lub konkretnym serwerze proxy interfejsu API.

Aby to zrobić, wykonaj czynności opisane w tej sekcji.

Sprawdzanie limitu czasu operacji wejścia-wyjścia na hostach wirtualnych

Interfejs Edge

Aby sprawdzić limit czasu hosta wirtualnego za pomocą interfejsu Edge, wykonaj te czynności:

Zaloguj się do interfejsu Edge.
Kliknij Admin > Virtual Hosts (Administracja > Hosty wirtualne).
Wybierz konkretne środowisko, w którym występuje problem z przekroczeniem limitu czasu.
Wybierz 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 powyższym przykładzie Limit czasu odczytu serwera proxy jest skonfigurowany z wartością 120. Oznacza to, że skonfigurowany na tym hoście wirtualnym limit czasu wejścia-wyjścia wynosi 120 sekund.

Uwaga: jeśli Limit czasu odczytu serwera proxy nie ma żadnej wartości, oznacza to, że przyjmie wartość domyślną wynoszącą 57 sekund skonfigurowaną w routerze (chyba że limit czasu wejścia/wyjścia jest zastąpiony 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:

Uruchom interfejs API Get virtual host, aby pobrać konfigurację virtualhost, jak pokazano poniżej:

Użytkownik chmury publicznej

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 pole proxy_read_timeout jest skonfigurowane 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 właściwość proxy_read_timeout nie istnieje w danych wyjściowych interfejsu Management API, oznacza to, że przyjmie wartość domyślną wynoszącą 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ę do routera.
Wyszukaj właściwość proxy_read_timeout w katalogu /opt/nginx/conf.d i sprawdź, czy została ustawiona nowa wartość w ten sposób:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Sprawdź wartość ustawioną dla właściwości proxy_read_timeout w pliku konfiguracji hosta wirtualnego.

Przykładowy wynik 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;
```
W powyższym przykładzie danych wyjściowych można zauważyć, że właściwość proxy_read_timeout została ustawiona na nową wartość 57 w obiekcie 0-default.conf, który jest plikiem konfiguracji domyślnego hosta wirtualnego. Wskazuje to, że limit czasu wejścia-wyjścia jest skonfigurowany na routerze na domyślnego hosta wirtualnego na 57 sekund. Jeśli masz wiele hostów wirtualnych, te informacje będą wyświetlane dla każdego z nich. Pobierz wartość proxy_read_timeout dla konkretnego hosta wirtualnego użytego do wywołania interfejsu API, które zakończyły się błędem 504.

Sprawdzanie limitu czasu operacji wejścia-wyjścia na serwerze proxy interfejsu API

Limit czasu wejścia-wyjścia możesz sprawdzić w tych sekcjach:

Docelowy punkt końcowy serwera proxy interfejsu API
Zasady dotyczące objaśnienia usługi w przypadku serwera proxy interfejsu API

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

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

Wyświetl limit czasu wejścia-wyjścia w zasadzie ServiceCallout z serwerem proxy interfejsu API

W interfejsie użytkownika Edge wybierz konkretny serwer proxy interfejsu API, w którym chcesz wyświetlić nową wartość limitu czasu wejścia/wyjścia dla zasady ServiceCallout.
Wybierz konkretną zasadę objaśnienia usługi, którą chcesz sprawdzić.
Sprawdź element <Timeout> z odpowiednią wartością w konfiguracji <ServiceCallout>.

Na przykład limit czasu wejścia-wyjścia tego kodu wynosi 120 sekund:
```
<Timeout>120000</Timeout>
```

Sprawdzanie limitu czasu operacji wejścia-wyjścia w procesorach wiadomości

Zaloguj się do procesora wiadomości.

Wyszukaj usługę HTTPTransport.io.timeout.millis w katalogu /opt/apigee/edge-message-processor/conf za pomocą tego polecenia:

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

Przykładowe wyniki

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

W przykładowych danych wyjściowych powyżej można zauważyć, że właściwość HTTPTransport.io.timeout.millis została ustawiona z wartością 55000 w kolumnie http.properties. Oznacza to, że limit czasu wejścia-wyjścia został skonfigurowany na 55 sekund w procesorze wiadomości.

Po określeniu limitu czasu skonfigurowanego w routerze i procesorze wiadomości sprawdź, czy dla routera lub hosta wirtualnego nie ma niższej wartości czasu oczekiwania w porównaniu do czasu oczekiwania na serwerze proxy interfejsu API lub routera wiadomości.

Zanotuj wartości ustawione na wszystkich warstwach zgodnie z poniższą tabelą:

Limit czasu routera (sekundy)	Limit czasu na hoście wirtualnym (sekundy)	Przekroczenie limitu czasu w procesorze wiadomości (sekundy)	Przekroczenie limitu czasu na serwerze proxy interfejsu API (sekundy)
57	-	55	120

Oto przykład:

W routerze skonfigurowana jest domyślna wartość 57 sekund.
Czas oczekiwania nie jest ustawiony na konkretnym hoście wirtualnym. Oznacza to, że będzie używać wartości domyślnej 57 sekund skonfigurowanej w routerze.
W procesorze wiadomości ustawiana jest wartość domyślna 55 sekund.
W przypadku serwera proxy interfejsu API skonfigurowana jest jednak wartość 120 sekund.

Wyższa wartość limitu czasu jest konfigurowana tylko na serwerze proxy interfejsu API, ale router nadal ma skonfigurowane 57 sekund. Z tego powodu router przekroczy limit czasu wynoszący 57 sekund, gdy procesor wiadomości/backend nadal przetwarza żądanie. Spowoduje to odpowiedź routera z błędem 504 Gateway Timeout do aplikacji klienckiej.

Rozdzielczość

Wykonaj opisane poniżej czynności, aby skonfigurować odpowiedni czas oczekiwania na wejście/wyjście w routerze i procesorze wiadomości, co pozwoli rozwiązać ten problem.

Zapoznaj się ze sprawdzonymi metodami konfigurowania limitu czasu wejścia/wyjścia, aby dowiedzieć się, jakie wartości czasu oczekiwania należy ustawiać w różnych komponentach uczestniczących w przepływie żądań do interfejsu API przez Apigee Edge.
W powyższym przykładzie, jeśli wiesz, że trzeba ustawić większą wartość limitu czasu, ponieważ serwer backendu wymaga dłuższego czasu, a wartość limitu czasu procesora wiadomości została zwiększona do 120 sekund, ustaw wyższą wartość limitu czasu, na przykład 123 seconds w routerze. Aby uniknąć wpływu nowej wartości limitu czasu na wszystkie serwery proxy interfejsu API, ustaw wartość 123 seconds tylko na konkretnym hoście wirtualnym, który jest używany w danym serwerze proxy interfejsu API.
Wykonaj instrukcje opisane w artykule Konfigurowanie limitu czasu wejścia-wyjścia w routerach, aby ustawić limit czasu na hoście wirtualnym.