503 サービス利用不可 - NoActiveTargets - HealthCheckFailures

<ph type="x-smartling-placeholder"></ph> 現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。 詳細

動画

503 エラーについて詳しくは、次の動画をご覧ください。

症状

クライアント アプリケーションは、HTTP レスポンスのステータス コード 503 を、 Service Unavailable というメッセージとエラーコード NoActiveTargets が表示される API プロキシリクエストだけです

エラー メッセージ

次のエラー レスポンスが表示されます。

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 プロキシのターゲット エンドポイント構成で 1 つ以上のターゲット サーバーを使用する場合。

このハンドブックでは、503 Service Unavailable（サービス利用不可）に関するエラーコードを取り上げます。 NoActiveTargets - ヘルスチェックの失敗が原因で発生する。 このエラーのその他の原因については、こちらのハンドブックをご覧ください。

ヘルスチェックの失敗

ヘルスチェックの失敗がモニタリングされるのは、 <ph type="x-smartling-placeholder"></ph> Health Monitor は、API プロキシのターゲット エンドポイントでターゲット サーバーのロード バランシング構成の一部として使用できます。

ターゲット サーバーがヘルスチェックに失敗すると、Edge はそのサーバーの失敗カウントをインクリメントします。 そのサーバーのヘルスチェックの失敗回数が事前定義のしきい値（<MaxFailures>）に達した場合、 Message Processor では、次のような警告メッセージがログファイルに記録されます。

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 リクエストは、エラーコード NoActiveTargets とともに 503 Service Unavailable を返します。

Health Monitor を使用すると、Apigee Edge は自動的にターゲット サーバーをインスタンスに戻すことができます。 API プロキシを再デプロイする必要はありません。

ヘルスチェックの失敗には、次のような原因が考えられます。

共通の診断手順

失敗したリクエストのメッセージ ID を特定する

一般的なエラー メッセージ

ターゲット サーバーが使用されていて、Message Processor がターゲット サーバーを 接続すると、いくつかの一般的なエラー メッセージが Message Processor のログ。これらのエラーは、実際の例外/エラー メッセージの後でログに記録されます。 確認しました

Message Processor のログで観察される一般的なエラー メッセージ （/opt/apigee/var/log/edge-message-processor/logs/system.log） 503 Service Unavailable（エラーコード: 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>

これらのエラー メッセージは、 失敗します。その結果、Message Processor から 503 Service Unavailable が送信されます。 クライアントへのレスポンスとしてエラーコード NoActiveTargets が表示されます。

原因: 接続タイムアウト

診断

1. 失敗したリクエストのメッセージ ID を特定する。
2. Message Processor ログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）でメッセージ ID を検索します。
3. [ 一般的なエラー メッセージを確認できます。ただし、 ヘルスチェックの失敗の実際の原因を確認するには、 一般的なエラー メッセージを調べて、HEALTH MONITOR のエラーがないかどうかチェックしてください。

   たとえば、次の HEALTH MONITOR エラー メッセージは、Message Processor で障害が発生したことを示します。 ヘルスチェック 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 プロキシで使用されているターゲット サーバーが、この数に達した 503 レスポンス コード（エラーコード NoActiveTargets）が表示される。

4. 上記の例では、ヘルスチェックが connection timed out エラーで失敗しています。 各インスタンスから特定のバックエンド サーバーに直接接続できるかどうかを確認する telnet コマンドを使用する Message Processor:

telnet <BackendServer-HostName> 443
      

5. バックエンド サーバーに接続できる場合、次のようなメッセージが表示されることがあります。 backend-server に接続。この場合、その問題は一時的な問題であり、 解決しているか断続的に発生している可能性があります。ステップ 4 を数回繰り返します （10 回以上）実行して出力を確認します。
1. telnet コマンドでエラーが一貫して発生しない場合は、問題があります。 解決しました。ヘルスチェックの失敗が停止したかどうかを再確認します。「はい」であれば、何もする必要はありません。 見ていきます
2. telnet コマンドを使用してバックエンド サーバーに断続的に接続できない場合、 ネットワークに問題があるか、バックエンド サーバーがビジー状態になっている可能性があります。
6. telnet コマンドを使用してバックエンド サーバーに一貫して接続できない場合は、 特定のバックエンド サーバーの Message Processor からのトラフィックが許可されていないことが原因と考えられます。

解決策

connection timed out エラーが継続的に発生する場合は、バックエンド サーバーにファイアウォールの制限がなく、Apigee Edge Message Processor からのトラフィックを許可します。 たとえば、Linux では iptables を使用して、 バックエンド サーバー上の Message Processor の IP アドレス。

問題が解決しない場合は、ネットワーク管理者と協力して問題を特定し、解決してください。 Apigee からさらにサポートが必要な場合は、Apigee サポートにお問い合わせください。

原因: セキュアでないポートでのセキュア リクエスト

診断

1. 失敗したリクエストのメッセージ ID を特定する。
2. Message Processor ログ（/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 プロキシで使用されているターゲット サーバーが、この数に達した 503 レスポンス コード（エラーコード NoActiveTargets）が表示される。

4. ヘルスチェックが失敗し、次のエラーが返されました。

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   このエラー メッセージと URL は、 セキュアでないポート 80 でセキュア呼び出し（HTTPS）が行われた。

   このエラーは、次の 2 つのシナリオで発生する可能性があります。

   • セキュアでないポートで定義されたセキュアなターゲット サーバー
   • セキュア ターゲット サーバーが定義されているが、Health Monitor が非セキュアポートで構成されている

   セキュア ターゲットの非セキュア ポート

   シナリオ 1: セキュアでないポートで定義されたセキュアなターゲット サーバー

   セキュアなターゲット サーバーを定義しても、80 などのセキュアでないポートを使用すると、 表示されます。次の手順に従って、この問題の原因かどうかを確認します。

   1. ターゲット エンドポイントの構成で使用されているターゲット サーバーの定義を確認します。

   こちらの TargetServer API の取得 ターゲット サーバーの定義を取得します。

   ターゲット サーバー定義の出力

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

   上記の例では、定義はターゲット サーバー mocktarget がセキュアであることを示しています。 SSLInfo ブロックで示される SSL 通知サーバー。ただし、セキュアでないポート 80 で構成されています。

   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>
                

      <Port> 要素が ヘルスモニターの構成は上記で説明しています。この場合、Edge の Message Processor で次のポートが使用されます。 ターゲット サーバーの定義（80）で指定された、ヘルスチェック API 呼び出しを行うための

   3. 上記の情報によると、このエラーの原因は、ターゲット サーバーが として定義された（SSLInfo ブロックが有効）、セキュアでないポート 80 を使用します。

   セキュア ターゲットの非セキュア HM ポート

   シナリオ 2: 安全なターゲット サーバーが定義されているが、Health Monitor にセキュアでないポートが構成されている

   安全なターゲット サーバーを定義したものの、Health Monitor に 80 などのセキュアでないポートを指定している場合、このエラーが発生します。確認手順は次のとおりです。 エラーの原因となっているかどうかを確認します。

   1. ターゲット エンドポイントの構成で使用されているターゲット サーバーの定義を確認します。

      <ph type="x-smartling-placeholder"></ph> Get TargetServer API を使用して、ターゲット サーバーの定義を取得します。

      ターゲット サーバー定義の出力

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

      上記の例では、SSLInfo ブロックが示しているように、ターゲット サーバー mocktarget が安全なサーバーであることを示しています。

   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> 要素で示されているように、Health Monitor が非セキュアポート 80 で構成されています。

   3. 上記の情報によると、このエラーの原因は、ターゲット サーバーが定義されていることです。 安全なサーバーとして（SSLInfo ブロックが有効）、セキュアポート 443 を使用しますが、Health Monitor は セキュアでないポート 80（<Port> 要素で指定）でヘルスチェックを実行するように構成されている。

      つまり、この場合、Edge はヘルスチェック API を非セキュア呼び出しとして、 ポート 80 でポート 80 を開き、上記のエラーで失敗します。

解決策

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

原因: セキュアポートでのセキュアでないリクエスト

診断

1. 失敗したリクエストのメッセージ ID を特定する。
2. Message Processor ログ（/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 プロキシで使用されているターゲット サーバーが、この数に達した 503 レスポンス コード（エラーコード NoActiveTargets）が表示される。

4. ヘルスチェックが失敗し、次のエラーが返されました。

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   このエラー メッセージと URL は、 セキュアポート 443 で非セキュア呼び出し（HTTP）が行われた。

   このエラーは、次の 2 つのシナリオで発生する可能性があります。

   • セキュアポートで定義されたセキュアでないターゲット サーバー
   • セキュアでないターゲット サーバーが定義されているが、Health Monitor がセキュアポートで構成されている

   セキュアでないターゲットのセキュアポート

   シナリオ 1: セキュアポートが定義されたセキュアでないターゲット サーバー

   セキュアでないターゲット サーバーを定義し、セキュアポート（443 など）を使用しても、 このエラーが発生します。次の手順に従って、この問題の原因かどうかを確認します。

   1. ターゲット エンドポイントの構成で使用されているターゲット サーバーの定義を確認します。

      <ph type="x-smartling-placeholder"></ph> 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>
                      

      ヘルスモニターで <Port> 要素が指定されていないことに注意してください。 構成します。この場合、Edge の Message Processor は、サービス IP アドレスで指定されたポートを ターゲットサーバーの定義は 443 です

   3. 上記の情報によると、このエラーの原因は、ターゲット サーバーが定義されていることです。 非セキュア サーバーと見なされます（SSLInfo ブロックが定義されていないため）。ただし、セキュアポート 443 を使用します。

      つまり、Edge は、ヘルスチェックをセキュアポート 443 を使用して非セキュア呼び出しとして行い、失敗します。 上のエラーで示されます。

   セキュアでないターゲットのセキュア HM ポート

   シナリオ 2: セキュアでないターゲット サーバーが定義されているが、Health Monitor にセキュアなポートが構成されている

   セキュアでないターゲット サーバーを定義しても、Health Monitor が 443 などのセキュア ポートで構成されている場合、 このエラーが発生します。次の手順に従って、この問題の原因かどうかを確認します。

   1. ターゲット エンドポイントの構成で使用されているターゲット サーバーの定義を確認します。

      <ph type="x-smartling-placeholder"></ph> Get TargetServer API を使用して、ターゲット サーバーの定義を取得します。

      ターゲット サーバー定義の出力

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

      上記の例では、ターゲット サーバー mocktarget が非セキュアであることを示しています。 （SSLInfo ブロックがないため）にセキュアでないポート 80 が構成されています。

   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> 要素で示されているように、Health Monitor は安全なポート 443 で構成されています。

   3. 上記の情報によると、このエラーの原因は、ターゲット サーバーが次のように定義されていることです。 セキュアでないポート 80 を持つ非セキュア サーバー（SSLInfo ブロックが定義されていないため） ただし、Health Monitor は、セキュアなポート 443（<Port> 要素で指定）を使用してヘルスチェックを実行するように構成されています。

      つまり、この場合、Edge はヘルスチェックをセキュアポート 443 を使用して非セキュア呼び出しとして行い、前述のエラーで失敗します。

解決策

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

原因: ヘルスチェック API がエラーを返す

診断

1. 失敗したリクエストのメッセージ ID を特定する。
2. Message Processor ログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）でメッセージ ID を検索します。
3. メッセージ ID に対応する一般的なエラー メッセージが表示されます。 ただし、ヘルスチェックの失敗の実際の原因を確認するには、これらの 一般的なエラー メッセージを調べて、ヘルスモニターのエラー/警告がないか確認します。

   たとえば、次のように 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 プロキシで使用されているターゲット サーバーのカウントに到達した 503 レスポンス コード（エラーコード NoActiveTargets）が表示される。

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. Message Processor ログで、警告メッセージの前に表示されたメッセージを確認します。

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

   このメッセージのヘルスチェック URL をメモします。

2. この URL を Message Processor から直接呼び出して、実際のレスポンスを確認できます。

   curl -i https://mocktarget.apigee.net:443/status/200
             

   Message Processor のログに示されているように、上記の呼び出しからのレスポンスは 404 を返します。

   < HTTP/2 404
             

3. これは、ヘルスチェック URL の直接呼び出しでも、同じレスポンス コード 404 で失敗することを示しています。 これは、ヘルスチェック URL が正しくないか、URL の一部としてアクセスされているリソースが利用できなくなったことを意味します。
4. 上記のヘルスチェック API の例では、Health Monitor の構成で使用されている URL が正しくないために問題が発生しています。 正しい URL は https://mocktarget.apigee.net:443/statuscode/200 であることが判明しました モック ターゲット API。
7. その他のエラー レスポンスを受け取った場合は、 手順は上記と同じです。必要に応じて、バックエンド チームと連携します。

解決策

1. バックエンド サーバーのヘルスチェック API の問題を修正します。
2. 上記の例の問題を解決するには:
1. Health Monitor の構成に含まれる <Path> 要素を、次のように /statuscode/200 に変更します。

   <Path>/statuscode/200</Path>
           

2. API プロキシに変更を保存します。

問題が解決しない場合は、 診断情報の収集が必要な場合。

API Monitoring を使用して問題を診断する

API Monitoring で問題を切り分ける エラー、パフォーマンス、レイテンシの問題とその原因（デベロッパー、 アプリ、API プロキシ、バックエンド ターゲット、または API プラットフォーム。

サンプル シナリオを使用する をご覧ください。たとえば messaging.adaptors.http.flow.NoActiveTargets の件数が増加したときに通知されるようにアラートを設定できます。 検出できます。

診断情報の収集が必要な場合

上記の手順でも問題が解決しない場合は、以下の情報を収集します。 表示されます。Apigee サポートに連絡して共有します。

1. Public Cloud をご利用の場合は、次の情報を提供してください。
1. 組織名
2. 環境名
3. API プロキシ名
4. エラーを再現するための curl コマンドを完了する
5. 503 Service Unavailable（エラーコード NoActiveTargets）を含むリクエストを含むトレース ファイル
2. Private Cloud をご利用の場合は、次の情報を提供してください。 <ph type="x-smartling-placeholder">
   </ph>
   1. 確認された完全なエラー メッセージ
   2. 環境名
   3. API プロキシ バンドル
   4. 503 Service Unavailable（エラーコード NoActiveTargets）を含むリクエストを含むトレース ファイル
   5. NGINX アクセスログ

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

   6. Message Processor のログ

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