500 내부 서버 오류

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

동영상

500개의 내부 서버 오류 해결에 대해 자세히 알아보려면 다음 동영상을 시청하세요.

동영상 설명
소개 500개의 내부 서버 오류와 가능한 원인을 소개합니다. 또한 다음을 보여줍니다. 실시간 500 내부 서버 오류 및 오류 해결 단계
서비스 콜아웃 처리 및 변수 추출 오류 서비스 콜아웃 및 변수 추출 정책으로 인해 발생한 500개의 내부 서버 오류 2개를 보여줍니다. 이러한 오류를 해결하는 방법을 보여줍니다.
JavaScript 정책 오류 처리 JavaScript 정책 및 단계로 인해 발생한 500 내부 서버 오류가 표시됩니다. 이 오류를 해결할 수 있습니다.
백엔드 서버의 실패 처리 백엔드 서버의 장애로 인해 발생한 내부 서버 오류 500개의 예를 보여주고 단계를 보여줍니다. 오류를 해결할 수 있습니다.

증상

클라이언트 애플리케이션이 HTTP 상태 코드 500을 가져오고 '내부 서버 오류'를 API 호출에 대한 응답으로 표시합니다. 500 내부 서버 오류는 Edge 내에서 정책을 실행하는 중에 발생한 오류 또는 오류로 인해 발생할 수 있습니다. kube-APIserver로 전송합니다

HTTP 상태 코드 500은 일반적인 오류 응답입니다. 서버에 특정 오류가 발생했다는 예상치 못한 상태로 인해 요청을 수행할 수 없게 되었습니다. 이 오류는 일반적으로 다른 오류 코드가 적절하지 않은 경우 서버에서 반환함.

오류 메시지

다음과 같은 오류 메시지가 표시될 수 있습니다.

HTTP/1.1 500 Internal Server Error

경우에 따라 더 자세한 내용이 포함된 다른 오류 메시지가 표시될 수도 있습니다. 다음은 샘플입니다 오류 메시지:

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

가능한 원인

500 내부 서버 오류는 여러 가지 원인으로 인해 발생할 수 있습니다. Edge에서 원인은 오류가 발생한 위치에 따라 두 가지 주요 카테고리로 분류할 수 있습니다.

원인 세부정보 자세한 문제 해결 단계는 다음과 같습니다.
에지 정책의 실행 오류 정책 오류가 발생할 수 있습니다 Edge 프라이빗 및 퍼블릭 클라우드 사용자
백엔드 서버 오류 어떤 이유로든 백엔드 서버가 실패할 수 있습니다. Edge 프라이빗 및 퍼블릭 클라우드 사용자

에지 정책의 실행 오류

A Policy 어떤 이유로든 API 프록시가 실패할 수 있습니다. 이 섹션에서는 다음과 같은 경우 문제를 해결하는 방법을 설명합니다. 정책을 실행하는 동안 500 내부 서버 오류가 발생하는 경우

진단

프라이빗 및 퍼블릭 클라우드 사용자를 위한 진단 단계

오류에 대한 트레이스 UI 세션이 있는 경우:

  1. 오류가 정책 실행으로 인해 발생했는지 확인합니다. 자세한 내용은 문제의 원인 확인을 참조하세요.
  2. 정책 실행 중에 오류가 발생한 경우 계속 진행하세요. 오류가 백엔드 서버에서 오류 발생으로 이동합니다.
  3. 추적에서 500 내부 서버 오류와 함께 실패한 API 요청을 선택하세요.
  4. 요청을 검토하고 실패한 특정 정책 또는 '오류' trace에서 실패한 정책 바로 뒤에 오는
  5. '오류'를 확인하여 오류에 대한 자세한 내용을 확인합니다. 필드를 섹션 또는 오류 콘텐츠를 확인하세요
  6. 오류에 관해 수집한 세부정보를 사용하여 원인을 파악해 보세요.

프라이빗 클라우드 사용자만을 위한 진단 단계

트레이스 UI 세션이 없는 경우:

  1. 정책 실행 중에 오류가 발생했는지 확인합니다. 자세한 내용은 문제의 원인 확인을 참조하세요.
  2. 정책 실행으로 인해 오류가 발생한 경우 계속 진행합니다. 정책 실행 중에 오류가 발생한 경우 계속 진행합니다. 백엔드 서버로 인해 오류가 발생한 경우 백엔드 서버에서 오류로 이동합니다.
  3. 다음에 설명된 대로 NGINX 액세스 로그를 사용합니다. 문제의 근원을 파악하여 API 프록시에서 실패한 정책을 결정하고 고유 요청 메시지 ID
  4. 메시지 프로세서 로그 확인 (/opt/apigee/var/log/edge-message-processor/logs/system.log)로 이동하여 고유 요청 메시지 ID를 포함시킵니다.
  5. 고유한 요청 메시지 ID를 찾은 경우 장애의 원인이 됩니다

해상도

정책에서 발생한 문제의 원인을 파악했다면 정책을 수정하고 프록시를 재배포했습니다

다음 예는 다양한 상황에서 원인과 해결 방법을 문제 유형에 따라 다릅니다

500 내부 서버 오류 문제 해결을 위해 추가 지원이 필요하거나 Edge 내에서 문제인 경우 Apigee에 문의 지원을 참조하세요.

예 1: 백엔드 오류로 인한 서비스 콜아웃 정책 실패 서버

서비스 콜아웃 정책 내에서 백엔드 서버 호출이 다음과 같은 오류와 함께 실패하는 경우 4XX 또는 5XX인 경우 500 내부 서버 오류로 처리됩니다.

  1. 다음은 서비스 내에서 백엔드 서비스가 404 오류와 함께 실패하는 예입니다. 콜아웃 정책 다음 오류 메시지가 최종 사용자에게 전송됩니다. 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. 다음 트레이스 UI 세션은 서비스 오류로 인해 발생한 500 상태 코드를 보여줍니다. 콜아웃 정책:

  3. 이 예에서 'error'는 속성에는 서비스 콜아웃 정책의 이유가 나열됩니다. "ResponseCode 404가 오류로 처리됨"으로 표시됩니다. 이 오류는 다음과 같은 경우에 발생할 수 있습니다. 서비스 콜아웃 정책의 백엔드 서버 URL을 통해 액세스 중인 리소스가 있습니다.
  4. 백엔드 서버에서 리소스의 가용성을 확인합니다. 이용하지 못할 수도 있습니다. 임시로/영구적으로 삭제되거나 다른 위치로 이동되었을 수 있습니다.

예시 1 해결 방법

  1. 백엔드 서버에서 리소스의 가용성을 확인합니다. 이용하지 못할 수도 있습니다. 임시로/영구적으로 삭제되거나 다른 위치로 이동되었을 수 있습니다.
  2. 유효한 기존 리소스도 제공합니다
  3. 리소스를 일시적으로 사용할 수 없는 경우 리소스를 사용할 수 있습니다

예 2: 변수 추출 정책 실패

이제 다른 예를 살펴보겠습니다. 500 내부 서버 오류가 오류 때문에 를 살펴보고 문제를 해결하는 방법을 알아봅니다.

  1. UI 세션의 다음 trace는 추출 내 오류로 인한 500 상태 코드를 보여줍니다. 변수 정책:

  2. 실패한 변수 추출 정책을 선택하고 아래로 스크롤하여 '오류 콘텐츠' 섹션에서 자세한 내용을 확인하세요.
    <ph type="x-smartling-placeholder">
    </ph>
  3. 오류 콘텐츠는 &quot;serviceCallout.oamCookieValidationResponse&quot; 변수는 변수 추출 정책 변수 이름에서 알 수 있듯이 이전 서비스 콜아웃 정책의 응답을 반환합니다.
  4. trace에서 서비스 콜아웃 정책을 선택하면 &quot;serviceCallout.oamCookieValidationResponse&quot; 변수가 설정되지 않았습니다. 이 는 백엔드 서비스 호출이 실패하여 빈 응답이 발생했음을 나타냅니다. 변수의 값을 지정합니다.
  5. 서비스 콜아웃 정책은 실패했지만, 서비스 호출 이후에 정책 실행은 'continueOnError' 오류가 발생하여 서비스 콜아웃 정책의 플래그가 설정됨 true로 설정합니다.

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. 이 특정 API의 고유 메시지 ID &quot;X-Apigee.Message-ID&quot;를 기록해 둡니다. 요청을 다음과 같이 삭제합니다. <ph type="x-smartling-placeholder">
      </ph>
    1. '기록된 애널리틱스 데이터'를 선택합니다. 요청의 단계
    2. 아래로 스크롤하여 X-Apigee.Message-ID의 값을 확인합니다.

  7. 메시지 프로세서 로그 보기 (/opt/apigee/var/log/edge-message-processor/system.log)로 이동하여 메시지 ID가 기록되었습니다. 특정 API에서 다음과 같은 오류 메시지가 발견되었습니다. 요청: 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

    위 오류는 연결로 인해 서비스 콜아웃 정책이 실패했음을 나타냅니다. 백엔드 서버에 연결하는 동안 시간 초과 오류가 발생했습니다.

  8. 연결 시간 초과 오류의 원인을 확인하기 위해 telnet 명령어를 메시지 프로세서에서 백엔드 서버로 전송합니다. 텔넷 명령어에 '연결 시간이 초과되었습니다'라는 메시지가 표시됨 오류가 표시됩니다. 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    일반적으로 이 오류는 다음과 같은 상황에서 발생합니다.

    • 백엔드 서버가 에지 메시지의 트래픽을 허용하도록 구성되지 않은 경우 프로세서.
    • 백엔드 서버가 특정 포트에서 수신 대기하지 않는 경우

    위에 나와 있는 예시에서 변수 추출 정책은 실패했지만 실제 Edge가 서비스 콜아웃에서 백엔드 서버에 연결할 수 없었기 때문입니다. 정책 이 실패의 원인은 백엔드 엔드 서버가 에지 메시지 프로세서의 트래픽을 허용합니다.

    자체 변수 추출 정책은 다르게 작동하며 서로 다른 경우에 따라 실패할 수 있습니다. 있습니다. 오류가 발생한 원인에 따라 error 영역에서 메시지를 확인하여 변수 추출 정책 속성

예시 2 해결 방법

  1. 변수 추출 정책에서 오류 또는 실패의 원인을 적절하게 수정합니다.
  2. 위에 묘사된 예에서, 해결책은 네트워크 구성을 정정하여 에지 메시지 프로세서에서 백엔드 서버로의 트래픽을 허용합니다. 이 작업을 수행한 사람: 메시지 프로세서의 허용 목록에 특정 백엔드 서버의 IP 주소입니다. 예를 들어 경우에는 iptables를 사용하여 백엔드 서버에 있는 메시지 프로세서의 IP 주소입니다.

예 3: Java콜아웃 정책의 실패

이제 오류 때문에 500 내부 서버 오류가 발생하는 예를 하나 더 살펴보겠습니다. 자바 콜아웃 정책을 살펴보고 문제를 해결하는 방법을 알아보세요.

  1. 다음 UI 트레이스는 Java 콜아웃 정책의 오류로 인한 500 상태 코드를 보여줍니다.

  2. 이름이 'Error'인 흐름을 선택한 다음 실패한 Java 콜아웃 정책이 표시됩니다. 아래 그림과 같이 오류 세부정보를 가져옵니다.

  3. 이 예에서 속성 섹션의 "error" 속성을 통해 Oracle 데이터베이스에 연결하는 동안 사용 중인 비밀번호가 만료되어 실패함 를 호출할 수 있습니다. 자체 자바 콜아웃은 다르게 작동하며 error 속성에 다른 메시지를 채웁니다.
  4. Java콜아웃 정책 코드를 점검하고 올바른 구성을 확인합니다. 있습니다.

예시 3 해결 방법

런타임 예외를 방지하기 위해 자바 콜아웃 코드 또는 구성을 적절하게 수정합니다. 포함 위의 자바 콜아웃 실패 예시를 참조하세요. 올바른 비밀번호를 사용해야 합니다. Oracle 데이터베이스에 연결하여 문제를 해결할 수 있습니다

백엔드 서버에서 오류 발생

500 내부 서버 오류도 백엔드 서버에서 발생할 수 있습니다. 이 섹션 은 백엔드 서버에서 오류가 발생한 경우 문제를 해결하는 방법을 설명합니다.

진단

모든 사용자를 위한 진단 단계

기타 백엔드 오류의 원인은 크게 다를 수 있습니다. 각 상황을 진단해야 함 독립적으로 작동합니다

  1. 백엔드 서버로 인해 오류가 발생했는지 확인합니다. 자세한 내용은 문제의 원인 확인을 참조하세요.
  2. 백엔드 서버로 인해 오류가 발생한 경우 계속 진행합니다. 오류 발생 시간 정책 실행을 확인하려면 에지의 실행 오류 페이지로 이동하세요. 정책을 참조하세요.
  3. 다음 인스턴스의 trace 세션에 액세스할 수 있는지 여부에 따라 아래 단계를 따르세요. 백엔드가 Node.js 서버인 경우 다음을 실행합니다.

실패한 API 호출에 대한 추적 세션이 없는 경우:

  1. 실패한 요청에 UI trace를 사용할 수 없는 경우 백엔드 서버를 확인합니다. 로그를 사용하여 오류에 대한 세부정보를 가져옵니다.
  2. 가능하면 백엔드 서버에서 디버그 모드를 사용 설정하여 살펴봤습니다

실패한 API 호출에 대한 추적 세션이 있는 경우:

Trace 세션이 있는 경우 다음 단계를 통해 문제를 진단할 수 있습니다.

  1. 추적 도구에서 500 내부 서버로 실패한 API 요청을 선택합니다. 오류가 발생했습니다.
  2. 실패 목록에서 'Response received from target server(대상 서버에서 응답 수신됨)' 단계를 선택합니다. API 요청을 전송해야 합니다.

  3. '응답 콘텐츠' 섹션에서 오류에 대한 세부정보를 확인할 수 있습니다.

  4. 이 예에서 SOAP 봉투인 응답 콘텐츠는 결함 문자열을 '승인되지 않음' 메시지가 표시됨 이 문제의 가장 가능성이 높은 원인은 문제는 올바른 자격 증명 (사용자 이름/비밀번호, 액세스 토큰 등)이 사용자가 백엔드 서버를 사용하도록 할 수 있습니다. 이 문제는 백엔드 서버입니다

백엔드가 Node.js 서버인 경우:

  1. 백엔드가 Node.js 백엔드 서버인 경우 Node.js 로그를 확인합니다. (퍼블릭 및 프라이빗 클라우드 사용자 모두 Node.js 로그 확인). Edge 프라이빗 클라우드 사용자인 경우 메시지 프로세서 로그를 확인하여 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 자세한 내용을 확인하세요. 오류 정보

    Edge UI의 NodeJS 로그 옵션 - API 프록시의 개요 탭

해결 방법

  1. 오류의 원인을 확인한 후 백엔드 서버에서 문제를 해결합니다.
  2. Node.js 백엔드 서버인 경우: <ph type="x-smartling-placeholder">
      </ph>
    1. 커스텀 코드에서 오류가 발생하는지 확인하고 가능한 경우 문제를 해결합니다.
    2. 커스텀 코드에서 오류가 발생하지 않거나 도움이 필요한 경우 Apigee 지원

500 내부 서버 오류 문제 해결을 위해 추가 지원이 필요하거나 Edge 내에서 문제인 경우 Apigee에 문의 지원을 참조하세요.

문제의 원인 파악

다음 절차 중 하나를 사용하여 500 내부 서버 오류가 발생했는지 확인합니다. 정책을 실행하는 동안에만 또는 백엔드 서버에서 수행됩니다.

UI에서 Trace 사용

참고: 이 섹션의 단계는 공개와 프라이빗 클라우드 사용자

  1. 문제가 계속 발생하면 UI에서 영향을 받은 API의 트레이스를 사용 설정합니다.
  2. 트레이스를 캡처한 후 응답 코드를 500입니다.
  3. 실패한 API 요청의 모든 단계를 살펴보고 어떤 단계가 반환되는지 확인 500 내부 서버 오류: <ph type="x-smartling-placeholder">
      </ph>
    1. 정책 실행 중에 오류가 발생하면 에지 정책의 실행 오류를 진행합니다.
    2. 백엔드 서버가 500개의 내부 서버로 응답한 경우 백엔드 서버에서 오류 발생을 진행합니다.

API 모니터링 사용

참고: 이 섹션의 단계는 퍼블릭 클라우드 사용자만 수행할 수 있습니다.

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

API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 살펴봅니다. 예를 들어 상태 코드 500개 또는 오류 steps.servicecallout.ExecutionFailed개가 특정 기준점을 초과할 때 알림을 받도록 알림을 설정할 수 있습니다.

NGINX 액세스 사용 로그

참고: 이 섹션의 단계는 Edge Private Cloud 사용자를 위한 것입니다. 전용입니다.

NGINX 액세스 로그를 참조하여 500 상태 코드가 발생했는지 확인할 수도 있습니다. 정책을 실행하는 동안에만 또는 백엔드 서버에서 수행됩니다. 이것은 이전에 문제가 발생했거나 문제가 간헐적으로 발생한 경우 특히 유용합니다. UI에서 트레이스를 캡처할 수 없습니다. 다음 단계에 따라 NGINX 액세스 로그:

  1. NGINX 액세스 로그 (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)를 확인합니다.
  2. 특정 IP 프록시에서 특정 API 프록시에 500 오류가 있는지 지정할 수 있습니다.
  3. 500 오류가 있는 경우 오류가 정책인지 대상 서버 오류인지 확인합니다. 다음과 같습니다.

    정책 오류를 보여주는 샘플 항목

    대상 서버 오류를 보여주는 샘플 항목

  4. 정책 오류인지 대상 서버 오류인지 확인한 후 다음을 수행합니다. <ph type="x-smartling-placeholder">
      </ph>
    1. 다음과 같은 경우 에지 정책의 실행 오류로 진행합니다. 정책 오류입니다.
    2. 대상인 경우 백엔드 서버에서 오류로 진행 서버 오류가 발생했습니다.