Layanan 503 Tidak Tersedia - NoActiveTargets - HealthCheckFailures

Anda sedang melihat dokumentasi Apigee Edge.
Buka Dokumentasi Apigee X. info

Video

Lihat video berikut untuk informasi selengkapnya tentang error 503:

Gejala

Aplikasi klien menerima kode status respons HTTP 503 dengan pesan Service available dan kode error NoActiveTargets untuk permintaan proxy API.

Pesan error

Anda akan melihat respons error berikut:

HTTP/1.1 503 Service Unavailable
  

Anda akan melihat pesan error berikut dalam respons HTTP:

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

Kemungkinan penyebab

Respons HTTP 503 Layanan Tidak Tersedia dengan kode error NoActiveTargets biasanya diamati saat Anda menggunakan satu atau beberapa server target di konfigurasi endpoint target di Proxy API Anda.

Playbook ini membahas Layanan 503 Tidak Tersedia dengan kode error NoActiveTargets yang disebabkan oleh kegagalan health check. Lihat playbook ini untuk mempelajari penyebab lain kesalahan ini.

Kegagalan health check

Kegagalan health check akan diamati hanya jika Anda telah mengonfigurasi Health Monitor sebagai bagian dari konfigurasi load balancing server target di endpoint target Proxy API Anda.

Saat server target gagal dalam health check, Edge akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan health check untuk server tersebut mencapai nilai minimum yang telah ditentukan (<MaxFailures>), Pemroses Pesan mencatat pesan peringatan seperti yang ditunjukkan di bawah ini ke dalam file lognya:

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}
    

Pesan peringatan memberikan informasi berikut. Hal ini membantu Anda memahami server target mana yang mencapai jumlah MaxFailure:

• Nama Server Target
• Nama Organisasi dan Lingkungan
• Nama Proxy API
• Nama Endpoint Target

Setelah itu, Edge berhenti mengirim permintaan lebih lanjut ke server tersebut. Setelah semua target server yang dikonfigurasi di konfigurasi LoadBalancer mencapai jumlah MaxFailure, Permintaan API direspons dengan 503 Service Tidak Tersedia dengan kode error NoActiveTargets.

Penggunaan Health Monitor membantu Apigee Edge menyertakan kembali server target secara otomatis ke dalam ketika sudah responsif, tanpa harus men-deploy ulang Proxy API.

Berikut adalah kemungkinan penyebab kegagalan health check:

Langkah-langkah diagnosis umum

Menentukan ID Pesan dari permintaan yang gagal

Pesan error yang umum

Saat server target digunakan dan terjadi error saat Pemroses Pesan mencoba terhubung dengan server backend, maka Anda akan melihat beberapa pesan {i>error<i} yang umum Log Pemroses Pesan. Error ini dicatat setelah pesan pengecualian/error yang sebenarnya yang menyebabkan kegagalan.

Pesan error umum yang diamati di log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log) untuk Layanan 503 Tidak Tersedia dengan kode error NoActiveTargets adalah sebagai berikut:

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>

Pesan error ini menunjukkan bahwa permintaan tidak dapat dikirim ke server backend karena gagal. Akibatnya, Pemroses Pesan mengirimkan 503 Service available dengan kode error NoActiveTargets sebagai responsnya terhadap klien.

Penyebab: Waktu tunggu koneksi habis

Diagnosis

1. Tentukan ID pesan permintaan yang gagal.
2. Telusuri ID pesan di log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Anda akan melihat pesan error umum yang sesuai dengan ID pesan. Namun, untuk mendapatkan penyebab sebenarnya atas kegagalan health check, scroll ke atas pesan error umum dan periksa apakah ada Error HEALTH MONITOR.

   Misalnya, pesan error HEALTH MONITOR berikut menunjukkan bahwa Pemroses Pesan gagal dengan error waktu koneksi habis saat membuat permintaan API health check:

   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>
           

   Jika error ini berulang selama MaxFailure kali yang dikonfigurasi di Health Monitor, Anda akan melihat pesan peringatan seperti ini:

   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}
           

   Baca informasi yang diberikan dalam pesan peringatan dengan cermat. Pastikan bahwa MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu yang menerima kode respons 503 dengan kode error NoActiveTargets.

4. Pada contoh di atas, health check gagal dengan error connection timed out. Periksa apakah Anda dapat terhubung ke server backend tertentu langsung dari masing-masing Pemroses Pesan menggunakan perintah telnet:

telnet <BackendServer-HostName> 443
      

5. Jika Anda dapat terhubung ke server backend, Anda mungkin melihat pesan seperti Terhubung ke server backend. Lalu, masalahnya mungkin permasalahan sementara dan masalah tersebut mungkin telah diselesaikan atau merupakan masalah yang terputus-putus. Ulangi langkah 4 beberapa kali (10+ kali) dan verifikasi outputnya.
1. Jika tidak ada error dengan perintah telnet secara konsisten, masalahnya adalah diselesaikan. Periksa kembali apakah kegagalan health check telah berhenti. Jika ya, maka Anda tidak perlu melakukan apa pun lebih jauh.
2. Jika Anda tidak dapat terhubung ke server backend dengan perintah telnet sesekali, maka mungkin ada masalah jaringan atau server backend Anda mungkin sibuk.
6. Jika Anda tidak dapat terhubung ke server backend secara konsisten dengan perintah telnet, maka hal ini mungkin karena traffic tidak diizinkan dari Pemroses Pesan di server backend tertentu.

Resolusi

Jika error connection timed out terus-menerus diamati, pastikan backend server tidak memiliki batasan firewall dan mengizinkan traffic dari Pemroses Pesan Edge Apigee. Misalnya, di Linux, Anda dapat menggunakan iptables untuk mengizinkan traffic dari Alamat IP Pemroses Pesan di server backend.

Jika masalah berlanjut, bekerjasamalah dengan Administrator jaringan Anda untuk menentukan dan memperbaiki masalah tersebut. Jika Anda memerlukan bantuan lebih lanjut dari Apigee, hubungi Dukungan Apigee.

Penyebab: Permintaan aman pada port yang tidak aman

Diagnosis

1. Tentukan ID pesan permintaan yang gagal.
2. Telusuri ID pesan di log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Anda akan melihat pesan error umum yang sesuai dengan ID pesan. Namun, untuk mengetahui penyebab sebenarnya atas kegagalan health check, scroll di atas pesan error umum dan periksa apakah ada Error HEALTH MONITOR.

   Misalnya, Anda mungkin melihat pesan error HEALTH MONITOR seperti yang ditunjukkan di bawah ini:

   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>
           

   Jika error ini berulang selama MaxFailure kali yang dikonfigurasi di Health Monitor, Anda akan melihat pesan peringatan seperti ini:

   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}
           

   Baca informasi yang diberikan dalam pesan peringatan dengan cermat. Pastikan bahwa MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu yang menerima kode respons 503 dengan kode error NoActiveTargets.

4. Health check gagal dengan error:

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

   Pesan {i>error<i} dan URL menunjukkan penyebab masalah ini adalah panggilan aman (HTTPS) dilakukan di port 80 yang tidak aman.

   Error ini dapat terjadi dalam dua skenario berikut:

   • Server target aman yang ditentukan dengan port yang tidak aman
   • Server target aman ditentukan tetapi Health Monitor dikonfigurasi dengan port yang tidak aman

   Port tidak aman target aman

   Skenario 1: Server target aman yang ditentukan dengan port yang tidak aman

   Jika Anda telah mendefinisikan server target yang aman tetapi dengan porta yang tidak aman seperti 80, maka Anda mendapatkan {i>error<i} ini. Ikuti langkah-langkah di bawah untuk memastikan apakah ini penyebab masalah ini:

   1. Periksa definisi server target yang digunakan dalam konfigurasi endpoint target.

   Gunakan Mendapatkan TargetServer API untuk mendapatkan definisi server target.

   Output Definisi Server Target

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

   Pada contoh di atas, definisi menunjukkan bahwa server target mocktarget adalah server server seperti yang ditunjukkan oleh blok SSLInfo. Namun, server ini dikonfigurasi dengan Port 80 yang tidak aman.

   2. Sekarang, periksa konfigurasi Health Monitor untuk server target di konfigurasi endpoint target:

      Konfigurasi Pemantau Status

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

      Perhatikan bahwa tidak ada elemen <Port> yang ditetapkan dalam Konfigurasi Health Monitor di atas. Dalam hal ini, Pemroses Pesan Edge menggunakan porta yang ditentukan dalam definisi server target (yaitu 80) untuk melakukan panggilan API health check.

   3. Berdasarkan informasi di atas, penyebab error ini adalah server target ditetapkan sebagai server aman (karena blok SSLInfo diaktifkan), tetapi dengan port 80 yang tidak aman.

   Port HM yang tidak aman target aman

   Skenario 2: Server target aman yang ditetapkan, tetapi Health Monitor dikonfigurasi dengan port yang tidak aman

   Jika Anda telah menentukan server target yang aman tetapi {i>Health Monitor<i} dikonfigurasi dengan porta tidak aman seperti 80, maka Anda akan mendapatkan pesan {i>error<i} ini. Ikuti langkah-langkah di bawah untuk memverifikasi jika ini adalah penyebab masalah ini:

   1. Periksa definisi server target yang digunakan dalam konfigurasi endpoint target.

      Gunakan Dapatkan TargetServer API untuk mendapatkan definisi server target.

      Output Definisi Server Target

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

      Pada contoh di atas, definisi menunjukkan bahwa server target mocktarget adalah server aman seperti yang ditunjukkan oleh blok SSLInfo.

   2. Selanjutnya, periksa konfigurasi Health Monitor untuk server target di konfigurasi endpoint target:

      Konfigurasi Pemantau Status

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

      Pada contoh di atas, Health Monitor dikonfigurasi dengan Port 80 yang tidak aman seperti yang ditunjukkan oleh elemen <Port>.

   3. Berdasarkan informasi di atas, penyebab error ini adalah server target ditentukan sebagai server aman (karena blok SSLInfo diaktifkan) dan menggunakan port aman 443, tetapi Health Monitor dikonfigurasi untuk melakukan health check dengan port 80 yang tidak aman (ditentukan dalam elemen <Port>).

      Artinya, dalam hal ini, Edge membuat API health check sebagai panggilan aman dengan item port 80 dan gagal dengan error yang disebutkan di atas.

Resolusi

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

Penyebab: Permintaan tidak aman pada port aman

Diagnosis

1. Tentukan ID pesan permintaan yang gagal.
2. Telusuri ID pesan di log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Anda akan melihat pesan error umum yang sesuai dengan ID pesan. Namun, untuk mengetahui penyebab sebenarnya atas kegagalan health check, scroll di atas pesan error umum dan periksa apakah ada Error HEALTH MONITOR.

   Misalnya, Anda mungkin melihat pesan error HEALTH MONITOR seperti yang ditunjukkan di bawah ini:

   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>
             

   Jika error ini berulang selama MaxFailure kali yang dikonfigurasi di Health Monitor, Anda akan melihat pesan peringatan seperti ini:

   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}
             

   Baca informasi yang diberikan dalam pesan peringatan dengan cermat. Pastikan bahwa MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu yang menerima kode respons 503 dengan kode error NoActiveTargets.

4. Health check gagal dengan error:

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

   Pesan {i>error<i} dan URL menunjukkan penyebab masalah ini adalah non-secure call (HTTP) dilakukan di secure port 443.

   Error ini dapat terjadi dalam dua skenario berikut:

   • Server target tidak aman ditentukan dengan port aman
   • Server target tidak aman sudah ditentukan, tetapi Health Monitor dikonfigurasi dengan port aman

   Port aman target tidak aman

   Skenario 1: Server target tidak aman yang ditentukan dengan port aman

   Jika Anda telah menetapkan server target yang tidak aman tetapi dengan porta aman seperti 443, maka Anda mendapatkan pesan {i>error<i} ini. Ikuti langkah-langkah di bawah untuk memastikan apakah ini penyebab masalah ini:

   1. Periksa definisi server target yang digunakan dalam konfigurasi endpoint target.

      Gunakan Dapatkan TargetServer API untuk mendapatkan definisi server target.

      Output Definisi Server Target

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

      Pada contoh di atas, definisi menunjukkan bahwa server target mocktarget adalah server yang tidak aman karena tidak ada blok SSLInfo. Namun, salah dikonfigurasi dengan Port 443 yang aman.

   2. Sekarang, periksa konfigurasi Health Monitor untuk server target di konfigurasi endpoint target:

      Konfigurasi Pemantau Status

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

      Perhatikan bahwa tidak ada elemen <Port> yang ditentukan dalam Health Monitor konfigurasi di atas. Dalam hal ini, Pemroses Pesan Edge akan menggunakan porta yang ditentukan dalam definisi server target yaitu 443.

   3. Berdasarkan informasi di atas, penyebab error ini adalah server target ditentukan sebagai server yang tidak aman (karena blok SSLInfo tidak ditentukan), tetapi dengan port aman 443.

      Artinya, Edge membuat health check sebagai panggilan tidak aman dengan port aman 443 dan gagal dengan error yang disebutkan di atas.

   Port HM aman target tidak aman

   Skenario 2: Server target yang tidak aman ditentukan, tetapi Health Monitor dikonfigurasi dengan port aman

   Jika Anda telah menetapkan server target yang tidak aman tetapi {i>Health Monitor<i} dikonfigurasi dengan porta aman seperti 443, maka Anda mendapatkan pesan {i>error<i} ini. Ikuti langkah-langkah di bawah untuk memastikan apakah ini penyebab masalah ini:

   1. Periksa definisi server target yang digunakan dalam konfigurasi endpoint target.

      Gunakan Dapatkan TargetServer API untuk mendapatkan definisi server target.

      Output Definisi Server Target

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

      Pada contoh di atas, definisi menunjukkan bahwa server target mocktarget adalah server tidak aman server (karena tidak ada blok SSLInfo) yang dikonfigurasi dengan port 80 yang tidak aman dengan benar.

   2. Selanjutnya, periksa konfigurasi Health Monitor untuk server target di konfigurasi endpoint target:

      Konfigurasi Pemantau Status

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

      Pada contoh di atas, Health Monitor dikonfigurasi dengan Port 443 aman seperti yang ditunjukkan oleh elemen <Port>.

   3. Berdasarkan informasi di atas, penyebab error ini adalah server target didefinisikan sebagai server yang tidak aman (karena blok SSLInfo tidak ditentukan) dengan port 80 yang tidak aman dengan benar, tetapi Health Monitor dikonfigurasi untuk melakukan health check dengan port 443 aman (ditentukan dalam elemen <Port>).

      Artinya, dalam hal ini, Edge membuat health check sebagai panggilan tidak aman dengan port aman 443 dan gagal dengan error yang disebutkan di atas.

Resolusi

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

Penyebab: Health check API merespons dengan error

Diagnosis

1. Tentukan ID pesan permintaan yang gagal.
2. Telusuri ID pesan di log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Anda akan melihat pesan error umum yang sesuai dengan ID pesan. Namun, untuk mengetahui penyebab sebenarnya atas kegagalan health check, scroll di atas pesan error umum dan periksa apakah ada Error/Peringatan HEALTH MONITOR.

   Misalnya, Anda mungkin melihat peringatan HEALTH MONITOR seperti yang ditunjukkan di bawah ini:

   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
           

   Jika error ini berulang selama MaxFailure kali yang dikonfigurasi di Health Monitor, Anda akan melihat pesan peringatan seperti ini:

   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}
           

   Baca informasi yang diberikan dalam pesan peringatan dengan cermat. Pastikan bahwa MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu yang menerima kode respons 503 dengan kode error NoActiveTargets.

4. Health check menampilkan pesan peringatan:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   Pesan peringatan di atas menyatakan bahwa kode respons yang diharapkan untuk health check API adalah 200, tetapi respons sebenarnya yang diterima adalah 404. Oleh karena itu, tindakan ini dianggap sebagai kegagalan.

5. Sebelum menyelidiki penyebab respons error dari health check API, tentukan alasan Edge mengharapkan kode respons sebagai 200 untuk API health check. Untuk itu, periksa Health Monitor untuk server target dalam konfigurasi endpoint target:

   Konfigurasi Pemantau Status

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

   Perhatikan bahwa konfigurasi Health Monitor dikonfigurasi dengan kode respons 200 di bawah elemen <SuccessResponse>. Artinya, jika Edge mendapatkan kode respons (seperti 400, 401, 404, 500) selain 200 dari API health check, hal itu akan dianggap sebagai {i>error<i} dan akan menambah jumlah kegagalan.

6. Sekarang, untuk menyelidiki penyebab respons error dari health check API, ikuti langkah-langkah di bawah ini:
1. Lihat pesan sebelum pesan peringatan di log Pemroses Pesan.

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

   Catat URL health check dari pesan ini.

2. Anda dapat melakukan panggilan langsung ke URL ini dari Pemroses Pesan dan memeriksa respons yang sebenarnya

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

   Respons dari panggilan di atas memberikan 404 seperti yang terlihat dalam log Pemroses Pesan:

   < HTTP/2 404
             

3. Hasil ini menunjukkan bahwa panggilan langsung ke URL health check pun gagal dengan kode respons 404 yang sama. Artinya, URL health check mungkin salah atau resource yang diakses sebagai bagian dari URL tidak lagi tersedia.
4. Pada contoh Health Check API yang diberikan di atas, masalah terjadi karena URL yang salah digunakan dalam konfigurasi Health Monitor. URL yang benar ditemukan https://mocktarget.apigee.net:443/statuscode/200 dari API Target Tiruan.
7. Jika Anda mendapatkan respons error lainnya, tentukan penyebab error tersebut dengan mengikuti langkah-langkah di atas. Jika diperlukan, bekerja samalah dengan tim backend Anda.

Resolusi

1. Perbaiki masalah terkait API health check di server backend Anda.
2. Untuk memperbaiki masalah dalam contoh yang dibahas di atas:
1. Ubah elemen <Path> dalam konfigurasi Health Monitor menjadi /statuscode/200 seperti yang ditunjukkan di bawah:

   <Path>/statuscode/200</Path>
           

2. Simpan perubahan di Proxy API.

Jika masalah masih berlanjut, buka Harus Mengumpulkan Informasi Diagnostik.

Mendiagnosis masalah menggunakan pemantauan API

Pemantauan API memungkinkan Anda mengisolasi masalah area dengan cepat untuk mendiagnosis masalah error, performa, dan latensi beserta sumbernya, seperti masalah aplikasi, proxy API, target backend, atau platform API.

Mengikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx dengan API menggunakan Pemantauan API. Misalnya, Anda perlu menyiapkan peringatan yang akan diberi tahu ketika jumlah messaging.adaptors.http.flow.NoActiveTargets kesalahan melebihi batas tertentu.

Harus mengumpulkan informasi diagnostik

Jika masalah berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi berikut informasi diagnostik. Hubungi dan bagikan ke Dukungan Apigee:

1. Jika Anda adalah pengguna Cloud Publik, berikan informasi berikut:
1. Nama Organisasi
2. Nama Lingkungan
3. Nama Proxy API
4. Menyelesaikan perintah curl untuk mereproduksi error
5. File rekaman aktivitas yang berisi permintaan dengan Layanan 503 Tidak Tersedia dengan kode error NoActiveTargets
2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
   1. Pesan Error Lengkap diamati
   2. Nama Lingkungan
   3. Paket Proxy API
   4. File rekaman aktivitas yang berisi permintaan dengan Layanan 503 Tidak Tersedia dengan kode error NoActiveTargets
   5. Log Akses NGINX

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

   6. Log Pemroses Pesan

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