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

500 내부 서버 오류 - 스트리밍 사용

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

증상

클라이언트 애플리케이션이 HTTP 응답 상태 코드 500을 수신합니다. API 호출에 대한 내부 서버 오류 메시지

오류 메시지

클라이언트 애플리케이션에서 다음과 같은 오류 응답을 받을 수 있습니다.

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "faultstring":"Expecting } at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

OR

{
   "fault":{
      "faultstring":"Expecting ] at line 1"
      "detail":{
         "errorcode":"Internal Server Error"
      }
   }
}

가능한 원인

500 내부 서버 오류는 여러 가지 이유로 발생할 수 있습니다. 플레이북 요청/응답 액세스로 인해 발생한 500 내부 서버 오류에 집중합니다. 스트리밍 중 사용 설정되어 있는지 확인합니다.

원인	설명	문제 해결 단계를 수행할 수 있는 사용자
다음을 사용하여 페이로드 액세스 스트리밍 사용 설정됨	스트리밍이 사용 설정된 상태에서 요청/응답 페이로드에 액세스했기 때문에 오류가 발생했습니다.	Edge 프라이빗 및 퍼블릭 클라우드 사용자

원인: 스트리밍이 사용 설정된 페이로드 액세스

진단

절차 #1: Trace 사용

trace 사용 설정 세션으로 돌아가 API를 호출하여 문제(500 내부 서버 오류)를 재현합니다.
실패한 요청 중 하나를 선택하고 trace를 검토합니다.
추적의 다양한 단계를 살펴보고 오류가 발생한 위치를 찾습니다.
정책에서 요청/응답 페이로드를 파싱하는 중에 이 오류가 발생했을 수 있습니다.
다음은 JSONThreatProtection'을 보여주는 샘플 트레이스 스크린샷입니다. 정책 오류와 함께 실패 'Expecting } at line 1':

위와 같이 트레이스 출력에서 다음 정보를 기록해 둡니다. 스크린샷:

실패 정책: JSONThreatProtection

흐름: 프록시 요청

실패한 정책 정의를 검토하고 파싱 중인 페이로드를 확인합니다.

예제 시나리오에서는 JSON-Threat-Protection이 실패하여 <Source> 요소를 확인합니다.

<JSONThreatProtection async="false" continueOnError="false" enabled="true" name="JSON-Threat-Protection">
   <DisplayName>JSON Threat Protection</DisplayName>
   <ArrayElementCount>20</ArrayElementCount>
   <ContainerDepth>10</ContainerDepth>
   <ObjectEntryCount>15</ObjectEntryCount>
   <ObjectEntryNameLength>50</ObjectEntryNameLength>
   <Source>request</Source>
   <StringValueLength>1000</StringValueLength>
</JSONThreatProtection>

<Source> 요소가 request.를 가리킵니다. 즉, 요청 페이로드를 파싱하는 동안 오류가 발생했습니다.

API 요청을 확인하여 파싱되는 페이로드의 유형을 확인합니다.

요청 페이로드 및 Content-Type 헤더의 내용은 다음에서 확인할 수 있습니다. API 요청에 대응합니다 다음 curl 명령어 예에서는 JSON 페이로드가 사용됩니다.

curl -i https://VIRTUAL_HOST_ALIAS/BASEPATH -H "Content-Type: application/json" \
-X POST -d @request-payload.json

또한 실패하는 정책을 확인하고 사용 중인 페이로드의 유형을 확인할 수 있습니다. 파싱할 수 있습니다. 위의 예시 시나리오에서는 JSON-Threat-Protection 정책이 실패합니다. 이는 페이로드가 JSON 형식이어야 함을 나타냅니다.

페이로드가 올바른 형식인지 확인합니다. 페이로드가 유효하지 않으면 이 오류가 발생할 수 있습니다.

참고: 페이로드가 큰 경우 온라인 형식 지정 도구를 사용하여 형식일 수도 있습니다.
페이로드가 유효하지만 오류 메시지 섹션에 표시된 오류의 원인을 찾으세요. 스트리밍이 활성화될 때 페이로드에 액세스한다는 것입니다.

(6단계에서 결정된 대로) 정책에 의해 파싱되는 페이로드에 따라 적절한 단계에서 Trace 도구의 페이로드 콘텐츠를 검사합니다.

예시 시나리오에서는 요청 페이로드가 파싱되고 있으므로 'Request Received from Client'(클라이언트에서 수신된 요청) 단계를 확인하고 콘텐츠 요청.

위 스크린샷과 같이 요청 콘텐츠가 비어 있는 것으로 확인되면 유효한 페이로드를 보냈다면 이 문제의 가능한 원인은 요청 스트리밍이 사용 설정됩니다

스트리밍이 사용 설정되면 요청 페이로드가 trace에 표시되지 않기 때문입니다.

마찬가지로 오류 발생 시 응답 페이로드가 파싱되는 경우 '대상 서버에서 응답 수신됨' 단계에 있는 응답 콘텐츠를 확인하시기 바랍니다.
다음으로, 장애가 발생한 위치에 따라 프록시 및 대상 엔드포인트 정의를 검사합니다. 정책은 API 프록시 흐름에서 사용됩니다. 스트리밍이 사용 설정되었는지 확인합니다.

예시 시나리오에서는 실패한 정책이 프록시 요청 흐름에서 실행되었습니다. (위의 5단계에서 결정됨) 프록시 엔드포인트를 검사합니다.
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
    <Properties>
      <Property name="response.streaming.enabled">true</Property>
      <Property name="request.streaming.enabled">true</Property>
    </Properties>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
위의 예에서 볼 수 있듯이, 요청 스트리밍이 "request.streaming.enabled" 속성을 true로 설정합니다.

따라서 오류의 원인은 API 프록시에서 JSONThreatProtection 정책을 사용하는 것입니다. 스트리밍이 사용 설정되었을 때 요청 페이로드에 액세스하는 이로 인해 오류가 발생합니다. API 프록시에서 버퍼링을 트리거하고 Apigee Edge에서 스트리밍을 사용하는 목적을 무효화합니다.

이 오류는 작은 페이로드에서는 발견되지 않을 수 있지만 더 큰 페이로드를 사용하면 볼 수 있습니다.
값을 확인하여 500 오류가 정책으로 인한 것인지 확인할 수 있습니다. "X-Apigee-fault-source" 중 (애널리틱스 데이터 기록됨) 아래의 단계에 따라 트레이스를 진행합니다. <ph type="x-smartling-placeholder">
1. 'AX' (애널리틱스 데이터 기록됨) 단계 클릭 아래 스크린샷과 같이 작동합니다.
2. 단계 세부정보에서 'Error Headers'(오류 헤더)가 보일 때까지 아래로 스크롤합니다. 섹션과 'X-Apigee-fault-code'의 값을 결정합니다. "X-Apigee-fault-source" 및 'X-Apigee-fault-policy' 아래에서 바와 같이 변경할 수 있습니다.
3. "X-Apigee-fault-source" 값이 'policy'인 경우 아래와 같이 를 사용할 수 없다면 페이로드를 전송합니다.

해상도

스트리밍이 사용 설정된 상태에서 페이로드에 액세스하는 것은 피해야 할 패턴: 스트리밍이 사용 설정된 경우 요청/응답 페이로드에 액세스합니다.

페이로드를 처리하려면 프록시/타겟에서 스트리밍을 사용 중지해야 합니다. 아래 ProxyEndpoint 예와 같이 "request.streaming.enabled" and "response.streaming.enabled" 속성을 삭제하여 엔드포인트를 생성합니다.
```
<ProxyEndpoint name="default">
...
  <HTTPProxyConnection>
    <BasePath>/v1/weather</BasePath>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
</ProxyEndpoint>
```
또는
API 프록시에 스트리밍을 사용하려는 경우 요청/응답 페이로드에 액세스하는 API 프록시입니다.

참고:

이 플레이북에서는 JSONThreatProtection 정책을 사용하여 사용 설정되어 있어야 합니다. 이로 인해 다른 오류와 함께 500 내부 서버 오류가 발생했습니다.
이러한 오류는 JSONToXML 및 XMLToJSON과 같은 정책에서도 볼 수 있습니다. 요청 또는 응답 페이로드를 포함하는 것이 좋습니다.
페이로드의 총 개수를 알 수 있습니다.
이렇게 하는 것은 피해야 할 패턴: 스트리밍이 사용 설정된 경우 요청/응답 페이로드에 액세스합니다.

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

프라이빗 클라우드 사용자는 이 절차를 건너뜁니다.

API 모니터링을 사용하면 문제 영역을 빠르게 격리하여 오류, 성능, 지연 시간 문제와 그 원인(예: 개발자 앱, API 프록시, 백엔드 대상 또는 API 플랫폼)을 진단할 수 있습니다.

API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 살펴봅니다. 예를 들어 오류 500개가 특정 기준을 초과하면 알림이 전송되도록 설정할 수 있습니다.

정책에서 500 오류 응답이 발생할 때 알림을 받으려면 결함 소스를 프록시로 하여 500 상태 코드 알림을 설정해야 합니다.

진단 정보 수집 필요

위의 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집하세요. Apigee 지원팀에 문의하여 공유하세요.

퍼블릭 클라우드 사용자는 다음 정보를 제공하세요.

조직 이름
환경 이름
API 프록시 이름
요청 페이로드 (있는 경우)와 함께 curl 명령어를 완료하여 500 오류를 재현합니다.
500 내부 서버 오류가 있는 요청이 포함된 추적 파일
현재 500 오류가 발생하지 않고 있다면 과거에 500 오류가 발생했을 때의 시간대 정보와 함께 해당 기간을 제공합니다.

프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요.

실패한 요청에 대해 발견된 전체 오류 메시지
500 오류가 관찰된 조직, 환경 이름, API 프록시 이름
API 프록시 번들
요청에 사용된 페이로드 (있는 경우)
500 내부 서버 오류가 있는 요청이 포함된 추적 파일
NGINX 액세스 로그 (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)
500 오류가 발생했을 때의 시간대 정보가 포함된 기간입니다.