503 서비스를 사용할 수 없음 - NoActiveTargets - HealthCheckFailures

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

동영상

503 오류에 관한 자세한 내용은 다음 동영상을 참조하세요.

동영상 설명
<ph type="x-smartling-placeholder"></ph> 503 서비스를 사용할 수 없음 - NoActiveTargets 문제 해결 다음에 대해 알아보세요. <ph type="x-smartling-placeholder">
    </ph>
  • 대상 서버 및 상태 모니터의 중요성
  • 실시간 503 서비스를 사용할 수 없음 - NoActiveTargets 문제 해결 상태 확인 실패로 인해 발생한 오류

증상

클라이언트 애플리케이션이 HTTP 응답 상태 코드 503Service Unavailable 메시지가 표시되고 오류 코드: NoActiveTargets 사용할 수 있습니다

오류 메시지

다음과 같은 오류 응답이 표시됩니다.

HTTP/1.1 503 Service Unavailable
  

HTTP 응답에 다음 오류 메시지가 표시됩니다.

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.NoActiveTargets"
       }
    }
}
  

가능한 원인

일반적으로 HTTP 응답 503 Service Unavailable과 오류 코드 NoActiveTargets가 관찰됩니다. API 프록시의 대상 엔드포인트 구성에서 하나 이상의 대상 서버를 사용하는 경우

이 플레이북에서는 503 Service Unavailable과 오류 코드를 설명합니다. 상태 확인 실패로 인해 NoActiveTargets 가 발생했습니다. 이 오류의 다른 원인에 대해 알아보려면 이 플레이북을 참조하세요.

상태 점검 실패

상태 점검 실패는 <ph type="x-smartling-placeholder"></ph> 상태 모니터링: API 프록시의 대상 엔드포인트에서 대상 서버 부하 분산 구성의 일부로.

대상 서버가 상태 점검에 실패하면 Edge는 해당 서버의 실패 횟수를 증가시킵니다. 해당 서버의 상태 점검 실패 횟수가 사전 정의된 임곗값 (<MaxFailures>)에 도달하면 메시지 프로세서는 아래와 같이 경고 메시지를 로그 파일에 기록합니다.

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

경고 메시지에는 다음 정보가 제공됩니다. 이렇게 하면 MaxFailure 개수에 도달한 대상 서버를 파악하는 데 도움이 됩니다.

  • 대상 서버 이름
  • 조직 및 환경 이름
  • API 프록시 이름
  • 대상 엔드포인트 이름

그 후 Edge는 해당 특정 서버로의 추가 요청 전송을 중지합니다. 모든 타겟이 부하 분산기 구성에서 구성된 서버가 MaxFailure 개수에 도달하면 이후에 API 요청은 503 Service Unavailable 오류 코드와 함께 NoActiveTargets 오류 코드로 응답합니다.

상태 모니터를 사용하면 Apigee Edge가 대상 서버를 자동으로 정상 상태가 되면 API 프록시를 다시 배포하지 않고도 순환을 수행할 수 있습니다.

상태 점검 실패의 가능한 원인은 다음과 같습니다.

원인 설명 문제 해결 단계를 수행할 수 있는 사용자
연결 시간 초과 오류 메시지 프로세서가 지정된 제한 시간 내에 대상 서버에 연결할 수 없습니다. 지정할 수 있습니다 Edge 프라이빗 클라우드 사용자
비보안 포트의 보안 요청
  1. 대상 서버가 보안 서버로 정의되었지만 비보안 포트가 있습니다.
  2. 대상 서버가 보안 서버로 정의되어 있지만 상태 모니터링이 상태 점검을 수행하도록 구성되어 있는 포트입니다.
Edge 프라이빗 클라우드 사용자
보안 포트에서 비보안 요청
  1. 대상 서버가 비보안 서버로 정의되었지만 잘못 구성된 경우 보안 포트가 있어야 합니다.
  2. 대상 서버가 비보안 서버로 정의되어 있지만 상태 모니터링이 상태 점검을 수행하도록 구성되어 있습니다.
Edge 프라이빗 클라우드 사용자
Health Check API가 오류로 응답함 상태 점검 API가 오류 또는 응답 코드로 응답하는 경우 상태 모니터링의 SuccessResponse 요소에 지정되어 있습니다. Edge 프라이빗 클라우드 사용자

일반적인 진단 단계

실패한 요청의 메시지 ID 확인

추적 도구

Trace 도구를 사용하여 실패한 요청의 메시지 ID를 확인하려면 다음 안내를 따르세요.

  1. trace 세션을 사용 설정합니다. API를 호출하고 NoActiveTargets 오류 코드와 함께 503 Service Unavailable 문제를 재현합니다.
  2. 실패한 요청 중 하나를 선택합니다.
  3. AX 단계로 이동하여 메시지 ID (X-Apigee.Message-ID)를 확인합니다. 단계 세부정보 섹션에서 아래로 스크롤하여 요청의 유형을 확인하세요.

    단계 세부정보 섹션의 메시지 ID

NGINX 액세스 로그

NGINX 액세스 로그를 사용하여 실패한 요청의 메시지 ID를 확인하려면 다음 안내를 따르세요.

NGINX 액세스 로그를 참조하여 503 오류의 메시지 ID를 확인할 수도 있습니다. 이 기능은 문제가 이전에 발생했거나 간헐적인 경우 특히 유용합니다. UI에서 트레이스를 캡처할 수 없습니다. NGINX 액세스 로그에서 이 정보를 확인하려면 다음 단계를 따르세요.

  1. NGINX 액세스 로그를 확인합니다(/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log).
  2. 특정 기간 동안 특정 API 프록시에 503 오류가 발생했는지 검색합니다. (과거에 문제가 발생한 경우) 또는 여전히 503으로 실패한 요청이 있는지 확인합니다.
  3. X-Apigee-fault-codemessaging.adaptors.http.flow.NoActiveTargets에 503 오류가 있으면 다음 예와 같이 하나 이상의 이러한 요청에 대한 메시지 ID를 기록해 두세요.

    503 오류를 보여주는 샘플 항목

    상태 코드, 메시지 ID, 오류 소스, 오류 코드를 보여주는 샘플 항목

흔히 나타나는 오류 메시지

대상 서버가 사용되고 메시지 프로세서가 연결되면 메시지 프로세서 로그. 이러한 오류는 실제 예외/오류 메시지가 표시된 후에 기록됩니다. 살펴봤습니다

메시지 프로세서 로그에서 일반적으로 관찰되는 오류 메시지 (/opt/apigee/var/log/edge-message-processor/logs/system.log) 503 서비스를 사용할 수 없음(오류 코드: NoActiveTargets) 다음과 같습니다.

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

이 오류 메시지는 다음과 같은 이유로 인해 백엔드 서버에 요청을 전송할 수 없음을 나타냅니다. 있습니다 따라서 메시지 프로세서는 503 Service Unavailable을 클라이언트에 대한 응답으로 오류 코드 NoActiveTargets를 포함합니다.

원인: 연결 시간 초과

진단

  1. 실패한 요청의 메시지 ID를 확인합니다.
  2. 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
  3. 보시는 바와 같이 일반적인 오류 메시지를 표시합니다. 하지만 상태 점검 실패의 실제 원인을 확인하려면 이 항목 위로 스크롤하세요 일반적인 오류 메시지를 살펴보고 HEALTH MONITOR 오류가 있는지 확인하세요.

    예를 들어 다음 HEALTH MONITOR 오류 메시지는 메시지 프로세서가 실패했음을 나타냅니다. 상태 점검 API 요청을 할 때 연결 타임아웃 오류가 발생합니다.

    Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
    java.net.ConnectException: Connection timed out (Connection timed out)
    	at java.net.PlainSocketImpl.socketConnect(Native Method)
    	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
    	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
    …<snipped>
            

    상태 모니터에 구성된 MaxFailure 횟수 동안 이 오류가 반복되면 그러면 다음과 같은 경고 메시지가 표시됩니다.

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

    경고 메시지에 제공된 정보를 주의 깊게 읽습니다. MaxFailure 지정된 특정 API 프록시에서 사용되는 대상 서버의 개수가 오류 코드가 NoActiveTargets인 503 응답 코드가 표시됩니다.

  4. 위의 예시에서는 connection timed out 오류와 함께 상태 점검이 실패했습니다. 각 백엔드 서버에서 직접 특정 백엔드 서버에 연결할 수 있는지 telnet 명령어를 사용하는 메시지 프로세서:
  5. telnet <BackendServer-HostName> 443
          
  6. 백엔드 서버에 연결할 수 있으면 다음과 같은 메시지가 표시될 수 있습니다. 백엔드 서버에 연결합니다. 그렇다면 문제는 일시적인 문제일 수 있으며 문제가 해결되었거나 간헐적인 문제일 수 있습니다. 4단계를 몇 번 반복합니다. (10회 이상)하고 출력을 확인합니다.
    1. telnet 명령어에서 지속적으로 오류가 발생하지 않으면 다음과 같은 문제가 있는 것입니다. 문제가 해결되었습니다 상태 점검 실패가 중지되었는지 다시 확인합니다. 그렇다면 별도의 조치를 취하지 않아도 됩니다. 할 수 있습니다.
    2. telnet 명령어를 간헐적으로 사용하여 백엔드 서버에 연결할 수 없는 경우 네트워크 문제이거나 백엔드 서버가 많을 수 있습니다.
  7. telnet 명령어를 사용하여 백엔드 서버에 일관되게 연결할 수 없는 경우 특정 백엔드 서버의 메시지 프로세서에서 트래픽이 허용되지 않기 때문일 수 있습니다.

해상도

connection timed out 오류가 일관되게 관찰되면 백엔드가 서버에 방화벽 제한이 없으며 Apigee Edge 메시지 프로세서의 트래픽을 허용합니다. 예를 들어 Linux에서 iptables를 사용하여 백엔드 서버에 있는 메시지 프로세서의 IP 주소입니다.

문제가 지속되면 네트워크 관리자에게 문의하여 문제를 확인하고 해결하세요. Apigee의 추가 지원이 필요한 경우 Apigee 지원팀에 문의하세요.

원인: 비보안 포트에서 보안 요청

진단

  1. 실패한 요청의 메시지 ID를 확인합니다.
  2. 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
  3. 메시지 ID에 해당하는 일반적인 오류 메시지가 표시됩니다. 그러나 상태 점검 실패의 실제 원인을 확인하려면 일반적인 오류 메시지를 살펴보고 HEALTH MONITOR 오류가 있는지 확인하세요.

    예를 들어 아래와 같은 HEALTH MONITOR 오류가 표시될 수 있습니다.

    Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
            at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
            at sun.security.ssl.InputRecord.read(InputRecord.java:527)
            at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
            at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
            at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
    …<snipped>
            

    상태 모니터에 구성된 MaxFailure 횟수 동안 이 오류가 반복되면 다음과 같은 경고 메시지가 표시됩니다.

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

    경고 메시지에 제공된 정보를 주의 깊게 읽습니다. MaxFailure 지정된 특정 API 프록시에서 사용되는 대상 서버의 개수가 오류 코드가 NoActiveTargets인 503 응답 코드가 표시됩니다.

  4. 다음 오류로 상태 점검이 실패했습니다.
    Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
    javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
          

    오류 메시지와 URL은 보안 호출 (HTTPS)이 비보안 포트 80에서 수행되었습니다.

    이 오류는 다음 두 가지 시나리오에서 발생할 수 있습니다.

    • 비보안 포트로 정의된 보안 대상 서버
    • 보안 대상 서버가 정의되었지만 상태 모니터가 비보안 포트로 구성되어 있음

    보안 대상 비보안 포트

    시나리오 1: 비보안 포트로 정의된 보안 대상 서버

    80과 같은 비보안 포트를 사용하여 보안 대상 서버를 정의했다면 확인할 수 있습니다. 이 문제의 원인인지 확인하려면 아래 단계를 따르세요.

    1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.
    2. 사용 TargetServer API 가져오기 대상 서버 정의를 가져옵니다.

      대상 서버 정의 출력

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
                

      위의 예에서 정의는 대상 서버 mocktarget가 보안 SSLInfo 블록에 표시된 대로 서버에 정보를 전송합니다. 하지만 비보안 포트 80으로 구성되어 있습니다.

    3. 이제 대상 엔드포인트 구성에서 대상 서버의 상태 모니터 구성을 확인합니다.

      상태 모니터 구성

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      <Port> 요소가 위의 상태 모니터링 구성 이 경우 Edge의 메시지 프로세서는 대상 서버 정의 (80)에 지정되어 있어야 합니다.

    4. 위 정보에 근거할 때 이 오류의 원인은 대상 서버가 (SSLInfo 블록이 활성화됨), 비보안 포트 80을 포함하는 보안 서버로 정의됩니다.

    보안 대상 비보안 HM 포트

    시나리오 2: 보안 대상 서버가 정의되었지만 상태 모니터가 비보안 포트로 구성됨

    보안 대상 서버를 정의했지만 Health Monitor가 80과 같은 비보안 포트를 사용하는 경우 이 오류가 발생합니다. 인증하려면 아래 단계를 따르세요. 이 문제의 원인인 경우:

    1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.

      TargetServer API를 가져와 대상 서버 정의를 가져옵니다.

      대상 서버 정의 출력

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
              

      위의 예에서 정의는 대상 서버 mocktargetSSLInfo 블록으로 표시된 보안 서버임을 보여줍니다.

    2. 그런 다음 대상 엔드포인트 구성에서 대상 서버의 상태 모니터 구성을 확인합니다.

      상태 모니터 구성

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      위의 예에서 상태 모니터는 <Port> 요소로 표시된 비보안 포트 80으로 구성되어 있습니다.

    3. 위 정보에 근거할 때 이 오류의 원인은 대상 서버가 (SSLInfo 블록이 사용 설정된 경우) 보안 서버로 설정되고 보안 포트 443을 사용하지만 Health Monitor는 비보안 포트 80 (<Port> 요소에 지정됨)으로 상태 점검을 수행하도록 구성되어 있습니다.

      즉, 이 경우 Edge는 상태 점검 API를 비보안 호출을 사용한 보안 호출로 만듭니다. 포트 80으로 설정하고 위에서 언급한 오류와 함께 실패합니다.

해상도

보안 대상 비보안 포트

시나리오 1: 비보안 포트로 정의된 보안 대상 서버

이 오류를 수정하려면 적절한 보안 포트를 사용하도록 대상 서버 정의를 업데이트하세요.

TargetServer API를 업데이트하여 대상 서버 정의를 업데이트하고 아래 예와 같이 보안 포트 (예: 443) 가 사용됩니다.

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    

보안 대상 비보안 HM 포트

시나리오 2: 보안 대상 서버가 정의되었지만 상태 모니터가 비보안 포트로 구성됨

이 오류를 수정하려면 다음 안내를 따르세요.

  1. 보안 포트 (예: 443)를 사용하여 대상을 수행하도록 상태 모니터 구성 수정 실패한 API 프록시의 대상 엔드포인트 구성에서 서버 상태 점검을 실행합니다.
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
        <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>443</Port>
          <Verb>GET</Verb>
          <Path>/statuscode/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            
  2. API 프록시에 변경사항을 저장합니다.

원인: 보안 포트에서 보안되지 않은 요청

진단

  1. 실패한 요청의 메시지 ID를 확인합니다.
  2. 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
  3. 보시는 바와 같이 일반적인 오류 메시지를 표시합니다. 그러나 상태 점검 실패의 실제 원인을 확인하려면 일반적인 오류 메시지를 살펴보고 HEALTH MONITOR 오류가 있는지 확인하세요.

    예를 들어 아래와 같은 HEALTH MONITOR 오류가 표시될 수 있습니다.

    Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
    	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
    	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
    	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
    	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
    …<snipped>
              

    상태 모니터에 구성된 MaxFailure 횟수 동안 이 오류가 반복되면 다음과 같은 경고 메시지가 표시됩니다.

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
              

    경고 메시지에 제공된 정보를 주의 깊게 읽습니다. MaxFailure 지정된 특정 API 프록시에서 사용되는 대상 서버의 개수가 오류 코드가 NoActiveTargets인 503 응답 코드가 표시됩니다.

  4. 다음 오류로 상태 점검이 실패했습니다.
    Error sending request Request URL : http://mocktarget.apigee.net:443/status
    java.net.SocketException: Unexpected end of file from server
          

    오류 메시지와 URL은 보안 포트 443에서 비보안 호출 (HTTP)이 수행되었습니다.

    이 오류는 다음 두 가지 시나리오에서 발생할 수 있습니다.

    • 보안 포트로 정의된 비보안 대상 서버
    • 비보안 대상 서버가 정의되었지만 상태 모니터링이 보안 포트로 구성되어 있음

    비보안 대상 보안 포트

    시나리오 1: 보안 포트로 정의된 비보안 대상 서버

    443과 같은 보안 포트를 사용하여 비보안 대상 서버를 정의했다면, 이 오류가 발생합니다 이 문제의 원인인지 확인하려면 아래 단계를 따르세요.

    1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.

      TargetServer API를 가져와 대상 서버 정의를 가져옵니다.

      대상 서버 정의 출력

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
                    

      위의 예에서 정의는 대상 서버 mocktargetSSLInfo 블록이 없으므로 비보안 서버입니다. 하지만 잘못됨 구성됩니다.

    2. 이제 대상 엔드포인트 구성에서 대상 서버의 상태 모니터 구성을 확인합니다.

      상태 모니터 구성

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      상태 모니터에 지정된 <Port> 요소가 없습니다. 참조하세요. 이 경우 Edge의 메시지 프로세서는 대상 서버 정의인 443입니다

    3. 위 정보에 근거할 때 이 오류의 원인은 대상 서버가 (SSLInfo 블록이 정의되지 않음)을 비보안 서버로 사용하지만 보안 포트 443을 사용합니다.

      즉, Edge는 상태 점검을 보안 포트 443을 사용한 비보안 호출로 만들고 실패합니다. 사용할 수 있습니다.

    비보안 대상 보안 HM 포트

    시나리오 2: 비보안 대상 서버가 정의되었지만 상태 모니터링이 보안 포트로 구성됨

    비보안 대상 서버를 정의했지만 Health Monitor가 443과 같은 보안 포트로 구성된 경우에는 이 오류가 발생합니다 이 문제의 원인인지 확인하려면 아래 단계를 따르세요.

    1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.

      TargetServer API를 가져와 대상 서버 정의를 가져옵니다.

      대상 서버 정의 출력

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      위의 예에서 정의는 대상 서버 mocktarget이 비보안 서버라는 것을 보여줍니다. 서버 (SSLInfo 블록이 없기 때문)를 비보안 포트 80으로 올바르게 구성했는지 확인합니다.

    2. 그런 다음 대상 엔드포인트 구성에서 대상 서버의 상태 모니터 구성을 확인합니다.

      상태 모니터 구성

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      위의 예에서 Health Monitor는 <Port> 요소로 표시된 보안 포트 443으로 구성되어 있습니다.

    3. 위 정보에 근거할 때 이 오류의 원인은 대상 서버가 SSLInfo 블록이 정의되지 않은 것처럼 비보안 서버를 사용하고 있다면 비보안 포트 80이 올바르게 상태 모니터는 보안 포트 443 (<Port> 요소에 지정됨)으로 상태 확인을 수행하도록 구성되어 있습니다.

      즉, 이 경우 Edge는 보안 포트 443을 사용하여 상태 점검을 비보안 호출로 실행하고 위에 언급된 오류와 함께 실패합니다.

해상도

비보안 대상 보안 포트

시나리오 1: 보안 포트로 정의된 비보안 대상 서버

이 오류를 수정하려면 적절한 보안 포트를 사용하도록 대상 서버 정의를 업데이트하세요.

대상 서버 API를 업데이트하여 대상 서버 정의를 업데이트하고 아래 예와 같이 비보안 포트 (예: 80) 사용됩니다.

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

비보안 대상 보안 HM 포트

시나리오 2: 비보안 대상 서버가 정의되었지만 상태 모니터링이 보안 포트로 구성됨

이 오류를 수정하려면 다음 안내를 따르세요.

  1. 상태 모니터 구성에서 <Port> 요소를 삭제합니다. 또는 비보안 포트 (예: 80) 를 사용하도록 상태 모니터링 구성을 수정하세요. 아래와 같이 실패한 API 프록시의 대상 엔드포인트 구성에서 대상 서버 상태 점검을 수행합니다.
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
       	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/statuscode/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            
  2. API 프록시에 변경사항을 저장합니다.

원인: Health check API가 오류로 응답함

진단

  1. 실패한 요청의 메시지 ID를 확인합니다.
  2. 메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
  3. 메시지 ID에 해당하는 일반적인 오류 메시지가 표시됩니다. 그러나 상태 점검 실패의 실제 원인을 확인하려면 일반적인 오류 메시지를 살펴보고 HEALTH MONITOR 오류/경고가 있는지 확인합니다.

    예를 들어 아래와 같이 HEALTH MONITOR 경고가 표시될 수 있습니다.

    Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
    Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
            

    상태 모니터에 구성된 MaxFailure 횟수 동안 이 오류가 반복되면 다음과 같은 경고 메시지가 표시됩니다.

    Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
            

    경고 메시지에 제공된 정보를 주의 깊게 읽습니다. MaxFailure 지정된 특정 API 프록시에서 사용되는 대상 서버의 개수가 오류 코드가 NoActiveTargets인 503 응답 코드가 표시됩니다.

  4. 상태 점검에서 경고 메시지를 반환했습니다.
    HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
          

    위의 경고 메시지는 상태 점검 API의 예상 응답 코드가 200임을 나타냅니다. 수신된 실제 응답은 404입니다. 따라서 이는 실패로 간주됩니다.

  5. 상태 점검 API에서 오류 응답이 발생하는 원인을 조사하기 전에 Edge에서 그 이유를 확인하세요. 상태 점검 API의 경우 응답 코드가 200일 것으로 예상합니다. 상태를 모니터링하려면 대상 엔드포인트 구성에서 대상 서버의 구성을 설정합니다.

    상태 모니터 구성

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
       	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>443</Port>
          <Verb>GET</Verb>
          <Path>/status/200</Path>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
            

    상태 모니터 구성이 <SuccessResponse> 요소 아래 200 응답 코드로 구성되어 있습니다. 즉, Edge가 상태 점검 API에서 200이 아닌 응답 코드 (예: 400, 401, 404, 500)를 받으면 오류로 취급되고 실패 횟수가 증가합니다.

  6. 이제 상태 점검 API에서 오류 응답의 원인을 조사하려면 다음 단계를 따르세요.
    1. 메시지 프로세서 로그에서 경고 메시지 앞에 있는 메시지를 확인합니다.
      Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
                

      이 메시지의 상태 점검 URL을 기록해 둡니다.

    2. 메시지 프로세서에서 이 URL로 직접 호출하여 실제 응답을 확인할 수 있습니다.
      curl -i https://mocktarget.apigee.net:443/status/200
                

      위 호출의 응답은 메시지 프로세서 로그에서 볼 수 있듯이 404를 제공합니다.

      < HTTP/2 404
                
    3. 이는 상태 점검 URL에 대한 직접 호출도 동일한 응답 코드 404와 함께 실패함을 보여줍니다. 이는 상태 점검 URL이 잘못되었거나 URL의 일부로 액세스 중인 리소스를 더 이상 사용할 수 없음을 의미합니다.
    4. 위에 제공된 상태 점검 API 예에서는 상태 모니터 구성에 잘못된 URL이 사용되었기 때문에 문제가 발생합니다. 올바른 URL은 다음의 https://mocktarget.apigee.net:443/statuscode/200입니다. 모의 대상 API.
  7. 다른 오류 응답이 표시되면 단계를 따르세요. 필요한 경우 백엔드팀과 협력합니다.

해상도

  1. 백엔드 서버에서 상태 점검 API 관련 문제를 해결합니다.
  2. 위에 설명된 예에서 문제를 해결하려면 다음 안내를 따르세요.
    1. 아래와 같이 상태 모니터링 구성의 <Path> 요소를 /statuscode/200로 수정합니다. <ph type="x-smartling-placeholder">
      <Path>/statuscode/200</Path>
              
      </ph>
    2. API 프록시에 변경사항을 저장합니다.

문제가 계속되면 진단 정보를 수집해야 함.

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

API 모니터링으로 문제 격리 가능 오류, 성능, 지연 시간 문제를 진단할 수 있는 영역과 그 원인(예: 개발자)을 백엔드 타겟, API 플랫폼 중에서 선택할 수 있습니다

샘플 시나리오 살펴보기 에서 API Monitoring을 사용해 API의 5xx 문제를 해결하는 방법을 알아보세요. 예를 들어 messaging.adaptors.http.flow.NoActiveTargets 수가 많을 때 알림을 받도록 설정할 수 있습니다. 특정 임곗값을 초과하는 경우를 예로 들 수 있습니다

진단 정보 수집 필요

위의 안내를 따랐는데도 문제가 계속되면 다음 내용을 수집합니다. 제공합니다. Apigee 지원팀에 연락하여 공유하세요.

  1. 퍼블릭 클라우드 사용자는 다음 정보를 제공하세요.
    1. 조직 이름
    2. 환경 이름
    3. API 프록시 이름
    4. curl 명령어를 완료하여 오류를 재현하세요.
    5. 503 서비스를 사용할 수 없음(오류 코드: NoActiveTargets)이 포함된 요청이 포함된 추적 파일
  2. 프라이빗 클라우드 사용자인 경우 다음 정보를 제공하세요. <ph type="x-smartling-placeholder">
      </ph>
    1. 오류 메시지 완료 확인됨
    2. 환경 이름
    3. API 프록시 번들
    4. 503 서비스를 사용할 수 없음(오류 코드: NoActiveTargets)이 포함된 요청이 포함된 추적 파일
    5. NGINX 액세스 로그

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

    6. 메시지 프로세서 로그

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