499 클라이언트 연결 종료

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

증상

클라이언트 애플리케이션에서 API 요청에 대한 시간 제한 오류를 수신하거나 요청이 종료되었습니다. API 요청이 Apigee에서 실행되는 동안 갑자기 발생합니다.

API Monitoring에서 이러한 API 요청의 상태 코드 499를 확인합니다. NGINX 액세스 로그. API 애널리틱스에 다른 상태 코드가 표시되는 이유는 메시지 프로세서가 반환한 상태 코드를 보여줍니다.

오류 메시지

클라이언트 애플리케이션에서 다음과 같은 오류가 표시될 수 있습니다. 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received
 드림 <ph type="x-smartling-placeholder">

클라이언트 시간 초과의 원인은 무엇인가요?

Edge 플랫폼에서의 일반적인 API 요청 경로는 고객 > 라우터 > 메시지 프로세서 > Backend Server를 사용해야 합니다.

Apigee Edge 플랫폼 내의 라우터 및 메시지 프로세서는 기본 제한 시간 값을 설정하여 API 요청을 완료하는 데 너무 오래 걸리지 않도록 합니다.

클라이언트 시간 초과

클라이언트 애플리케이션은 필요에 따라 적절한 시간 제한 값으로 구성할 수 있습니다.

웹브라우저 및 모바일 앱과 같은 클라이언트에는 운영체제에서 정의된 시간 제한이 있습니다.

라우터 시간 초과

라우터에 구성된 기본 제한 시간은 57초입니다. 이 값은 특정 광고가 게재될 수 있는 Edge에서 API 요청이 수신된 시점부터 응답이 실행될 때까지 API 프록시가 실행될 수 있습니다. 백엔드 응답 및 실행된 모든 정책을 포함하여 반환됩니다. 기본값 시간 제한은 라우터 및 가상 호스트에서 재정의될 수 있으며 <ph type="x-smartling-placeholder"></ph> 라우터에서 I/O 제한 시간 구성을 참조하세요.

메시지 프로세서 시간 초과

메시지 프로세서에 구성된 기본 제한 시간은 55초입니다. 최대 금액이며 백엔드 서버가 요청을 처리하고 메시지에 다시 응답하는 데 걸릴 수 있는 시간 프로세서. 기본 제한 시간은 메시지 프로세서 또는 API 내에서 재정의할 수 있습니다. 다음에 설명된 프록시 <ph type="x-smartling-placeholder"></ph> 메시지 프로세서에서 I/O 제한 시간 구성

API 프록시 시간이 초과되기 전에 클라이언트가 라우터와의 연결을 끊으면 특정 API 요청에 대한 시간 초과 오류를 관찰할 것입니다 이러한 요청에 대해 상태 코드 499 Client Closed Connection가 라우터에 로깅되며, API에서 확인할 수 있습니다. Monitoring 및 NGINX 액세스 로그

가능한 원인

Edge에서 499 Client Closed Connection 오류가 발생하는 일반적인 원인은 다음과 같습니다.

원인 설명 다음에 관한 문제 해결 안내
클라이언트가 연결을 갑자기 종료함 이는 최종 사용자가 연결을 취소하여 클라이언트가 연결을 종료할 때 발생합니다. 요청이 완료될 때까지 기다리세요. 퍼블릭 및 프라이빗 클라우드 사용자
클라이언트 애플리케이션 제한 시간 이 문제는 API 프록시가 해당 요청을 처리하기 전에 클라이언트 응용 프로그램이 응답을 전송합니다. 일반적으로 클라이언트 제한 시간이 짧은 경우에 발생합니다. 더 클 수 있습니다. 퍼블릭 및 프라이빗 클라우드 사용자

일반적인 진단 단계

다음 도구/기술 중 하나를 사용하여 이 오류를 진단합니다.

  • API 모니터링
  • NGINX 액세스 로그

API 모니터링

<ph type="x-smartling-placeholder">

API 모니터링을 사용하여 오류를 진단하려면 다음 안내를 따르세요.

  1. 분석 > API 모니터링 > 조사 페이지를 엽니다.
  2. 오류 4xx개를 필터링하고 기간을 선택하세요.
  3. 시간을 기준으로 상태 코드를 표시합니다.
  4. 아래와 같이 오류가 499개 있는 셀을 선택하세요.

  5. 오른쪽 창에 다음과 같이 499 오류에 대한 정보가 표시됩니다. 다음과 같습니다.

  6. 오른쪽 창에서 로그 보기를 클릭합니다.

    트래픽 로그 창에서 일부 499에 대한 다음 세부정보를 확인합니다. 오류:

    • 요청:호출하는 데 사용되는 요청 메서드와 URI를 제공합니다.
    • 응답 시간:요청에 대해 경과된 총 시간을 제공합니다.
    를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

    API Monitoring API를 사용하여 모든 로그를 GET logs API를 사용합니다. 대상 예를 들어 org, env timeRange, status를 사용하는 경우 클라이언트 시간이 초과된 트랜잭션의 로그

    API Monitoring에서 HTTP 499의 경우 프록시를 -로 설정하므로 API를 사용하여 (Logs API) 가상 호스트 및 경로에 연결된 프록시입니다.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Response Time에서 추가 499 오류를 검토하고 다음 사항을 확인합니다. 모든 테스트 응답에서 응답 시간이 일관적 (예: 30초) 오류가 499개 있습니다.

NGINX 액세스 로그

<ph type="x-smartling-placeholder">

NGINX 액세스 로그를 사용하여 오류를 진단하려면 다음 안내를 따르세요.

  1. Private Cloud 사용자는 NGINX 액세스 로그를 사용하여 HTTP 499 오류에 대한 주요 정보입니다.
  2. NGINX 액세스 로그를 확인합니다.
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. 특정 기간 동안 오류 499개가 있는지 검색하세요. (과거에 문제가 발생한 경우) 또는 여전히 499
  4. 일부 499 오류에 관해 다음 정보를 참고하세요. <ph type="x-smartling-placeholder">
      </ph>
    • Total Response Time(총 대응 시간)
    • 요청 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
  5. Total Response Time(총 응답 시간) 및 User Agent(사용자 에이전트)가 일관적인지 확인합니다. 전체 오류 499개

원인: 클라이언트가 갑자기 연결을 종료함

진단

  1. 브라우저 또는 모바일 애플리케이션에서 실행되는 단일 페이지 앱에서 API를 호출하면 최종 사용자가 갑자기 브라우저를 닫고 탐색한 후 다른 웹페이지로 이동하거나, 클릭하거나 탭하여 페이지 로드를 중지할 수도 있습니다. 로드를 중지합니다.
  2. 이 경우 HTTP 499 상태의 트랜잭션은 일반적으로 다음과 같이 달라집니다. 요청 처리 시간 (응답 시간)으로 계산됩니다.
  3. 응답 시간을 비교하고 다음을 확인하면 원인을 파악할 수 있습니다. API Monitoring 또는 NGINX 액세스를 사용하는 각 499 오류마다 다릅니다. 일반적인 진단 단계에 설명된 대로 로그를 확인합니다.

해상도

  1. 이는 정상이며 HTTP 499 오류 발생 시 일반적으로 문제가 되지는 않습니다. 발생하는 문제죠.

  2. 동일한 URL 경로에서 이 문제가 자주 발생하는 경우 특정 프록시가 매우 느리고 사용자는 기다릴 필요가 없습니다.

    영향을 받을 수 있는 프록시를 확인한 후 지연 시간 분석 대시보드를 사용하여 프록시 지연 시간의 원인을 자세히 조사하세요.

    1. 이 경우 다음 단계에 따라 영향을 받은 프록시를 확인합니다. 일반적인 진단 단계.
    2. 지연 시간 분석 대시보드를 사용하여 프록시 지연 시간의 원인을 자세히 조사하고 문제를 해결합니다.
    3. 특정 프록시에 대한 지연 시간이 예상되는 경우 이 프록시가 응답하는 데 다소 시간이 걸린다는 것을 사용자에게 알려야 합니다.

원인: 클라이언트 애플리케이션 시간 초과

이는 여러 시나리오에서 발생할 수 있습니다.

  1. 요청이 완료되는 데 특정 시간 (예: 10초)이 소요될 것으로 예상됩니다. 훨씬 크다는 것을 의미합니다. 하지만 클라이언트 애플리케이션이 올바른 시간 제한 값 (예: 5초)으로, 클라이언트 애플리케이션이 API 요청이 완료되어 499가 발생합니다. 이 경우 클라이언트 제한 시간을 적절한 값으로 설정하세요.
  2. 대상 서버 또는 콜아웃이 예상보다 오래 걸리고 있습니다. 이 경우 시간 제한 값을 적절하게 조정할 수도 있습니다.
  3. 클라이언트가 더 이상 응답이 필요하지 않으므로 중단되었습니다. 이 문제는 빈도 API(예: 자동 완성 또는 짧은 폴링)

진단

API 모니터링 또는 NGINX 액세스 로그

API Monitoring 또는 NGINX 액세스 로그를 사용하여 오류를 진단합니다.

  1. 다음에 설명된 대로 API 모니터링 로그 또는 NGINX 액세스 로그에서 HTTP 499 트랜잭션을 확인합니다. 일반적인 진단 단계
  2. 모든 499 오류에서 응답 시간이 일관적인지 확인합니다.
  3. 답이 '예'인 경우 특정 클라이언트 애플리케이션이 고정된 시간 제한을 구성했기 때문일 수 있습니다. 있습니다. API 프록시 또는 대상 서버가 느리게 응답하는 경우 클라이언트가 타임아웃됩니다. 그 결과 HTTP 499s가 대량으로 전송되어 동일한 URI 경로를 사용합니다. 이 경우 NGINX 액세스 로그에서 사용자 에이전트사용자 에이전트를 특정 클라이언트 애플리케이션을 확인하는 데 도움이 됩니다.
  4. 또한 Apigee 앞에 Akamai와 같은 부하 분산기가 F5, AWS ELB 등 Apigee가 커스텀 부하 분산기 뒤에서 실행되는 경우 요청은 부하 분산기의 제한 시간을 Apigee API 제한 시간 초과로 구성해야 합니다. 작성자: 기본적으로 Apigee 라우터는 57초 후에 타임아웃되므로 60초로 설정합니다

Trace

Trace를 사용하여 오류 진단

문제가 계속 발생하는 경우 (오류 499개가 계속 발생함) 다음을 수행합니다. 다음 단계를 따르세요.

  1. 사용 설정 트레이스 세션 에 대해 자세히 알아보세요.
  2. 오류가 발생할 때까지 기다리거나 API 호출이 있는 경우 API를 호출합니다. 오류를 재현할 수 있습니다.
  3. 각 단계의 경과 시간을 확인하고 가장 많은 시간이 발생한 단계를 기록합니다. 비용을 지출하는 것으로 나타났습니다
  4. 오류가 발생한 후 오류가 발생하면 백엔드 서버가 느리거나 시간이 오래 걸리는 것을 요청을 처리합니다. <ph type="x-smartling-placeholder">
      </ph>
    • 대상 서버로 요청이 전송됨
    • ServiceCallout 정책

    다음은 Request가 완료된 후 Gateway Timeout(게이트웨이 시간 초과)을 보여주는 샘플 UI 트레이스입니다. 대상 서버로 전송되는 URL:

해상도

  1. 자세한 내용은 제한 시간 값을 설정해야 하는 경우를 파악하기 위한 I/O 제한 시간 구성 권장사항 Apigee Edge를 통한 API 요청 흐름과 관련된 다양한 구성요소에 대해 알아봅니다.
  2. 다음에 따라 클라이언트 애플리케이션에 적절한 시간 제한 값을 설정했는지 확인합니다. 확인할 수 있습니다

문제가 계속되면 진단 정보를 수집해야 함을 참고하세요 .

진단 정보 수집 필요

문제가 지속되면 다음 진단 정보를 수집한 후 Apigee Edge 지원팀에 문의하세요.

퍼블릭 클라우드 사용자는 다음 정보를 입력합니다.

  • 조직 이름
  • 환경 이름
  • 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)