404 호스트의 프록시를 식별할 수 없습니다. <가상 호스트 이름> 및 url: <경로>

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

증상

클라이언트 애플리케이션은 API 호출에 대한 응답으로 Not Found 메시지와 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH 오류 메시지가 포함된 HTTP 상태 코드 404를 가져옵니다.

이 오류는 Edge가 지정된 가상 호스트 및 경로의 API 프록시를 찾을 수 없음을 의미합니다.

오류 메시지

다음과 같은 HTTP 상태 코드가 표시됩니다.

HTTP/1.1 404 Not Found

또한 아래와 비슷한 오류 메시지가 표시됩니다.

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

위의 오류 메시지는 Edge가 default 가상 호스트 및 /oauth2/token 경로의 API 프록시를 찾을 수 없음을 나타냅니다.

가능한 원인

이 오류가 발생하는 몇 가지 원인은 다음과 같습니다.

원인	설명	다음에 관한 문제 해결 안내
특정 가상 호스트와 연결되지 않은 API 프록시	특정 API 프록시가 오류 메시지에 지정된 가상 호스트에서 요청을 수락하도록 구성되지 않았습니다.	Edge 퍼블릭 및 프라이빗 클라우드 사용자
새로 배포된 API 프록시 버전에서 가상 호스트가 삭제됨	클라이언트가 특정 가상 호스트를 사용하는 동안 새로 배포된 버전에서 가상 호스트를 삭제하면 이 문제가 발생할 수 있습니다.	Edge 퍼블릭 및 프라이빗 클라우드 사용자
API 프록시와 연결되지 않은 경로	특정 API 프록시가 오류 메시지에 지정된 경로에서 요청을 수락하도록 구성되지 않았습니다.	Edge 퍼블릭 및 프라이빗 클라우드 사용자
API 프록시가 환경에 배포되지 않음	특정 API 프록시가 API 요청을 만들려는 특정 환경에 배포되지 않았습니다.	Edge 퍼블릭 및 프라이빗 클라우드 사용자
메시지 프로세서에 환경이 로드되지 않음	API 요청을 시도하는 특정 환경이 오류로 인해 메시지 프로세서에 로드되지 않았습니다.	Edge Private Cloud 사용자
API 프록시가 하나 이상의 메시지 프로세서에 배포되지 않음	배포 중 이벤트 알림이 누락되어 API 프록시가 하나 이상의 메시지 프로세서에 배포되지 않을 수 있습니다.	Edge Private Cloud 사용자

일반적인 진단 단계

NGINX 및 메시지 프로세서 로그는 404 오류를 해결하는 데 도움이 됩니다. 로그를 확인하려면 다음 단계를 따르세요.

1. 다음 명령어를 사용하여 NGINX 로그를 확인합니다.

   /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

2. 로그 항목에서 다음 필드를 확인합니다.

   필드	값
   Upstream_status, status	404
   X-Apigee-fault-code	messaging.adaptors.http.flow.ApplicationNotFound

   로그에서 메시지 ID를 기록해 둡니다.

3. 메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log))에서 특정 API에 messaging.adaptors.http.flow.ApplicationNotFound가 있는지 또는 API 요청에 2단계의 고유한 메시지 ID가 있는지 확인하세요.

   메시지 프로세서 로그의 오류 메시지 샘플

NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

위의 로그는 오류 코드와 오류 메시지를 다음과 같이 보여줍니다.

code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

원인: API 프록시가 특정 가상 호스트와 연결되지 않음

API 프록시가 특정 가상 호스트에 대한 요청을 수락하도록 구성되지 않은 경우 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. 오류 메시지와 함께 404 Not Found 응답을 받을 수 있습니다.

진단

1. API 프록시의 프록시 엔드포인트 구성을 확인하고 API 프록시가 오류에 지정된 가상 호스트에 대한 요청을 수락하도록 구성되어 있는지 확인합니다. VirtualHost 요소로 나타냅니다. 이해를 돕기 위해 샘플 ProxyEndpoint 구성을 살펴보겠습니다.

   API 프록시가 보안 가상 호스트에서 요청을 수락함을 보여주는 샘플 프록시 엔드포인트 구성

   

2. 가상 호스트가 특정 환경에서 다음과 같이 정의되었다고 가정해 보겠습니다.

   이름	포트	호스트 별칭
   default	80	myorg-prod.apigee.net
   secure	443	myorg-prod.apigee.net

3. URL http://myorg-prod.apigee.net/weather을 사용하여 default VirtualHost에 API를 요청합니다.
4. 위 예시와 같이 ProxyEndpoint에 default VirtualHost가 없으므로 다음과 같은 오류 메시지와 함께 404 응답 코드가 표시됩니다.

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

5. 이 문제를 해결하려면 아래의 해결 방법 섹션으로 이동하세요.
6. ProxyEndpoint가 default VirtualHost의 요청을 수락하도록 구성된 경우 다음 원인인 API 프록시와 연결되지 않은 경로로 이동합니다.

해상도

1. 누락된 VirtualHost를 ProxyEndpoint 구성에 추가하여 문제를 해결합니다. 위에 표시된 예에서는 다음과 같이 기본 VirtualHost를 ProxyEndpoint 구성에 추가할 수 있습니다.

   <VirtualHost>default</VirtualHost>

   기본값> VirtualHost>가 추가되었음을 보여주는 프록시 엔드포인트 구성 샘플

   

2. 또는 위 예시에서 이 특정 API 프록시에 secure VirtualHost만 사용하려는 경우 HTTPS 프로토콜을 사용하여 secure VirtualHost에만 API를 요청합니다.

   https://myorg-prod.apigee.net/weather

원인: 새로 배포된 API 프록시 버전에서 가상 호스트가 삭제됨

클라이언트가 API 요청을 하기 위해 계속 사용하고 있는 특정 가상 호스트(이전에 배포된 버전의 일부였음)를 삭제한 후 API 프록시의 새 버전이 배포되면 이 문제가 발생할 수 있습니다.

진단

1. API 프록시의 프록시 엔드포인트 구성에서 API 프록시가 오류에 지정된 가상 호스트에 대한 요청을 수락하도록 구성되어 있는지 확인합니다. 이는 ProxyEndpoint 구성의 VirtualHost 요소로 표시됩니다.
2. 오류에 지정된 가상 호스트가 ProxyEndpoint 구성에 없으면 다음 단계를 수행합니다. 그 외의 경우 다음 원인(API 프록시와 연결되지 않은 경로)으로 이동합니다.
3. 이전에 배포된 버전의 ProxyEndpoint 구성을 현재 배포된 버전과 비교합니다.
   1. 예를 들어 이전에 배포한 버전이 5이고 현재 배포된 버전이 6이라고 가정해 보겠습니다.
      • 버전 5의 프록시 엔드포인트에 구성된 가상 호스트

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>vh1</VirtualHost>
      </HTTPProxyConnection>
      

      • 버전 6의 프록시 엔드포인트에 구성된 가상 호스트

      <HTTPProxyConnection>
          <BasePath>/weather</BasePath>
          <Properties/>
          <VirtualHost>secure</VirtualHost>
      </HTTPProxyConnection>
      

   2. 위의 예에서 VirtualHost vh1는 revision 5,에 있었지만 revision 6에서 삭제되고 VirtualHost secure로 대체되었습니다.
   3. 따라서 개발자나 클라이언트가 VirtualHost vh1 (revision 5의 일부)를 사용하여 이 API 프록시에 요청하는 경우 다음과 같은 오류 메시지와 함께 404 응답 코드가 표시됩니다.

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

4. 현재 배포된 버전에서 가상 호스트가 의도적으로 또는 의도적으로 변경되었는지 확인하고 해결 섹션에 설명된 대로 적절한 조치를 취합니다.

해상도

새 버전에서 가상 호스트가 삭제된 것을 확인했다면 삭제가 의도된 것이거나 실수로 삭제되었을 수 있습니다. 각 케이스에 대해 다음 해결 방법/권장 단계를 수행하여 문제를 해결하세요.

시나리오 #1: 의도적인 변경

가상 호스트를 의도적으로 삭제하는 경우 다음 옵션 중 하나를 선택할 수 있으며 첫 번째 옵션이 권장되는 방법입니다.

1. 다른 기본 경로로 새 프록시를 만들고 이전에 배포된 버전에 없는 다른 가상 호스트를 사용합니다.

2. 기존 API 프록시는 계속 사용하지만 다른 가상 호스트를 사용하려면 기존 가상 호스트를 유지하고 가상 호스트를 추가하는 것이 좋습니다.

   이렇게 하면 이 API 프록시의 사용자가 변경사항의 영향을 받지 않습니다.

3. 기존 API 프록시를 사용하고 다른 가상 호스트만 사용하려면 사용자에게 미리 알리고 유지보수 기간 동안 이 변경을 수행합니다.

   이렇게 하면 이 API 프록시의 사용자가 변경사항을 인지하고 다른 가상 호스트를 사용하여 이 API 프록시를 호출할 수 있습니다. 따라서 변경의 영향을 받지 않습니다.

시나리오 #2: 의도치 않은 변경

가상 호스트가 의도치 않게 실수로 삭제된 경우 다음 단계를 따르세요.

1. 이전에 배포된 버전에서 사용된 것과 동일한 가상 호스트를 사용하도록 현재 배포된 버전의 ProxyEndpoint 구성을 업데이트합니다. 위 예에서 다음 섹션을

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>secure</VirtualHost>
   </HTTPProxyConnection>
   

   에서 변경합니다.

   to

   <HTTPProxyConnection>
       <BasePath>/weather</BasePath>
       <Properties/>
       <VirtualHost>vh1</VirtualHost>
   </HTTPProxyConnection>
   

2. 버전을 다시 배포합니다.

권장사항

배포 중에 발생하는 문제를 피하거나 트래픽에 미치는 영향을 최소화할 수 있도록 유지보수 기간 중이나 트래픽이 최소한으로 예상되는 시점에 새 프록시나 새 버전을 배포하는 것이 좋습니다.

원인: 경로가 API 프록시와 연결되지 않음

API 프록시가 API 요청 URL에 사용된 특정 경로에 대한 요청을 수락하도록 구성되지 않은 경우 Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. 오류 메시지와 함께 404 Not Found 응답을 가져올 수 있습니다.

진단

1. API 요청을 사용하려는 특정 API 프록시의 ProxyEndpoint 구성을 확인합니다.
2. 오류 메시지에 표시된 특정 경로에 대한 요청을 수락하도록 API 프록시가 구성되었는지 확인합니다. 시나리오 1 및 시나리오 2의 단계를 수행하면 됩니다.

시나리오 #1: 경로가 API 프록시의 기본 경로와 일치하지 않음

1. 오류 메시지에 표시된 path가 특정 API 프록시의 basepath와 같지 않거나 basepath로 시작하지 않는 경우 이로 인해 오류가 발생했을 수 있습니다.
2. 이해를 돕기 위해 예를 들어 보겠습니다.
1. 원하는 API 프록시의 basepath은(는) /weather입니다.
2. API 요청 URL은 https://myorg-prod.apigee.net/climate입니다. 즉, API 요청 URL에 사용되는 경로는 /climate.입니다.
3. 이 예에서 path는 basepath와 동일하지 않으며 basepath로 시작하지 않습니다. 따라서 다음 오류가 발생합니다.

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

해상도

1. API 요청 URL에 사용된 path가 특정 API 프록시의 basepath와 동일한지 확인합니다.
2. 위의 예에서 API 요청 URL은 다음과 같아야 합니다.

   {
   https://myorg-prod.apigee.net/weather
   

시나리오 #2: 경로가 사용 가능한 조건부 흐름과 일치하지 않음

1. API 요청 URL에 사용된 path가 basepath로 시작하면 오류 메시지에 표시된 path suffix (basepath 다음에 오는 부분)가 조건부 흐름과 일치하지 않아 404 오류가 발생할 수 있습니다.
2. 이 문제를 설명하는 예를 살펴보겠습니다.
   1. 원하는 API 프록시의 basepath은(는) /weather입니다.
   2. API 요청 URL은 https://myorg-prod.apigee.net/weather/Delhi입니다. 즉, API 요청 URL에 사용되는 경로는 /weather/Delhi.입니다.
3. 이 예에서 path는 basepath /weather로 시작합니다. 또한 path suffix가 /Delhi입니다.
4. 이제 ProxyEndpoint에 조건부 흐름이 있는지 확인합니다.
5. 조건부 흐름이 없거나 몇 개의 비조건부 흐름이 있는 경우 다음 원인인 환경에 배포되지 않은 API 프록시로 이동합니다.
6. ProxyEndpoint에 조건부 흐름만 있는 경우 다음을 확인합니다.
   1. 이러한 모든 조건부 흐름의 조건이 특정 proxy.pathsuffix(기본 경로 뒤의 경로)를 확인하는 경우
   2. API 요청 URL에 지정된 path suffix가 어떤 조건과도 일치하지 않으면 오류의 원인입니다.
7. ProxyEndpoint에 두 개의 흐름이 있고 둘 다 아래와 같이 조건부 흐름이라고 가정해 보겠습니다.

   <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>
   
   <Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
   

   1. 위의 예에는 두 개의 조건부 흐름이 있습니다. 하나는 proxy.pathsuffix (기본 경로 뒤의 경로)와 /Bangalore과 일치하고 다른 하나는 /Chennai와 일치합니다. 하지만 API 요청 URL에 전달된 path suffix인 /Delhi와 일치하는 항목이 없습니다.
   2. 404 오류가 발생한 원인입니다. 따라서

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

      오류가 발생합니다.

해상도

1. path suffix이 프록시 엔드포인트의 조건부 흐름 중 하나 이상과 일치하는지 확인합니다.
2. 위의 예에서 다음 방법을 사용하여 오류를 해결할 수 있습니다.
   1. /Delhi 경로에 특정 정책 집합을 실행하려면 필수 정책 집합이 포함된 별도의 흐름을 추가하고 아래와 같이 /proxy.pathsuffix /Delhi와 일치하는 조건이 있는지 확인합니다.

      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>

   2. /Delhi 경로에 공통 정책 세트를 실행하려면 공통 흐름에서 일반 /proxy.pathsuffix를 허용하는 조건이 있는지 확인합니다. 즉, 아래와 같이 basepath /weather 뒤의 모든 경로를 허용합니다.

      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

ProxyEndpoint에 올바른 basepath가 있고 API URL에 지정된 path suffix가 조건부 흐름 중 하나와 일치하면 다음 원인인 API 프록시가 환경에 배포되지 않음으로 이동합니다.

원인: API 프록시가 환경에 배포되지 않음

진단

1. API 요청 URL에 사용되는 호스트 별칭이 있는 환경을 확인합니다. Edge UI에서 조직의 각 환경에 있는 모든 가상 호스트의 세부정보를 확인하면 됩니다.

   예를 들어 다음 구성을 가정해 보겠습니다.

   • URL이 http://myorg-prod.apigee.net/weather이면 myorg-prod.apigee.net이 호스트 별칭입니다.
   • 호스트 별칭 myorg-prod.apigee.net은 조직의 prod 환경에 있는 가상 호스트 중 하나의 일부로 구성됩니다.
2. 특정 API 프록시가 위의 1단계에서 결정된 특정 환경에 배포되었는지 확인합니다.
3. API 프록시가 특정 환경에 배포되지 않은 경우 404 오류가 발생합니다.
   1. 따라서 위의 1단계에서 사용된 예시에서 API 프록시가 prod 환경에 배포되지 않았다고 가정해 보겠습니다. 이 때문에 오류가 발생합니다.
   2. 아래의 해결 방법 섹션으로 이동합니다.
4. API 프록시가 특정 환경에 배포된 경우 다음 원인인 메시지 프로세서에 로드되지 않은 환경으로 이동합니다.

해상도

API 요청을 하려는 특정 환경에 API 프록시를 배포합니다.

원인: 메시지 프로세서에 환경이 로드되지 않았습니다.

진단

1. 각 메시지 프로세서에 로그인하고 API 요청을 하는 특정 환경이 다음 명령어를 사용하여 메시지 프로세서에 로드되는지 확인합니다.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

2. 특정 환경이 위 명령어의 일부로 나열되어 있으면 다음 원인인 API 프록시가 하나 이상의 메시지 프로세서에 배포되지 않음으로 이동합니다.
3. 특정 환경이 나열되지 않으면 메시지 프로세서의 /opt/apigee/var/log/edge-message-processor/logs/system.log 및 /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log에서 환경을 로드하는 중에 오류가 있는지 확인합니다.
4. 다양한 오류가 발생하여 메시지 프로세서에 환경을 로드하지 못할 수 있습니다. 해결 방법은 발생한 오류에 따라 다릅니다.

해상도

여러 가지 이유로 메시지 프로세서에 환경이 로드되지 않을 수 있습니다. 이 섹션에서는 이 문제를 일으킬 수 있는 몇 가지 이유와 문제 해결 방법을 설명합니다.

1. 메시지 프로세서 로그에 다음 오류 중 하나가 표시되는 경우 지정된 환경의 지정된 키 저장소/트러스트 저장소에 추가된 인증서/키에서 발견된 문제가 있기 때문입니다.

   오류 #1: java.security.KeyStoreException: Cannot override own certificate

   2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
   at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
   …
   Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   

   ... 20 common frames omitted

   2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
   

   오류 #2: java.security.KeyStoreException: 보안 비밀 키를 덮어쓸 수 없음

   2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
   com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
   at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
   ...
   Caused by: java.security.KeyStoreException: Cannot overwrite secret key
   at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
   at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
   at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
   ... 20 common frames omitted
   
   2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

2. 다음 관리 API 호출을 사용하여 이전 단계에 표시된 오류 메시지에 지정된 키 저장소/truststore의 세부정보를 가져옵니다.

   curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user> 

   
   

   출력 예시:

   {
      "certs":[
         "mycert",
         "mycert-new"
      ],
      "keys":[
         "mycert"
      ],
      "name":"myTruststore"
   }
   

3. 출력 예시는 트러스트 저장소 myTruststore에 두 개의 인증서와 하나의 키가 있음을 보여줍니다. 트러스트 저장소에는 일반적으로 키가 포함되어 있지 않습니다. 가능하다면 단일 인증서와 단일 키를 사용하는 것이 좋습니다.
4. 다음 API를 사용하여 두 인증서에 대한 세부정보를 가져옵니다.

   curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
   

5. 각 인증서의 만료일을 확인하고 만료되었거나 오래된 인증서를 확인합니다.
6. myTruststore 트러스트에서 만료되었거나 원치 않는 인증서를 삭제합니다.

문제가 계속 발생하거나 위의 1단계에 언급된 것 이외의 오류가 발생하면 진단 정보를 수집해야 함으로 이동하세요.

원인: API 프록시가 하나 이상의 메시지 프로세서에 배포되지 않음

API 프록시는 하나 이상의 메시지 프로세서에 배포되지 않을 수 있습니다. 이 문제는 매우 드물게 발생하며 대부분 특정 API 프록시를 배포하는 동안 관리 서버에서 메시지 프로세서로 보내는 이벤트 알림이 누락되었기 때문에 발생합니다. 이 경우에도 Edge UI에서 트레이스 세션을 만들 수 없습니다.

진단

1. 각 메시지 프로세서에 로그인하고 다음 명령어를 사용하여 특정 버전의 API 프록시가 배포되었는지 확인합니다.

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
   

2. API 프록시의 특정 버전이 위의 1단계에 언급된 명령어의 출력으로 표시되지 않으면 해결에 설명된 대로 특정 메시지 프로세서를 다시 시작합니다.
3. 모든 메시지 프로세서에 1~2단계를 반복합니다.
4. 특정 버전의 API 프록시가 모든 메시지 프로세서에 배포되는 경우 이로 인해 문제가 발생하지 않습니다. 진단 정보를 수집해야 함을 참고하세요.

해상도

특정 버전의 API 프록시가 배포되지 않은 특정 메시지 프로세서를 다시 시작합니다.

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

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

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

이 문제의 경우 API 모니터링 > 조사 페이지로 이동하여 적절한 날짜, 프록시 등을 선택하면 다음과 같은 세부정보가 표시될 수 있습니다.

• 오류 코드: messaging.adaptors.http.flow.ApplicationNotFound
• 상태 코드: 404
• 결함 소스: Apigee 또는 MP

또한 위 스크린샷과 같이 로그 보기를 클릭하여 추가로 확인할 수 있습니다.

샘플 시나리오 살펴보기에서는 API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여줍니다. 예를 들어 404 상태 코드 수가 특정 임곗값을 초과하면 알림을 받도록 알림을 설정할 수 있습니다.

진단 정보 수집 필요

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

1. 퍼블릭 클라우드 사용자인 경우 다음 정보를 제공하세요.
   • 조직 이름
   • 환경 이름
   • API 프록시 이름
   • curl 명령어를 완료하여 오류를 재현하세요.
2. Private Cloud 사용자인 경우 다음 정보를 제공하세요.
   • 전체 오류 메시지가 관찰됨
   • 환경 이름
   • API 프록시 번들
   • 메시지 프로세서 로그 /opt/apigee/var/log/edge-message-processor/logs/system.log
   • 각 메시지 프로세서에 대한 다음 명령어의 출력

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments

   curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
         

3. 이 플레이북에서 시도해 본 섹션 및 이 문제를 빠르게 해결하는 데 도움이 될 기타 유용한 정보에 대한 세부정보입니다.