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

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

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

동영상

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

동영상	설명
문제 해결 및 503 Service Unavailable - NoActiveTargets	다음에 대해 알아보세요. 대상 서버 및 상태 모니터의 중요성 실시간 503 서비스를 사용할 수 없음 - 상태 점검 실패로 인해 발생한 NoActiveTargets 오류 문제 해결

증상

클라이언트 애플리케이션이 Service Unavailable 메시지와 함께 HTTP 응답 상태 코드 503과 API 프록시 요청에 대한 오류 코드 NoActiveTargets를 수신합니다.

오류 메시지

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

HTTP/1.1 503 Service Unavailable

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

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

가능한 원인

NoActiveTargets 오류 코드가 포함된 HTTP 응답 503 Service Unavailable은 일반적으로 API 프록시의 대상 엔드포인트 구성에서 하나 이상의 대상 서버를 사용할 때 나타납니다.

이 플레이북에서는 503 Service Unavailable 및 상태 점검 실패로 인해 발생한 NoActiveTargets 오류 코드를 다룹니다. 이 오류의 다른 원인을 알아보려면 이 플레이북을 참조하세요.

상태 점검 실패

상태 점검 실패는 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는 해당 특정 서버로 추가 요청 전송을 중지합니다. LoadBalancer 구성에 구성된 모든 대상 서버가 MaxFailure 개수에 도달하면 후속 API 요청은 503 Service Unavailable 응답과 함께 오류 코드 NoActiveTargets.

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

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

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

일반적인 진단 단계

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

추적 도구

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

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

NGINX 액세스 로그

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

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

NGINX 액세스 로그 확인: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
특정 기간 동안 특정 API 프록시에 503 오류가 있는지(과거에 문제가 발생한 경우) 또는 여전히 503과 함께 실패하는 요청이 있는지 검색합니다.
X-Apigee-fault-code Messaging.adaptors.http.flow.NoActiveTargets가 포함된 503 오류가 있는 경우 다음 예와 같이 이러한 요청 하나 이상의 메시지 ID를 기록해 둡니다.
503 오류를 보여주는 샘플 항목

흔히 나타나는 오류 메시지

대상 서버를 사용 중이고 메시지 프로세서가 백엔드 서버와의 연결을 시도하는 동안 오류가 발생하면 메시지 프로세서 로그에 몇 가지 일반적인 오류 메시지가 표시됩니다. 이러한 오류는 실패를 유발한 실제 예외/오류 메시지 이후에 로깅됩니다.

503 Service Unavailable 관련 메시지 프로세서 로그(/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 오류 코드 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>

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

원인: 연결 시간 초과

진단

실패한 요청의 메시지 ID를 확인합니다.
메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
메시지 ID에 해당하는 일반적인 오류 메시지가 표시됩니다. 하지만 상태 확인 실패의 실제 원인을 확인하려면 일반 오류 메시지 위로 스크롤하여 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}
        
```
경고 메시지에 있는 정보를 주의 깊게 읽습니다. NoActiveTargets 오류 코드와 함께 503 응답 코드가 발생하는 특정 API 프록시에 사용되는 대상 서버의 MaxFailure 수에 도달했는지 확인하세요.
위의 예시에서는 connection timed out 오류와 함께 상태 점검이 실패했습니다. telnet 명령어를 사용하여 각 메시지 프로세서에서 특정 백엔드 서버에 직접 연결할 수 있는지 확인합니다.

telnet <BackendServer-HostName> 443

백엔드 서버에 연결할 수 있으면 Connected tobackend-server와 같은 메시지가 표시될 수 있습니다. 그러면 문제는 일시적인 문제일 수 있으며 해결되거나 간헐적인 문제일 수 있습니다. 4단계를 몇 번(10회 이상) 반복하고 출력을 확인합니다.

telnet 명령어에서 일관되게 오류가 없다면 문제가 해결된 것입니다. 상태 확인 실패가 중지되었는지 다시 확인합니다. 그렇다면 추가 조치를 취할 필요가 없습니다.
telnet 명령어를 사용하여 간헐적으로 백엔드 서버에 연결할 수 없다면 네트워크 문제가 있거나 백엔드 서버가 사용 중인 것일 수 있습니다.

telnet 명령어로 백엔드 서버에 일관되게 연결할 수 없다면 특정 백엔드 서버의 메시지 프로세서에서 트래픽을 허용하지 않기 때문일 수 있습니다.

해상도

connection timed out 오류가 지속적으로 관찰되는 경우 백엔드 서버에 방화벽 제한이 없고 Apigee 에지 메시지 프로세서의 트래픽을 허용하는지 확인합니다. 예를 들어 Linux에서는 iptables를 사용하여 백엔드 서버에 있는 메시지 프로세서의 IP 주소에서 오는 트래픽을 허용할 수 있습니다.

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

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

진단

실패한 요청의 메시지 ID를 확인합니다.
메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.

메시지 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}

경고 메시지에 있는 정보를 주의 깊게 읽습니다. NoActiveTargets 오류 코드와 함께 503 응답 코드가 발생하는 특정 API 프록시에 사용되는 대상 서버의 MaxFailure 수에 도달했는지 확인하세요.

오류로 인해 상태 점검이 실패했습니다.
```
Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
      
```
오류 메시지와 URL은 이 문제의 원인을 비보안 포트 80에서 보안 호출 (HTTPS)이 발생했음을 알려줍니다.

이 오류는 다음 두 시나리오에서 발생할 수 있습니다.
- 비보안 포트로 정의된 보안 대상 서버
- 보안 대상 서버가 정의되었지만 상태 모니터가 비보안 포트로 구성되었습니다.
보안 대상 비보안 포트

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

보안 대상 서버를 정의했지만 80과 같은 비보안 포트가 있는 경우 이 오류가 발생합니다. 다음 단계에 따라 이 문제의 원인인지 확인하세요.
1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.
2. 이제 대상 엔드포인트 구성에서 대상 서버의 Health Monitor 구성을 확인합니다.
  상태 모니터 구성
```
<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>
          
```
  위의 Health Monitor 구성에 지정된 <Port> 요소가 없습니다. 이 경우 Edge의 메시지 프로세서는 대상 서버 정의에 지정된 포트 (80)를 사용하여 상태 점검 API를 호출합니다.
3. 위의 정보에 따르면 이 오류가 발생하는 이유는 대상 서버가 보안 서버 (SSLInfo 블록이 사용 설정됨)로 정의되어 있지만 비보안 포트 80으로 설정되어 있기 때문입니다.
보안 대상 비보안 HM 포트

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

보안 대상 서버를 정의했지만 상태 모니터가 80과 같은 비보안 포트로 구성된 경우 이 오류가 발생합니다. 아래 단계를 따라 이 문제의 원인인지 확인하세요.
1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.
  Get TargetServer API를 사용하여 대상 서버 정의를 가져옵니다.
  
  대상 서버 정의 출력
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
        
```
  위의 예에서 정의는 대상 서버 mocktarget이 SSLInfo 블록으로 표시된 보안 서버임을 보여줍니다.
2. 다음으로 대상 엔드포인트 구성에서 대상 서버의 Health Monitor 구성을 확인합니다.
  상태 모니터 구성
```
<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을 사용하지만, 상태 모니터는 비보안 포트 80 (<Port> 요소에 지정됨)으로 상태 점검을 실행하도록 구성되어 있기 때문입니다.
  즉, 이 경우 Edge는 상태 확인 API를 비보안 포트 80이 있는 보안 호출로 만들고 위에 언급된 오류와 함께 실패합니다.
  
  참고: 상태 모니터에 구성된 <Port> 요소는 대상 서버 정의에 사용되는 포트보다 우선합니다.

해상도

보안 대상 비보안 포트

시나리오 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: 보안 대상 서버가 정의되었지만 상태 모니터가 비보안 포트로 구성됨

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

아래와 같이 실패한 API 프록시의 타겟 엔드포인트 구성에서 대상 서버 상태 확인을 수행하기 위해 보안 포트 (예: 443)를 사용하도록 상태 모니터 구성을 수정합니다.

<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>

API 프록시에 변경사항을 저장합니다.

원인: 보안 포트에 대한 비보안 요청

진단

실패한 요청의 메시지 ID를 확인합니다.
메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.

예를 들어 아래와 같이 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}

오류로 인해 상태 점검이 실패했습니다.
```
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. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.
  Get TargetServer API를 사용하여 대상 서버 정의를 가져옵니다.
  
  대상 서버 정의 출력
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              
```
  위의 예에서 정의는 대상 서버 mocktarget가 비보안 서버임을 보여줍니다. SSLInfo 블록이 없기 때문입니다. 하지만 보안 포트 443을 사용하여 잘못 구성되었습니다.
2. 이제 대상 엔드포인트 구성에서 대상 서버의 Health Monitor 구성을 확인합니다.
  상태 모니터 구성
```
<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>
                
```
  위의 Health Monitor 구성에 지정된 <Port> 요소가 없습니다. 이 경우 에지의 메시지 프로세서는 대상 서버 정의에 지정된 포트(443)를 사용합니다.
3. 위의 정보에 따르면 이 오류가 발생하는 이유는 대상 서버가 비보안 서버 (SSLInfo 블록이 정의되지 않음)로 정의되어 있지만 보안 포트 443을 사용하기 때문입니다.
  즉, Edge는 보안 포트 443을 사용하는 비보안 호출로 상태 확인을 실행하며 위에 언급된 오류와 함께 실패합니다.
비보안 대상 보안 HM 포트

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

비보안 대상 서버를 정의했지만 상태 모니터가 443과 같은 보안 포트로 구성된 경우 이 오류가 발생합니다. 다음 단계에 따라 이 문제의 원인인지 확인하세요.
1. 대상 엔드포인트 구성에 사용된 대상 서버의 정의를 확인하세요.
  Get TargetServer API를 사용하여 대상 서버 정의를 가져옵니다.
  
  대상 서버 정의 출력
```
<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
        
```
  위의 예에서 정의는 대상 서버 mocktarget이 비보안 포트 80으로 올바르게 구성된 비보안 서버 (SSLInfo 블록이 없기 때문에)임을 보여줍니다.
2. 다음으로 대상 엔드포인트 구성에서 대상 서버의 Health Monitor 구성을 확인합니다.
  상태 모니터 구성
```
<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>
      
```
  위의 예에서 상태 모니터는 <Port> 요소로 표시되는 보안 포트 443으로 구성됩니다.
3. 위의 정보에 따르면 이 오류의 원인은 대상 서버가 비보안 포트 80을 사용하는 비보안 서버 (SSLInfo 블록이 정의되지 않음)로 정의되어 있지만 상태 점검이 보안 포트 443 (<Port> 요소에 지정됨)으로 상태 확인을 실행하도록 구성되어 있기 때문입니다.
  즉, 이 경우 Edge는 보안 포트 443을 사용하는 비보안 호출로 상태 확인을 실행하며 위에 언급된 오류와 함께 실패합니다.

해상도

비보안 대상 보안 포트

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

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

Update a Target Server API를 사용하여 대상 서버 정의를 업데이트하고 비보안 포트 (예: 80)가 아래 예시와 같이 사용되는지 확인합니다.

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

비보안 대상 보안 HM 포트

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

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

상태 모니터 구성에서 <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>

API 프록시에 변경사항을 저장합니다.

원인: 상태 점검 API에서 오류로 응답

진단

실패한 요청의 메시지 ID를 확인합니다.
메시지 프로세서 로그 (/opt/apigee/var/log/edge-message-processor/logs/system.log)에서 메시지 ID를 검색합니다.
메시지 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}
        
```
경고 메시지에 있는 정보를 주의 깊게 읽습니다. NoActiveTargets 오류 코드와 함께 503 응답 코드가 발생하는 특정 API 프록시에 사용되는 대상 서버의 MaxFailure 수에 도달했는지 확인하세요.
상태 점검에서 경고 메시지
```
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
      
```
을 반환했습니다.
위의 경고 메시지는 상태 점검 API의 예상 응답 코드가 200이지만 실제 수신된 응답은 404라고 명시합니다. 따라서 실패로 간주됩니다.
상태 점검 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)를 가져오면 오류로 처리되어 실패 횟수가 증가합니다.
이제 상태 점검 API의 오류 응답 원인을 조사하려면 다음 단계를 따르세요.

메시지 프로세서 로그에서 경고 메시지 이전의 메시지를 확인합니다.

Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200

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

메시지 프로세서에서 이 URL을 직접 호출하여 실제 응답을 확인할 수 있습니다.
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
위 호출의 응답은 메시지 프로세서 로그에 표시된 것처럼 404를 표시합니다.
```
< HTTP/2 404
          
```
이는 상태 점검 URL을 직접 호출해도 동일한 응답 코드 404와 함께 실패함을 보여줍니다. 이는 상태 점검 URL이 잘못되었거나 URL의 일부로 액세스 중인 리소스를 더 이상 사용할 수 없음을 의미합니다.
위에 제공된 상태 점검 API 예시에서는 상태 모니터 구성에 잘못된 URL이 사용되었기 때문에 문제가 발생합니다. 올바른 URL은 Mock Target API의 https://mocktarget.apigee.net:443/statuscode/200입니다.

다른 오류 응답이 수신되면 위 단계에 따라 원인을 파악하세요. 필요한 경우 백엔드팀과 협력하세요.

해상도

백엔드 서버에서 상태 점검 API 관련 문제를 해결합니다.
위에서 설명한 예에서 문제를 해결하려면 다음 단계를 따르세요.

아래와 같이 Health Monitor 구성의 <Path> 요소를 /statuscode/200로 수정합니다.
```
<Path>/statuscode/200</Path>
        
```
API 프록시의 변경사항을 저장합니다.

문제가 계속되면 진단 정보를 수집해야 함으로 이동하세요.

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

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

API Monitoring을 사용하여 API의 5xx 문제를 해결하는 방법을 보여주는 샘플 시나리오를 단계별로 살펴보세요. 예를 들어 messaging.adaptors.http.flow.NoActiveTargets 오류 수가 특정 임곗값을 초과하면 알림을 받도록 알림을 설정할 수 있습니다.

진단 정보 수집 필요

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

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

조직 이름
환경 이름
API 프록시 이름
curl 명령어를 완료하여 오류를 재현하세요.
503 Service Unavailable의 요청이 포함된 추적 파일(오류 코드 NoActiveTargets)

Private Cloud 사용자인 경우 다음 정보를 제공하세요.
1. 완료 오류 메시지 관찰됨
2. 환경 이름
3. API 프록시 번들
4. 503 Service Unavailable의 요청이 포함된 추적 파일(오류 코드 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)