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

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

증상

클라이언트 애플리케이션이 다음 메시지와 함께 HTTP 상태 코드 404를 가져옵니다. Not Found 및 오류 메시지 <ph type="x-smartling-placeholder">Unable to identify proxy for host: VIRTUAL_HOST and url: PATH</ph> API 호출에 대한 응답으로 제공합니다.

이 오류는 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 경로

가능한 원인

이 오류가 발생할 수 있는 원인은 다음과 같습니다.

원인 설명 다음에 관한 문제 해결 안내
<ph type="x-smartling-placeholder"></ph> 특정 가상 호스트에 연결되지 않은 API 프록시 특정 API 프록시가 가상 호스트에서 요청을 수락하도록 구성되어 있지 않습니다. 오류 메시지에 지정된 모든 URL을 반환합니다. 에지 퍼블릭 및 프라이빗 클라우드 사용자
새로 배포된 API 프록시 버전에서 가상 호스트가 삭제됨 클라이언트가 아직 있는 동안 새로 배포된 버전에서 가상 호스트 삭제 이 문제가 발생할 수 있습니다 에지 퍼블릭 및 프라이빗 클라우드 사용자
<ph type="x-smartling-placeholder"></ph> 경로가 API 프록시와 연결되지 않음 특정 API 프록시가 지정된 경로에서 요청을 수락하도록 구성되지 않았습니다. 표시됩니다. 에지 퍼블릭 및 프라이빗 클라우드 사용자
<ph type="x-smartling-placeholder"></ph> API 프록시가 환경에 배포되지 않음 특정 API 프록시가 현재 위치한 특정 환경에 배포되지 않은 경우 API 요청을 만들려고 합니다 에지 퍼블릭 및 프라이빗 클라우드 사용자
<ph type="x-smartling-placeholder"></ph> 메시지 프로세서에 로드되지 않은 환경 API 요청을 하려고 시도하는 특정 환경이 로드되었을 수 있습니다. Edge 프라이빗 클라우드 사용자
<ph type="x-smartling-placeholder"></ph> API 프록시가 하나 이상의 메시지 프로세서에 배포되지 않음 누락으로 인해 하나 이상의 메시지 프로세서에 API 프록시를 배포할 수 없습니다. 이벤트 알림을 사용할 수 있습니다. Edge 프라이빗 클라우드 사용자

일반적인 진단 단계

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입니다.

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

    4. 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 프록시가 특정 가상 호스트에 대한 요청을 수락하도록 구성되지 않은 경우 오류 메시지가 포함된 404 Not Found 응답을 받을 수 있습니다. Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

진단

  1. API 프록시에 대한 프록시 엔드포인트 구성을 확인하고 API 프록시가 오류에 지정된 가상 호스트에 대한 요청을 수락하도록 구성된 가상 머신입니다 이것은 VirtualHost 요소로 표현됩니다. 샘플 ProxyEndpoint 살펴보기 이해하는 것이 중요합니다

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

  2. 가상 호스트가 다음과 같이 특정 환경에서 정의되었다고 가정해 보겠습니다.
    이름 포트 호스트 별칭
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. URL을 사용하여 default VirtualHost에 API를 요청합니다. <ph type="x-smartling-placeholder">http://myorg-prod.apigee.net/weather</ph>
  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님, 다음 활동으로 이동하세요. <ph type="x-smartling-placeholder"></ph> 경로가 API 프록시와 연결되지 않음

해상도

  1. 누락된 VirtualHost를 ProxyEndpoint 구성에 추가하여 해결할 수 있습니다 위의 예에서는 기본 VirtualHost를 추가할 수 있습니다. 다음과 같이 ProxyEndpoint 구성에 추가합니다. <ph type="x-smartling-placeholder"> 
    <VirtualHost>default</VirtualHost>
    </ph>

    기본값을 보여주는 샘플 프록시 엔드포인트 구성> VirtualHost&gt; 추가 예정

  2. 또는 위에 언급된 예에서 secure VirtualHost: 이 특정 API 프록시에 대해 수행된 후 API 요청을 실행합니다. HTTPS 프로토콜을 사용하여 secure VirtualHost에만 연결할 수 있습니다. <ph type="x-smartling-placeholder">
    https://myorg-prod.apigee.net/weather
    </ph>

원인: 새로 배포된 API 프록시 버전에서 가상 호스트가 삭제되었습니다.

특정 가상 호스트를 삭제한 후 API 프록시의 새 버전이 배포되는 경우 (이전에 배포된 버전의 일부였으며), 클라이언트에서 계속 사용 중입니다. 사용할 수 없다면 이 문제가 발생할 수 있습니다

진단

  1. API 프록시에 대한 프록시 엔드포인트 구성에서 API 프록시가 오류에 지정된 가상 호스트에 대한 요청을 수락하도록 구성된 가상 머신입니다 이것은 ProxyEndpoint 구성의 VirtualHost 요소로 표현됩니다.
  2. 오류에 지정된 가상 호스트가 ProxyEndpoint에 없는 경우 다음 단계를 수행합니다. 그렇지 않은 경우 다음 원인으로 이동하세요. 경로가 API 프록시와 연결되지 않음
  3. 이전에 배포된 버전의 ProxyEndpoint 구성을 현재 구성과 비교합니다. 배포할 수 있습니다
    1. 예를 들어 이전에 배포한 버전이 5이고 현재 배포된 버전은 6입니다. <ph type="x-smartling-placeholder">
        </ph>
      • 버전 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의 일부) 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을 제공하면 오류 메시지가 포함된 404 Not Found 응답을 받을 수 있습니다. Unable to identify proxy for host: VIRTUAL_HOST and url: PATH.

진단

  1. 원하는 특정 API 프록시의 ProxyEndpoint 구성을 확인합니다. API 요청을 보낼 수 있습니다
  2. 표시된 특정 경로에 대한 요청을 수락하도록 API 프록시가 구성되어 있는지 확인합니다. 표시됩니다. 이렇게 하려면 시나리오 #1 시나리오 #2.

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

  1. 오류 메시지에 표시된 path가 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가 basepath와 동일한지 확인합니다. 지정할 수 있습니다
  2. 위의 예에서 API 요청 URL은 다음과 같아야 합니다. 
    {
https://myorg-prod.apigee.net/weather

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

  1. API 요청 URL에서 사용되는 path가 basepath로 시작하는 경우 path suffix( basepath)이 조건부 함수 중 하나와 일치하지 않습니다. 404 오류가 발생할 수 있습니다.
  2. 다음 예를 통해 설명해 드리겠습니다. <ph type="x-smartling-placeholder">
      </ph>
    1. 원하는 API 프록시의 basepath는 /weather입니다.
    2. API 요청 URL은 https://myorg-prod.apigee.net/weather/Delhi입니다. 다시 말해 API 요청 URL에 사용되는 경로는 /weather/Delhi.입니다.
  3. 이 예에서 path는 basepath /weather로 시작합니다. 또한 /Delhi의 path suffix가 있습니다.
  4. 이제 ProxyEndpoint에 조건부 흐름이 있는지 확인합니다.
  5. 조건부 흐름이 없거나 비조건부 흐름이 몇 개 있는 경우 다음 원인 - 환경에 배포되지 않은 API 프록시.
  6. ProxyEndpoint에 조건부 흐름만 있는 경우 다음을 확인합니다. <ph type="x-smartling-placeholder">
      </ph>
    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>
    <ph type="x-smartling-placeholder">
      </ph>
    1. 위의 예에는 두 개의 조건부 흐름이 있는데, /Bangalore에 대한 proxy.pathsuffix (기본 경로 뒤의 경로) 및 다른 하나는 /Chennai과(와) 일치합니다. 하지만 /Delhi과(와) 일치하는 항목이 없습니다. API 요청 URL에서 전달된 path suffix입니다.
    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. 위의 예에서는 다음 방법을 사용하여 오류를 해결할 수 있습니다. <ph type="x-smartling-placeholder">
      </ph>
    1. /Delhi 경로에 특정 정책 집합을 실행하려면 다음 안내를 따르세요. 필요한 정책 모음이 포함된 별도의 흐름을 추가하고 다음과 같이 /proxy.pathsuffix /Delhi와 일치하는 항목을 찾습니다. <ph type="x-smartling-placeholder"> 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
      </ph>
    2. /Delhi 경로에 공통 정책 집합을 실행하려면 일반적인 흐름에 대해 일반적인 /proxy.pathsuffix 즉, basepath 이후의 모든 경로를 허용합니다. /weather: <ph type="x-smartling-placeholder">
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>
      </ph>

ProxyEndpoint에 올바른 basepath 및 API URL에 지정된 path suffix가 있는 경우 조건부 흐름 중 하나와 일치하는 경우 다음 원인으로 넘어갑니다. API 프록시가 환경에 배포되지 않았습니다.

원인: API 프록시가 환경에 배포되지 않았습니다.

진단

  1. API 요청 URL에 사용된 호스트 별칭이 있는 환경을 확인합니다. 이를 위해서는 각 환경의 모든 가상 호스트의 세부정보를 확인하면 됩니다. 조직의 액세스 권한을 변경할 수 있습니다

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

    • 만약 http://myorg-prod.apigee.net/weather 가 URL이면 myorg-prod.apigee.net은 호스트 별칭입니다.
    • 호스트 별칭 myorg-prod.apigee.net은 조직의 prod 환경에 있는 가상 호스트
  2. 특정 API 프록시가 참조하세요.
  3. API 프록시가 특정 환경에 배포되지 않은 경우 404 오류를 반환합니다.
    1. 따라서 위의 1단계에서 사용한 예에서 API 프록시가 prod 환경에 있는 경우 이 때문에 오류의 원인이 됩니다.
    2. 아래의 해결 방법 섹션으로 이동합니다.
  4. API 프록시가 특정 환경에 배포된 경우 다음 원인으로 이동합니다. <ph type="x-smartling-placeholder"></ph> 환경이 메시지 프로세서에 로드되지 않았습니다.

해상도

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

원인: 메시지 프로세서에 환경이 로드되지 않음

진단

  1. 각 메시지 프로세서에 로그인하여 메시지 프로세서가 사용 설정된 특정 환경이 다음 명령을 사용하여 API 요청이 메시지 프로세서에 로드되도록 합니다. 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. 특정 환경이 위 명령어의 일부로 나열되어 있으면 다음 원인으로 이동합니다. <ph type="x-smartling-placeholder"></ph> API 프록시가 하나 이상의 메시지 프로세서에 배포되지 않았습니다.
  3. 특정 환경이 목록에 없는 경우 /opt/apigee/var/log/edge-message-processor/logs/system.log 및 /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log, 환경 로드 중 발생하는 오류에 대한 메시지 프로세서
  4. Google Compute Engine에서 환경을 로드하는 데 실패할 수 있는 메시지 프로세서의 일종입니다. 해결 방법은 발생한 오류에 따라 다릅니다.

해상도

여러 가지 이유로 환경이 메시지 프로세서에 로드되지 않을 수 있습니다. 이 섹션 이 문제가 발생할 수 있는 몇 가지 원인을 설명하고 해결 방법을 설명합니다. 있습니다.

  1. 메시지 프로세서 로그에 다음 오류 중 하나가 표시되면 지정된 keystore/truststore에 추가된 인증서/키에서 문제가 발견됨 포드로 라우팅됩니다

    오류 #1: java.security.KeyStoreException: 소유한 인증서를 덮어쓸 수 없음

    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. 다음에 표시된 오류 메시지에 지정된 keystore/truststore의 세부정보를 가져옵니다. 이전 단계에서 다음과 같은 관리 API 호출을 사용합니다. 
    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. 출력 예는 truststore에 두 개의 인증서와 키가 있음을 보여줍니다. 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 프록시의 특정 버전이 명령어의 출력으로 표시되지 않는 경우 특정 메시지 프로세서를 다시 시작할 수 있습니다. 해결 방법.
  3. 모든 메시지 프로세서에 대해 1~2단계를 반복합니다.
  4. API 프록시의 특정 버전이 모든 메시지 프로세서에 배포되면 이는 문제의 원인이 아닙니다. <ph type="x-smartling-placeholder"></ph>(으)로 이동 진단 정보를 수집해야 합니다.

해상도

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

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

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

API 모니터링으로 문제 영역을 빠르게 격리 오류, 성능, 지연 시간 문제와 그 원인을 진단하는 데 API 프록시, 백엔드 대상 또는 API 플랫폼

이 문제를 해결하려면 API 모니터링 > 조사 페이지 및 적절한 날짜, 프록시 등을 선택하면 다음 세부정보가 표시됩니다.

UI의 오류 코드 및 상태 코드

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

또한 위의 스크린샷에 표시된 대로 로그 보기를 클릭하여 자세히 확인할 수도 있습니다.

로그 보기

샘플 시나리오에서는 API 모니터링을 사용해 API의 5xx 문제를 해결하세요 예를 들어 404개 상태 코드 개수가 특정 기준점을 설정할 수 있습니다

진단 정보 수집 필요

위의 안내를 따른 후에도 문제가 지속되면 확인할 수 있습니다 Apigee Edge 지원팀에 문의하여 이 정보를 공유하세요.

  1. 퍼블릭 클라우드 사용자는 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
      </ph>
    • 조직 이름
    • 환경 이름
    • API 프록시 이름
    • curl 명령어를 완료하여 오류를 재현하세요.
  2. 프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
      </ph>
    • 전체 오류 메시지가 관찰됨
    • 환경 이름
    • 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. 이 플레이북의 어떤 섹션을 시도해 보았는지, 그리고 그 밖의 통찰력은 이 문제를 신속하게 해결하는 데 도움이 됩니다.