Edge UI에 캡처되지 않은 API 요청

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

증상

다음 이미지는 트레이스 세션이 시작될 때 Edge UI에서 API 요청이 캡처되지 않음을 보여줍니다.

오류 메시지

이 문제가 발생해도 Edge UI에 오류 메시지가 표시되지 않습니다.

가능한 원인

다음 표에서는 Edge UI Trace에서 API 요청을 캡처하지 못하는 가능한 원인을 보여줍니다.

원인: 메시지 프로세서가 처리하지 않는 요청

진단

Trace 세션에서 API 요청을 캡처하려면 Edge의 구성요소 메시지 프로세서에서 API 요청을 처리해야 합니다. Trace 트랜잭션에 API 요청이 캡처되지 않는 이유는 여러 가지가 있습니다.

예를 들어 API 요청이 Apigee Edge에 도달하지 못하면 Edge의 진입점에서 (즉, 라우터)에서 처리되거나 메시지 프로세서에 의해 처리되기 전에 실패하면 트레이스를 캡처할 수 없습니다. 이러한 각 시나리오는 아래에 더 자세히 설명되어 있습니다.

시나리오 1: 요청이 Apigee Edge에 도달하지 못함

• 원인

  이 시나리오에서는 DNS 변환 또는 네트워크 연결 문제로 인해 오류가 발생할 수 있습니다. 이 경우 이 명령어를 실행할 때 다음 오류가 표시될 수 있습니다.

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• 해상도

  다음 명령어를 사용하여 DNS 구성을 확인할 수 있습니다.

  dig hostName

  다음 명령어를 사용하여 네트워크 연결을 확인할 수 있습니다.

  telnet hostName port

시나리오 2: Apigee Edge 라우터에서 요청 실패

• 원인

  이 시나리오에서 오류는 TLS/SSL 핸드셰이크 실패로 인해 발생할 수 있습니다. 이 경우 다음 오류 중 하나가 표시될 수 있습니다.

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  SSL 인증서 오류가 표시될 수도 있습니다.

• 해상도

  다음 플레이북을 참고하여 문제를 해결하세요.

  TLS/SSL 핸드셰이크 실패

  400 잘못된 요청 - SSL 인증서 오류

시나리오 3: 메시지 프로세서에서 요청을 처리할 수 없음

• 원인

  이 시나리오에서는 Apigee 메시지 프로세서가 지정된 가상 호스트 및 경로를 사용합니다 그 결과, 다음 중 하나가 표시될 수 있습니다. 다음과 같은 오류가 발생할 수 있습니다.

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• 해상도

  이 문제를 해결하려면 404 cannot identifier for host(호스트용 프록시를 식별할 수 없음) 플레이북을 참조하세요.

원인: 분류 트리에서 API 프록시를 찾을 수 없음

진단

메시지 프로세서가 분류 트리에서 API 프록시를 찾을 수 없으면 해당 프록시에 대한 API 요청이 Edge UI의 추적 세션에 표시되지 않습니다.

이 경우에 해당하는지 확인하려면 다음 단계를 따르세요.

1. 각 메시지 프로세서에 로그인하고 다음 명령어를 사용하여 요청된 API의 특정 버전이 메시지 프로세서의 관련 환경에 배포되었는지 확인합니다.

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   출력 예시:

   위 명령어는 배포된 버전의 목록을 출력합니다. 예를 들어 버전 12가 배포되면 다음과 같은 출력이 표시됩니다.

   [ "12" ]
   

   간헐적인 HTTP 404 오류가 발생하지 않는 한 특정 버전이 배포되는 것을 볼 수 있습니다.

2. 분류 트리를 읽고 다음 명령어를 사용하여 API 프록시 이름이 있는지 확인합니다.

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. 각 메시지 프로세서에 대해 1단계와 2단계를 반복합니다. 지정된 API 프록시 이름이 메시지 프로세서의 분류 트리에서 누락된 경우 아래의 해결 방법을 따르세요.

해결 방법

이 문제를 해결하려면 다음 단계를 따르세요. 요청 로드가 많아서 메시지 프로세서를 다시 시작할 때 발생할 수 있는 프로덕션 중단을 방지하기 위해 필요한 모든 예방 조치를 취해야 합니다.

1. 분류 트리에서 특정 API 프록시가 누락된 각 메시지 프로세서 호스트에 로그인하고 아래 명령을 사용하여 메시지 프로세서를 다시 시작합니다.

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

2. 다시 시작하면 아래 명령어를 사용하여 활성화될 때까지 기다립니다.

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

3. 메시지 프로세서가 준비되면 다음 명령어를 사용하여 API 프록시의 사용 가능 여부를 확인합니다.

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   출력 예시:

   위 명령어는 배포된 버전의 목록을 출력합니다. 예를 들어 버전 12가 배포되면 다음과 같은 출력이 표시됩니다.

   [ "12" ]
   

   간헐적인 HTTP 404 오류가 발생하지 않는 한 특정 버전이 배포되는 것을 볼 수 있습니다.

4. 분류 트리를 읽고 다음 명령어를 사용하여 API 프록시 이름이 있는지 확인합니다.

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

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

진단 정보를 수집해야 함

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

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree