이 페이지는 Cloud Translation API를 통해 번역되었습니다.

504 게이트웨이 시간 초과

<ph type="x-smartling-placeholder"></ph> 현재 Apigee Edge 문서를 보고 있습니다.
Apigee X 문서. 정보

증상

클라이언트 애플리케이션이 다음 메시지와 함께 HTTP 상태 코드 504를 수신합니다. API 호출에 대한 응답으로 Gateway Timeout

HTTP 상태 코드 - 504 Gateway Timeout 오류는 클라이언트가 실행 중 에지 게이트웨이 또는 백엔드 서버로부터 적시에 응답을 받지 못함 API

오류 메시지

클라이언트 애플리케이션은 다음과 같은 응답 코드를 받습니다.

HTTP/1.1 504 Gateway Timeout

경우에 따라 다음과 같은 오류 메시지가 표시될 수도 있습니다.

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

게이트웨이 시간 초과의 원인은 무엇인가요?

Edge 플랫폼을 통한 API 요청의 일반적인 경로는 클라이언트 -> 라우터 -> 메시지 프로세서 -> Backend Server를 사용해야 합니다.

에지 플랫폼 내의 클라이언트 애플리케이션, 라우터, 메시지 프로세서는 시간 초과 값을 지정해야 합니다. Edge 플랫폼은 특정 기간 내에 응답이 전송될 것으로 예상합니다. 제한 시간 값을 기준으로 모든 API 요청에 대한 시간을 제공합니다. 24시간 이내에 응답을 받지 못하면 지정된 기간이 지나면 504 Gateway Timeout Error가 반환됩니다.

다음 표에는 Edge에서 시간 초과가 발생할 수 있는 경우에 대한 자세한 내용이 나와 있습니다.

시간 초과 발생	세부정보
메시지 프로세서에서 시간 초과 발생	지정된 제한 시간 내에 백엔드 서버가 메시지 프로세서에 응답하지 않습니다. 시간을 단축할 수 있습니다. 메시지 프로세서는 시간이 초과되고 응답 상태를 `504 Gateway Timeout`로 라우터에 보냅니다.
라우터에서 시간 초과 발생	메시지 프로세서가 지정된 제한 시간 내에 라우터에 응답하지 않음 자동으로 전달됩니다. 라우터가 타임아웃되고 응답 상태를 `504 Gateway Timeout`로 클라이언트 애플리케이션에 보냅니다.
클라이언트 애플리케이션에서 시간 초과 발생	라우터가 지정된 제한 시간 내에 클라이언트 애플리케이션에 응답하지 않음 가장 짧은 시간입니다. 클라이언트 애플리케이션이 타임아웃되고 최종 사용자에게 응답 상태를 `504 Gateway Timeout`로 종료합니다.

가능한 원인

Edge에서 504 Gateway Timeout 오류의 일반적인 원인은 다음과 같습니다.

원인	세부정보	주어진 단계
느린 백엔드 서버	API 요청을 처리하는 백엔드 서버가 과부하로 인해 너무 느립니다. 얻을 수 있습니다	퍼블릭 및 프라이빗 클라우드 사용자
에지에서 느린 API 요청 처리	높은 부하 또는 불량으로 인해 Edge에서 API 요청을 처리하는 데 시간이 오래 걸립니다. 확인할 수 있습니다

느림 백엔드 서버

백엔드 서버가 매우 느리거나 API 요청을 처리하는 데 시간이 오래 걸리는 경우 504 Gateway Timeout 오류가 발생합니다. 위 섹션에서 설명한 것처럼 제한 시간은 다음 시나리오 중 하나에서 발생할 수 있습니다.

백엔드 서버가 응답하기 전에 메시지 프로세서가 타임아웃됩니다.
메시지 프로세서/백엔드 서버가 응답하기 전에 라우터가 타임아웃됩니다.
라우터/메시지 프로세서/백엔드 서버가 응답하기 전에 클라이언트 애플리케이션이 타임아웃됩니다.

다음 섹션에서는 이러한 각 항목의 문제를 진단하고 해결하는 방법을 설명합니다. 있습니다

시나리오 #1 백엔드 서버가 응답하기 전에 메시지 프로세서가 타임아웃됩니다.

진단

다음 절차를 사용하여 504 Gateway Timeout 오류가 발생했는지 진단할 수 있습니다. 백엔드 서버가 느립니다

절차 #1 Trace 사용

문제가 계속 발생하는 경우 (오류 504개가 계속 발생함) 아래 단계를 따릅니다. 단계:

Edge UI에서 영향을 받는 API를 추적합니다. 오류가 발생할 때까지 기다리거나 API를 호출한 다음 몇 가지 API를 호출하고 504 Gateway Timeout 오류를 재현합니다.
오류가 발생한 후에는 응답 코드를 504
각 단계의 경과 시간을 확인하고 시간이 가장 많이 걸린 단계를 기록합니다. 합니다.
오류가 발생한 후 오류가 발생하면 백엔드 서버가 현재 상태를 유지하는 데 다음과 같이 요청을 처리합니다. <ph type="x-smartling-placeholder">
- 대상 서버로 요청이 전송됨
- ServiceCallout 정책

다음은 백엔드 서버가 응답하지 않았다는 것을 보여주는 샘플 Trace입니다. 55초 후 504 Gateway Timeout 오류가 발생합니다.

위의 추적에서 메시지 프로세서는 백엔드 서버처럼 55, 002ms 후에 타임아웃됩니다. 있습니다.

절차 #2 메시지 프로세서 로그 사용

메시지 프로세서 로그 확인 (/opt/apigee/var/log/edge-message-processor/logs/system.log개)

특정 API 프록시 요청에 대해 Gateway Timeout 및 onTimeoutRead 오류가 발견된 경우 메시지 프로세서의 시간이 초과되었음을 나타냅니다.

게이트웨이 시간 초과 오류를 보여주는 샘플 메시지 프로세서 로그

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

위의 메시지 프로세서 로그에서 백엔드 서버가 주소 XX.XX.XX.XX가 55초 후에도 응답하지 않습니다 (lastIO=55000ms). 따라서 메시지 프로세서의 시간이 초과되어 504 Gateway Timeout 오류를 보냈습니다.

확인: 메시지 프로세서에서 시간 제한이 어떻게 제어되나요?

메시지 프로세서에서 제한 시간을 제어하는 방법 메시지 프로세서는 일반적으로 기본 제한 시간 값 55초로 설정) HTTPTransport.io.timeout.millis입니다. 이 제한시간 값은 이 서비스가 서비스를 제공하는 조직에 속한 모든 API 프록시에 적용됩니다. 메시지 프로세서.
- 백엔드 서버가 55초 이내에 응답하지 않으면 프로세서가 타임아웃되고 504 Gateway Timeout 오류를 클라이언트에 전송합니다.
메시지 프로세서에 지정된 제한 시간 값은 io.timeout.millis 속성으로 재정의됨 API 프록시 내에서 지정됩니다. 이 제한 시간 값은 특정 API에 적용됩니다. 위에서 언급한 속성이 지정된 프록시입니다. 예를 들어 io.timeout.millis가 API 프록시 내에서 10초로 설정된 경우 이 특정 API 프록시에는 시간 제한 값 10초가 사용됩니다.
- 백엔드 서버가 특정 요청에 대해 10초 이내에 응답하지 않으면 API 프록시를 실행하면 메시지 프로세서가 타임아웃되고 504 Gateway Timeout를 전송합니다. 클라이언트로 전송합니다.

해상도

백엔드 서버가 55초 넘게 걸리는 이유를 확인하고 더 빠르게 대응할 수 있습니다
백엔드 서버를 수정/최적화할 수 없거나 백엔드가 설정된 제한 시간보다 서버 시간이 오래 걸리는 경우 라우터 및 메시지 프로세서의 제한 시간 값을 적절한 값으로 늘립니다.

시나리오 #2 - 메시지 프로세서/백엔드 서버가 응답하기 전에 라우터 타임아웃

메시지 전에 라우터가 타임아웃되면 504 Gateway Timeout 오류가 발생할 수 있습니다. 프로세서/백엔드 서버가 응답합니다. 이는 다음 상황 중 하나에서 발생할 수 있습니다.

라우터에 설정된 시간 제한 값이 메시지에 설정된 시간 제한 값보다 짧습니다. 프로세서. 예를 들어 라우터의 시간제한이 50초인 반면 프로세서는 55초입니다.

라우터 시간 초과 메시지 프로세서 시간 초과

50초 55초

라우터 시간 초과	메시지 프로세서 시간 초과
50초	55초

메시지 프로세서의 제한시간 값은 대상 엔드포인트 구성 내에 설정된 io.timeout.millis 속성 다음과 같습니다.

예를 들어 제한 시간 값이 다음과 같이 설정된 경우입니다.

라우터 시간 초과	메시지 프로세서 시간 초과	API 프록시 내 시간 초과
57초	55초	120초

하지만 API 프록시에서 io.timeout.millis는 120초로 설정되어 있습니다.

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

그러면 메시지 프로세서는 시간이 초과되더라도 55초가 지나면 시간 초과가 발생하지 않습니다. 값 (55초)이 라우터의 시간 제한 값 (57초)보다 작을 수 있습니다. 이는 메시지 프로세서의 시간 제한 값 55초는 API 프록시 내에서 120초로 설정됩니다. 따라서 메시지 프로세서의 시간 제한 값은 120초로 설정합니다

라우터는 시간 제한 값 (57초)이 57초로 설정되어 있으므로 백엔드 서버가 57 초입니다.

진단

NGINX 액세스 로그 확인 (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log개)
메시지 프로세서 전에 라우터가 시간 초과되면 504의 상태가 표시됩니다. 특정 API 요청에 대한 NGINX 액세스 로그 및 message id 메시지 프로세서는 -로 설정됩니다. 라우터가 응답을 받지 못했기 때문입니다. 라우터에 설정된 제한 시간 내에 메시지 프로세서로부터.

라우터 타임아웃으로 인해 504가 표시되는 샘플 NGINX 로그 항목
위의 예에서 NGINX의 504 상태(메시지의 메시지 ID)를 확인합니다. 프로세서가 -이고 총 경과된 시간은 57.001초입니다. 라우터가 타임아웃되었기 때문입니다 메시지 프로세서의 응답을 받지 못했습니다.

이 경우 메시지에 예외 Broken Pipe개가 표시됩니다. 프로세서 로그 (/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>

이 오류가 표시되는 이유는 라우터가 제한 시간을 초과하면 해당 라우터와의 연결을 종료하기 때문입니다. 메시지 프로세서. 메시지 프로세서는 처리를 완료하면 라우터에 대한 응답입니다. 라우터에 대한 연결이 이미 종료되었기 때문에 메시지 프로세서의 Broken Pipe exception

이 예외는 위에 설명된 상황에서 표시될 수 있습니다. 따라서 실제 504 Gateway Timeout 오류의 원인은 여전히 백엔드 서버가 응답하는 데 시간이 더 오래 걸리기 때문입니다. 이 문제를 해결해야 합니다

해상도

커스텀 백엔드 서버인 경우 <ph type="x-smartling-placeholder">

백엔드 서버가 응답하는 데 시간이 오래 걸리는 이유를 확인하고, 더 빠르게 대응할 수 있습니다

백엔드 서버를 수정/최적화할 수 없거나 시간이 오래 걸린다면 점점 더 많은 시간을 할당하여 라우터와 메시지 프로세서와 동일합니다.

아이디어: 다음 각 구성요소에 대해 제한 시간 값을 설정합니다. 주문:

클라이언트 제한 시간 > 라우터 시간 초과 > 메시지 시간 초과 프로세서 > API 프록시 내 제한 시간

NodeJS 백엔드 서버인 경우: <ph type="x-smartling-placeholder">
1. NodeJS 코드가 다른 백엔드 서버를 호출하는지, 시간이 오래 걸릴 수 있다는 사실을 알고 있을 겁니다 백엔드 서버에 시간이 오래 걸리는 이유를 확인하고 적절하게 문제를 해결합니다.
2. 메시지 프로세서의 CPU 또는 메모리 사용량이 많은지 확인합니다. <ph type="x-smartling-placeholder">
  1. 메시지 프로세서의 CPU 사용량이 높은 경우 대화목록 덤프를 실행합니다.
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. 메시지 프로세서의 메모리 사용량이 많은 경우 힙 dump할 수도 있습니다.
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. 아래 명령어를 사용하여 메시지 프로세서를 다시 시작합니다. CPU 사용률이 메모리:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. API 호출을 모니터링하여 문제가 여전히 존재하는지 확인합니다.
  5. Apigee Edge 지원팀에 문의하여 스레드 덤프, 힙 덤프 및 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 높은 CPU/메모리 사용량의 원인을 조사하세요.

확인 사항: Message에서 NodeJS 백엔드 서버의 제한 시간을 제어하는 방법 프로세서

NodeJS 백엔드 서버는 메시지 프로세서의 JVM 프로세스 내에서 실행됩니다. 이 NodeJS 백엔드 서버의 제한 시간 값은 속성을 통해 제어됩니다. nodejs.properties 파일의 http.request.timeout.seconds 이 속성은 기본적으로 0으로 설정됩니다. 즉, 모든 이 메시지 프로세서가 서비스를 제공하는 조직에 속한 API 프록시입니다. 따라서 NodeJS 백엔드 서버가 오래 걸리면 메시지 프로세서가 시간 초과되지 않습니다.
하지만 NodeJS 백엔드 서버가 오래 걸리고 API에 걸리는 시간이 요청이 > 57초 후 라우터의 시간이 초과되고 504 Gateway Timeout 클라이언트로 전송합니다.

시나리오 #3 - 라우터/메시지 프로세서/백엔드 서버 전에 클라이언트 애플리케이션이 타임아웃됨 응답

다음 날짜 전에 클라이언트 애플리케이션이 시간 초과되면 504 Gateway Timeout 오류가 발생할 수 있습니다. 확인할 수 있습니다 이러한 상황은 다음과 같은 경우에 발생할 수 있습니다.

클라이언트 애플리케이션에 설정된 시간초과 값이 라우터 및 메시지 프로세서:

예를 들어 제한 시간 값이 다음과 같이 설정된 경우입니다.

클라이언트 시간 초과	라우터 시간 초과	메시지 프로세서 시간 초과
50초	57초	55초

이 경우 Edge를 통해 API 요청에 대한 응답을 가져오는 데 사용할 수 있는 총 시간입니다. 50초 이하입니다. 여기에는 API 요청을 하는 데 걸린 시간, 에지 (라우터, 메시지 프로세서)에서 처리되며 요청이 백엔드 서버로 전송됩니다. (해당하는 경우), 요청을 처리하고 응답을 전송하는 백엔드, 마지막으로 클라이언트로 다시 전송합니다.

라우터가 50초 내에 클라이언트에 응답하지 않으면, 클라이언트는 시간이 초과되고 라우터와의 연결을 종료합니다. 클라이언트는 504

이렇게 하면 NGINX에서 클라이언트가 다음을 종료했음을 나타내는 상태 코드 499를 설정합니다. 연결

진단

라우터로부터 응답을 받기 전에 클라이언트 애플리케이션이 시간 초과되면 라우터와의 연결을 닫습니다 이 경우 NGINX 액세스 로그를 확인할 수 있습니다.
상태 코드 499를 보여주는 샘플 NGINX 로그 항목
<ph type="x-smartling-placeholder">
</ph>
위의 예에서 NGINX의 499 상태와 총 경과 시간은 다음과 같습니다. 50.001초 이는 클라이언트가 50.001초 후에 타임아웃되었음을 나타냅니다.

이 경우 메시지에 Broken Pipe 예외가 표시됩니다. 프로세서 로그 (/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>

라우터는 시간이 초과되면 메시지 프로세서와의 연결을 닫습니다. 이 메시지 프로세서는 처리를 완료하고 응답을 라우터에 쓰려고 시도합니다. 라우터에 대한 연결이 이미 닫혀 있으므로 메시지 프로세서에 Broken Pipe exception가 표시됩니다.
이러한 예외는 위에 설명된 상황에서 발생할 수 있습니다. 따라서 504 Gateway Timeout 오류는 여전히 백엔드 서버가 응답하는 데 시간이 오래 걸리고 이 문제를 해결해야 합니다

해상도

커스텀 백엔드 서버인 경우: <ph type="x-smartling-placeholder">

백엔드 서버에서 57초 이상 걸리는 이유를 확인하고 더 빠르게 응답하도록 수정/최적화할 수 있습니다.

백엔드 서버를 수정/최적화할 수 없거나 시간이 오래 걸리면 대기시간 값을 증가시켜 라우터와 메시지 프로세서의 세 가지 기본 네트워크입니다.

아이디어: 다음 각 구성요소에 대해 제한 시간 값을 설정합니다. 주문:

클라이언트 제한 시간 > 라우터 시간 초과 > 메시지 시간 초과 프로세서 > API 프록시 내 제한 시간

NodeJS 백엔드인 경우: <ph type="x-smartling-placeholder">
1. NodeJS 코드가 다른 백엔드 서버를 호출하는지, 그리고 시간이 오래 걸립니다. 백엔드 서버에 시간이 더 오래 걸리는 이유를 확인하세요.
2. 메시지 프로세서의 CPU 또는 메모리 사용량이 많은지 확인합니다. <ph type="x-smartling-placeholder">
  1. 메시지 프로세서의 CPU 사용량이 많으면 대화목록 덤프를 실행합니다.
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. 메시지 프로세서의 메모리 사용량이 많은 경우 힙 덤프 사용하여 다음 명령어를 실행합니다.
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. 아래 명령어를 사용하여 메시지 프로세서를 다시 시작합니다. 이렇게 하면 CPU 및 메모리:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. API 호출을 모니터링하여 문제가 여전히 존재하는지 확인합니다.
  5. Apigee Edge 지원팀에 문의하여 스레드 덤프, 힙 덤프 및 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 높은 CPU/메모리 사용량의 원인을 조사하세요.

다음에서 시간 제한 값을 늘립니다. 라우터 및 메시지 프로세서

다음에 따라 라우터 및 메시지 프로세서에 설정할 제한시간 값을 신중하게 선택합니다. 맞춤설정할 수 있습니다 임의로 큰 제한 시간 값을 설정하지 마세요. 도움이 필요한 경우 다음 연락처로 문의하세요. Apigee Edge 지원

라우터

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

다음 위치에 /opt/apigee/customer/application/router.properties 파일을 만듭니다. 라우터 머신(아직 없는 경우)
이 파일에 다음 줄을 추가합니다.
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
```
예를 들어 시간 제한 값을 120초로 설정하려면 다음과 같이 설정합니다. 다음과 같습니다.
```
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
```
이 파일이 Apigee의 소유인지 확인하세요.

라우터를 다시 시작합니다.

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

라우터가 두 개 이상인 경우 모든 라우터에서 위 단계를 반복합니다.

메시지 프로세서

다음에 /opt/apigee/customer/application/message-processor.properties 파일 만들기 메시지 프로세서 머신이 없는 경우.
이 파일에 다음 줄을 추가합니다.
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
예를 들어 시간 제한 값을 120초로 설정하려면 다음과 같이 설정합니다. 다음과 같습니다.
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

이 파일이 Apigee의 소유인지 확인하세요.

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

메시지 프로세서를 다시 시작합니다.

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

메시지 프로세서가 2개 이상인 경우 모든 메시지에서 위 단계를 반복합니다. 프로세서.

아이디어: 각 구성요소에 대해 시간 제한 값을 다음 순서로 설정하세요.

클라이언트 제한 시간 > 라우터 시간 초과 > 메시지 프로세서 시간 초과 > API 프록시 내 제한 시간

Edge에서 느린 API 요청 처리

Edge가 매우 느리거나 API 요청을 처리하는 데 시간이 오래 걸리는 경우 오류 504 Gateway Timeout개

진단

Edge UI에서 영향을 받는 API를 추적합니다.
오류가 발생할 때까지 기다리거나 API 호출이 있는 경우 API를 호출합니다. 504 Gateway Timeout 오류를 재현합니다.
이 경우 Trace에 성공적인 응답이 표시될 수 있습니다.
1. 라우터/클라이언트는 시간 초과로 인해 메시지 프로세서가 해당 시간 내에 라우터/클라이언트에서 지정된 시간 제한 기간 (둘 중 가장 짧은 시간 제한 시간) 그러나 메시지 프로세서는 계속 요청을 처리하며 있습니다.
2. 또한 HTTPTransport.io.timeout.millis 값은 메시지 프로세서는 메시지 프로세서가 HTTP/HTTPS와 통신하는 경우에만 트리거됩니다. 백엔드 서버입니다 즉, 다른 정책 (다른 사용하는 경우 시간이 오래 걸립니다.
오류가 발생한 후 가장 긴 지연 시간을 가진 특정 요청을 경과 시간이 포함됩니다.
각 단계에서 경과된 시간을 확인하고 시간이 가장 많은 단계를 기록합니다. 합니다.
'서비스' 이외의 정책에서 가장 오래 경과된 시간을 확인한 경우 콜아웃 정책을 설정한 경우 Edge에서 합니다.
다음은 JavaScript 정책에서 매우 긴 경과 시간을 보여주는 샘플 UI 트레이스입니다.
위 예에서 JavaScript 정책이 비정상적으로 오래 걸리는 것을 알 수 있습니다. 약 245초입니다

해상도

응답하는 데 시간이 오래 걸리는 정책, 처리하는 데 오랜 시간이 걸릴 수 있습니다 이러한 코드가 있는 경우 수정/최적화할 수 있습니다
처리 시간을 길어지게 할 수 있는 맞춤 코드가 없는 경우 메시지가 프로세서의 CPU 또는 메모리 사용량이 높습니다. <ph type="x-smartling-placeholder">
1. 메시지 프로세서의 CPU 사용량이 높은 경우 대화목록 덤프를 실행합니다.
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. 메모리 사용량이 많은 메시지 프로세서가 있으면 힙 덤프 사용하여 다음 명령어를 실행합니다.
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. 아래 명령어를 사용하여 메시지 프로세서를 다시 시작합니다. 이로 인해 CPU 사용률이 선택할 수 있습니다
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. API 호출을 모니터링하고 문제가 여전히 존재하는지 확인합니다.
5. Apigee Edge 지원팀에 문의하여 스레드를 제공합니다. 덤프, 힙 덤프 및 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 높은 CPU/메모리 사용량의 원인을 조사하세요.

API 모니터링을 사용하여 문제 진단

API 모니터링을 사용하면 문제 영역을 빠르게 격리하여 오류, 성능, 지연 시간 문제와 그 원인을 진단할 수 있습니다. 백엔드 타겟, API 플랫폼 등의 서비스를 정의할 수 있습니다

API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 살펴봅니다. 예를 들어 504개 상태 코드의 개수가 특정 임계값을 초과하면 알림을 받도록 설정할 수 있습니다.