현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보
증상
클라이언트 애플리케이션에 API 요청에 대한 시간 초과 오류가 수신되거나 API 요청이 Apigee에서 아직 실행되는 동안 요청이 갑자기 종료됩니다.
API 모니터링 및 NGINX 액세스 로그에서 이러한 API 요청의 상태 코드 499를 확인할 수 있습니다. 메시지 프로세서에서 반환한 상태 코드를 보여주기 때문에 API 애널리틱스에 다른 상태 코드가 표시되는 경우가 있습니다.
오류 메시지
클라이언트 애플리케이션에는 다음과 같은 오류가 표시될 수 있습니다.
curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
클라이언트 시간 초과의 원인은 무엇인가요?
Edge 플랫폼에서 API 요청의 일반적인 경로는 다음 그림과 같이 클라이언트 > 라우터 > 메시지 프로세서 > 백엔드 서버입니다.
Apigee Edge 플랫폼 내의 라우터 및 메시지 프로세서는 API 요청을 완료하는 데 너무 오래 걸리지 않도록 적절한 기본 시간 제한 값으로 설정됩니다.
클라이언트 시간 초과
클라이언트 애플리케이션은 필요에 따라 적절한 제한 시간 값으로 구성할 수 있습니다.
웹브라우저 및 모바일 앱과 같은 클라이언트에는 운영체제에서 정의한 시간 제한이 있습니다.
라우터 시간 초과
라우터에 구성된 기본 제한 시간은 57초입니다. Edge에서 API 요청이 수신된 시점부터 응답이 다시 전송될 때까지 API 프록시를 실행할 수 있는 최대 시간으로, 백엔드 응답 및 실행된 모든 정책이 포함됩니다. 기본 제한 시간은 라우터의 I/O 시간 제한 구성의 설명대로 라우터 및 가상 호스트에서 재정의할 수 있습니다.
메시지 프로세서 제한 시간
메시지 프로세서에 구성된 기본 제한 시간은 55초입니다. 이 시간은 백엔드 서버가 요청을 처리하고 메시지 프로세서에 응답하는 데 걸리는 최대 시간입니다. 메시지 프로세서의 I/O 제한 시간 구성에 설명된 대로 메시지 프로세서 또는 API 프록시에서 기본 제한 시간을 재정의할 수 있습니다.
API 프록시 시간이 초과되기 전에 클라이언트가 라우터와의 연결을 닫으면 특정 API 요청에 대한 시간 초과 오류가 표시됩니다. 이러한 요청에 대해 상태 코드 499 Client
Closed Connection가 라우터에 로깅되며, API 모니터링 및 NGINX 액세스 로그에서 확인할 수 있습니다.
가능한 원인
Edge에서 499 Client Closed Connection 오류의 일반적인 원인은 다음과 같습니다.
| 원인 | 설명 | 다음에 관한 문제 해결 안내 |
|---|---|---|
| 클라이언트가 갑자기 연결을 종료함 | 요청이 완료되기 전에 최종 사용자가 요청을 취소하여 클라이언트에서 연결을 닫을 때 이러한 상황이 발생합니다. | 퍼블릭 및 프라이빗 클라우드 사용자 |
| 클라이언트 애플리케이션 제한 시간 | API 프록시가 응답을 처리하고 전송하기 전에 클라이언트 애플리케이션이 타임아웃되면 발생합니다. 일반적으로 클라이언트 제한 시간이 라우터 제한 시간보다 짧을 때 발생합니다. | 퍼블릭 및 프라이빗 클라우드 사용자 |
일반적인 진단 단계
다음 도구/기술 중 하나를 사용하여 이 오류를 진단하세요.
- API 모니터링
- NGINX 액세스 로그
API 모니터링
API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.
- 분석 > API 모니터링 > 조사 페이지로 이동합니다.
- 오류
4xx개를 필터링하고 기간을 선택합니다. - 시간을 기준으로 상태 코드를 표시합니다.
- 아래와 같이 오류가
499개인 셀을 선택하세요.
- 아래와 같이 오른쪽 창에
499오류에 관한 정보가 표시됩니다.
- 오른쪽 창에서 로그 보기를 클릭합니다.
트래픽 로그 창에서 일부
499오류에 대한 다음 세부정보를 확인합니다.- 요청:호출하는 데 사용되는 요청 메서드와 URI를 제공합니다.
- 응답 시간:요청에 경과된 총 시간을 제공합니다.
API Monitoring GET logs API를 사용하여 모든 로그를 가져올 수도 있습니다. 예를 들어
org,env,timeRange,status의 로그를 쿼리하면 클라이언트가 타임아웃된 트랜잭션의 모든 로그를 다운로드할 수 있습니다.API Monitoring은 HTTP
499오류의 경우 프록시를-로 설정하므로 API(로그 API)를 사용하여 가상 호스트 및 경로의 관련 프록시를 가져올 수 있습니다.For example :
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
- 추가
499오류가 있는지 응답 시간을 검토하고 응답 시간이 모든499오류에서 일관적인지 (예: 30초) 확인합니다.
NGINX 액세스 로그
NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.
- Private Cloud 사용자는 NGINX 액세스 로그를 사용하여 HTTP
499오류에 대한 주요 정보를 확인할 수 있습니다. - NGINX 액세스 로그를 확인합니다.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log - 특정 기간 동안
499오류가 있었는지(과거에 문제가 발생한 경우)499와 함께 여전히 실패하는 요청이 있는지 검색합니다. - 일부
499오류에 관한 다음 정보를 참고하세요.- 총 응답 시간
- 요청 URI
- 사용자 에이전트
NGINX 액세스 로그의 샘플 499 오류:
2019-08-23T06:50:07+00:00 rrt-03f69eb1091c4a886-c-sy 50.112.119.65:47756 10.10.53.154:8443 10.001 - - 499 - 422 0 GET /v1/products HTTP/1.1 - okhttp/3.9.1 api.acme.org rrt-03f69eb1091c4a886-c-sy-13001-6496714-1 50.112.119.65 - - - - - - - -1 - - dc-1 router-pod-1 rt-214-190301-0020137-latest-7d 36 TLSv1.2 gateway-1 dc-1 acme prod https -이 예에서는 다음 정보가 표시됩니다.
- 총 응답 시간:
10.001초 이는 클라이언트가 10.001초 후에 타임아웃되었음을 나타냅니다. - 요청:
GET /v1/products - 호스트:
api.acme.org - 사용자 에이전트:
okhttp/3.9.1
- 모든
499오류에서 총 응답 시간과 사용자 에이전트가 일관적인지 확인합니다.
원인: 클라이언트가 갑자기 연결을 종료함
진단
- 브라우저 또는 모바일 애플리케이션에서 실행되는 단일 페이지 앱에서 API가 호출되면 최종 사용자가 갑자기 브라우저를 닫거나, 같은 탭의 다른 웹페이지로 이동하거나, 로드 중지를 클릭하거나 탭하여 페이지 로드를 중지하는 경우 브라우저에서 요청을 취소합니다.
- 이 경우 HTTP
499상태의 트랜잭션은 일반적으로 각 요청의 요청 처리 시간 (응답 시간)이 다릅니다. -
일반적인 진단 단계에 설명된 대로 응답 시간을 비교하고 API Monitoring 또는 NGINX 액세스 로그를 사용하여
499오류마다 다른지 확인하면 이것이 원인인지 확인할 수 있습니다.
해상도
- 이는 정상이며 HTTP
499오류가 소량으로 발생하는 경우에는 일반적으로 문제가 되지 않습니다. -
동일한 URL 경로에서 이 문제가 자주 발생하는 경우 해당 경로와 연결된 특정 프록시가 매우 느리고 사용자가 기다릴 의사가 없기 때문일 수 있습니다.
영향을 받을 수 있는 프록시를 알면 지연 시간 분석 대시보드를 사용하여 프록시 지연 시간의 원인을 자세히 조사합니다.
- 이 경우 일반적인 진단 단계의 단계를 사용하여 영향을 받는 프록시를 결정합니다.
- 지연 시간 분석 대시보드를 사용하여 프록시 지연 시간의 원인을 자세히 조사하고 문제를 해결합니다.
- 특정 프록시의 지연 시간이 예상되는 경우 사용자에게 이 프록시가 응답하는 데 다소 시간이 걸린다고 알려야 할 수 있습니다.
원인: 클라이언트 애플리케이션 시간 초과
이는 여러 가지 시나리오에서 발생할 수 있습니다.
-
정상적인 작동 조건에서 요청이 완료되는 데 특정 시간 (예: 10초)이 걸릴 것으로 예상됩니다. 하지만 클라이언트 애플리케이션이 잘못된 시간 제한 값 (예: 5초)으로 설정되어 API 요청이 완료되기 전에 클라이언트 애플리케이션의 시간 초과가 발생하여
499이 발생합니다. 이 경우에는 클라이언트 시간 제한을 적절한 값으로 설정해야 합니다. - 타겟 서버 또는 콜아웃이 예상보다 오래 걸리고 있습니다. 이 경우 적절한 구성요소를 수정하고 시간 제한 값도 적절하게 조정해야 합니다.
- 클라이언트에서 더 이상 응답이 필요하지 않아 취소되었습니다. 이 문제는 자동 완성 또는 짧은 폴링과 같은 빈도가 높은 API에서 발생할 수 있습니다.
진단
API 모니터링 또는 NGINX 액세스 로그
API Monitoring 또는 NGINX 액세스 로그를 사용하여 오류를 진단합니다.
- 일반적인 진단 단계에 설명된 대로 API Monitoring 로그 또는 NGINX 액세스 로그에서 HTTP
499트랜잭션을 확인합니다. - 모든
499오류에서 응답 시간이 일관적인지 확인합니다. - 그렇다면 특정 클라이언트 애플리케이션이 고정 시간 제한을 설정했기 때문일 수 있습니다. API 프록시 또는 대상 서버가 느리게 응답하면 프록시 시간이 초과되기 전에 클라이언트가 시간 초과되어 동일한 URI 경로에 대량의 HTTP
499s가 발생합니다. 이 경우 NGINX 액세스 로그에서 특정 클라이언트 애플리케이션을 확인하는 데 도움이 되는 사용자 에이전트를 확인합니다. - Akamai, F5, AWS ELB 등과 같은 Apigee 앞에 부하 분산기가 있을 수도 있습니다. Apigee가 커스텀 부하 분산기 뒤에서 실행되는 경우 부하 분산기의 요청 제한 시간이 Apigee API 제한 시간보다 길도록 구성해야 합니다. 기본적으로 Apigee 라우터는 57초 후에 타임아웃되므로 부하 분산기에 요청 제한 시간을 60초로 구성하는 것이 좋습니다.
Trace
Trace를 사용하여 오류 진단
문제가 여전히 활성 상태이면 (499 오류가 계속 발생함) 다음 단계를 따르세요.
- Edge UI에서 영향을 받은 API에 트레이스 세션을 사용 설정합니다.
- 오류가 발생할 때까지 기다리거나 API 호출이 있는 경우 API를 호출하고 오류를 재현합니다.
- 각 단계에서 경과된 시간을 확인하고 시간이 가장 많이 소요되는 단계를 기록해 둡니다.
- 다음 단계 중 하나 직후에 경과된 시간이 가장 긴 오류가 나타나면 백엔드 서버가 느리거나 요청을 처리하는 데 시간이 오래 걸린다는 의미입니다.
- 요청이 대상 서버로 전송됨
- ServiceCallout 정책
다음은 Request가 대상 서버로 전송된 후 게이트웨이 시간 초과를 보여주는 샘플 UI 추적입니다.
해상도
- Apigee Edge를 통한 API 요청 흐름과 관련된 여러 구성요소에 설정해야 하는 제한 시간 값을 알아보려면 I/O 제한 시간 구성 권장사항을 참조하세요.
- 권장사항에 따라 클라이언트 애플리케이션에 적절한 제한 시간 값을 설정해야 합니다.
문제가 계속되면 진단 정보를 수집해야 하는 경우로 이동하세요 .
진단 정보 수집 필요
문제가 지속되면 다음 진단 정보를 수집한 다음 Apigee Edge 지원팀에 문의하세요.
Public Cloud 사용자인 경우 다음 정보를 제공합니다.
- 조직 이름
- 환경 이름
- API 프록시 이름
- 시간 초과 오류를 재현하는 데 사용되는 전체
curl명령어 - 클라이언트 시간 제한 오류가 표시되는 API 요청에 대한 추적 파일
Private Cloud 사용자인 경우 다음 정보를 제공하세요.
- 실패한 요청에 대해 발견된 전체 오류 메시지
- 환경 이름
- API 프록시 번들
- 클라이언트 시간 제한 오류가 표시되는 API 요청에 대한 추적 파일
- NGINX 액세스 로그 (
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) - 메시지 프로세서 시스템 로그 (
/opt/apigee/var/log/edge-message-processor/logs/system.log)