Layanan 503 Tidak Tersedia - NoActiveTargets - HealthCheckFailures

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

Video

Lihat video berikut untuk informasi lebih lanjut tentang kesalahan 503:

Video Deskripsi
Memecahkan masalah dan menyelesaikan 503 Service Available - NoActiveTargets Pelajari hal berikut:
  • Pentingnya Server Target dan Pemantau Kesehatan
  • Memecahkan masalah dan menyelesaikan error 503 Service memperkirakan - NoActiveTargets secara real-time yang disebabkan oleh kegagalan health check

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 Service Availability dengan kode error NoActiveTargets biasanya diamati saat Anda menggunakan satu atau beberapa server target dalam konfigurasi endpoint target di Proxy API Anda.

Playbook ini mencakup 503 Service Supported dengan kode error NoActiveTargets yang disebabkan oleh kegagalan health check. Lihat playbook ini untuk mempelajari penyebab lain dari error ini.

Kegagalan health check

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

Jika server target gagal dalam health check, Edge akan menambah jumlah kegagalan server tersebut. Jika jumlah kegagalan health check untuk server tersebut mencapai batas yang telah ditentukan (<MaxFailures>), Message Processor akan mencatat pesan peringatan seperti yang ditunjukkan di bawah ini ke dalam file log-nya:

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 spesifik tersebut. Setelah semua server target yang dikonfigurasi dalam konfigurasi LoadBalancer mencapai jumlah MaxFailure, permintaan API berikutnya akan merespons dengan 503 Service Supported dengan kode error NoActiveTargets.

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

Berikut kemungkinan penyebab kegagalan health check:

Penyebab Deskripsi Siapa yang dapat melakukan langkah-langkah pemecahan masalah
Error Waktu Tunggu Koneksi Habis Pemroses Pesan tidak dapat terhubung ke server target dalam periode waktu tunggu yang ditentukan di konfigurasi LoadBalancer. Pengguna Edge Private Cloud
Permintaan yang Aman di Port yang Tidak Aman
  1. Apakah server target ditetapkan sebagai server yang aman, tetapi dikonfigurasi secara salah dengan port yang tidak aman.
  2. Jika server target ditetapkan sebagai server yang aman, tetapi monitor kondisi dikonfigurasi untuk melakukan health check pada port yang tidak aman.
Pengguna Edge Private Cloud
Permintaan Non-Aman pada Port Aman
  1. Apakah server target ditetapkan sebagai server yang tidak aman, tetapi dikonfigurasi secara salah dengan port aman.
  2. Jika server target ditetapkan sebagai server yang tidak aman, tetapi monitor kondisi dikonfigurasi untuk melakukan health check pada port yang aman.
Pengguna Edge Private Cloud
Health Check API merespons dengan error Jika health check API merespons dengan error atau kode respons, apa pun selain yang ditentukan dalam elemen SuccessResponse Health Monitor. Pengguna Edge Private Cloud

Langkah-langkah diagnosis umum

Menentukan ID Pesan dari permintaan yang gagal

Alat pelacak

Untuk menentukan ID pesan dari permintaan yang gagal menggunakan alat Trace:

  1. Aktifkan sesi perekaman aktivitas, lakukan panggilan API, dan rekonstruksi masalah - 503 Service Visible dengan kode error NoActiveTargets.
  2. Pilih salah satu permintaan yang gagal.
  3. Pilih fase AX, dan tentukan ID pesan (X-Apigee.Message-ID) dari permintaan dengan men-scroll ke bawah di bagian Phase Details, seperti ditunjukkan dalam gambar berikut.

    ID Pesan di bagian Tahap Detail

Log akses NGINX

Untuk menentukan ID pesan dari permintaan yang gagal menggunakan log akses NGINX:

Anda juga dapat melihat log Akses NGINX guna menentukan ID pesan untuk error 503. Cara ini sangat berguna jika masalah pernah terjadi sebelumnya, atau jika masalah hanya sesekali dan Anda tidak dapat menangkap rekaman aktivitas di UI. Gunakan langkah-langkah berikut untuk menentukan informasi ini dari log akses NGINX:

  1. Periksa log akses NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. Telusuri apakah ada Error 503 untuk proxy API tertentu selama durasi tertentu (jika masalah terjadi sebelumnya) atau apakah ada permintaan yang masih gagal dengan 503.
  3. Jika terdapat Error 503 pada X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, catat ID pesan untuk satu atau beberapa permintaan seperti yang ditunjukkan pada contoh berikut:

    Contoh Entri yang menampilkan Error 503

    Contoh entri yang menunjukkan kode status, ID pesan, sumber kesalahan, dan kode kesalahan

Pesan error yang umum

Jika server target digunakan dan error terjadi saat Message Processor mencoba terhubung dengan server backend, Anda akan melihat beberapa pesan error umum dalam log Pemroses Pesan. Error ini dicatat ke dalam log setelah pesan pengecualian/error aktual yang menyebabkan kegagalan.

Pesan error umum yang diamati di log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log) untuk 503 Service Available 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 adanya kegagalan. Akibatnya, Pemroses Pesan mengirimkan 503 Service Supported dengan kode error NoActiveTargets sebagai responsnya terhadap klien.

Penyebab: Waktu tunggu koneksi habis

Diagnosis

  1. Tentukan ID pesan dari permintaan yang gagal.
  2. Telusuri ID pesan di log Message Processor (/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 kegagalan health check, scroll di atas pesan error umum ini dan periksa apakah ada Error PEMANTAU KESEHATAN.

    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 sebanyak MaxFailure kali yang dikonfigurasi dalam 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu tempat Anda mengalami 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 setiap Pemroses Pesan menggunakan perintah telnet:
  5. telnet <BackendServer-HostName> 443
          
  6. Jika Anda dapat terhubung ke server backend, Anda mungkin melihat pesan seperti connected to backend-server. Maka, masalahnya mungkin bersifat sementara dan mungkin telah terselesaikan atau merupakan masalah yang bersifat sementara. Ulangi langkah 4 beberapa kali (10+ kali) dan verifikasi output.
    1. Jika tidak ada error secara konsisten pada perintah telnet, masalah akan terselesaikan. Memeriksa kembali apakah kegagalan health check telah berhenti. Jika ya, Anda tidak perlu melakukan apa pun.
    2. Jika Anda tidak dapat terhubung ke server backend dengan perintah telnet sesekali, mungkin ada masalah jaringan atau server backend Anda mungkin sibuk.
  7. Jika Anda tidak dapat terhubung ke server backend dengan perintah telnet secara konsisten, hal ini mungkin karena traffic tidak diizinkan dari Prosesor Pesan di server backend tertentu.

Resolusi

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

Jika masalah masih berlanjut, hubungi administrator Jaringan Anda untuk menentukan dan memperbaikinya. Jika Anda memerlukan bantuan lebih lanjut dari Apigee, hubungi Dukungan Apigee.

Penyebab: Permintaan aman pada port yang tidak aman

Diagnosis

  1. Tentukan ID pesan dari permintaan yang gagal.
  2. Telusuri ID pesan di log Message Processor (/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 kegagalan health check, scroll di atas pesan error umum ini dan periksa apakah ada Error PEMANTAU KESEHATAN.

    Misalnya, Anda mungkin melihat error PEMANTAU KESEHATAN seperti yang ditunjukkan di bawah:

    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 dikonfigurasi dalam 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu tempat Anda mengalami 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 error dan URL menunjukkan penyebab masalah ini adalah panggilan aman (HTTPS) dilakukan di port 80 tidak aman.

    Error ini dapat terjadi dalam dua skenario berikut:

    • Server target aman yang ditetapkan dengan porta yang tidak aman
    • Server target aman telah ditentukan, tetapi Health Monitor dikonfigurasi dengan port yang tidak aman

    Porta target tidak aman yang tidak aman

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

    Jika Anda telah menentukan server target yang aman tetapi memiliki port yang tidak aman seperti 80, Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal tersebut merupakan penyebab masalah ini:

    1. Periksa definisi server target yang digunakan dalam konfigurasi endpoint target.
    2. Gunakan Get 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 aman seperti yang ditunjukkan oleh blok SSLInfo. Namun, konfigurasi ini dikonfigurasi dengan Port 80 yang tidak aman.

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

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

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

    4. 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 target tidak aman yang tidak aman

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

    Jika Anda telah menentukan server target yang aman, tetapi Health Monitor dikonfigurasi dengan port tidak aman seperti 80, error ini akan muncul. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal tersebut merupakan penyebab masalah ini:

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

      Gunakan Get 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 dalam konfigurasi endpoint target:

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

      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 ditetapkan 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 port 80 yang tidak aman dan gagal dengan error yang disebutkan di atas.

Resolusi

Porta target tidak aman yang tidak aman

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

Untuk memperbaiki error ini, perbarui definisi server target agar menggunakan port aman yang sesuai.

Gunakan Update a TargetServer API untuk memperbarui definisi server target dan memastikan bahwa port aman (misalnya: 443) digunakan seperti yang ditunjukkan dalam contoh di bawah ini:

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

Port HM target tidak aman yang tidak aman

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

Untuk memperbaiki error ini, ikuti petunjuk di bawah:

  1. Ubah konfigurasi Health Monitor agar menggunakan port yang aman (misalnya: 443) untuk melakukan health check server target dalam konfigurasi endpoint target Proxy API yang gagal seperti yang ditunjukkan di bawah ini:
    <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. Simpan perubahan ke Proxy API.

Penyebab: Permintaan yang tidak aman pada port yang aman

Diagnosis

  1. Tentukan ID pesan dari permintaan yang gagal.
  2. Telusuri ID pesan di log Message Processor (/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 kegagalan health check, scroll di atas pesan error umum ini dan periksa apakah ada Error PEMANTAU KESEHATAN.

    Misalnya, Anda mungkin melihat error PEMANTAU KESEHATAN seperti yang ditunjukkan di bawah:

    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 dikonfigurasi dalam 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu tempat Anda mengalami 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 error dan URL yang menunjukkan penyebab masalah ini adalah panggilan tidak aman (HTTP) dilakukan pada port aman 443.

    Error ini dapat terjadi dalam dua skenario berikut:

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

    Port aman target yang tidak aman

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

    Jika Anda telah menetapkan server target yang tidak aman tetapi dengan port aman seperti 443, Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal tersebut merupakan penyebab masalah ini:

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

      Gunakan Get 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, konfigurasi ini tidak dikonfigurasi dengan benar dengan Port 443 yang aman.

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

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

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

    3. Berdasarkan informasi di atas, penyebab error ini adalah server target ditetapkan sebagai server 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 yang tidak aman

    Skenario 2: Menentukan server target yang tidak aman, tetapi Health Monitor dikonfigurasi dengan port yang aman

    Jika Anda telah menentukan server target yang tidak aman, tetapi Health Monitor dikonfigurasi dengan port aman seperti 443, Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal tersebut merupakan penyebab masalah ini:

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

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

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

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

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

      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 ditetapkan 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 aman 443 (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

Port aman target yang tidak aman

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

Untuk memperbaiki error ini, perbarui definisi server target agar menggunakan port aman yang sesuai.

Gunakan Update a Target Server API untuk mengupdate definisi server target dan memastikan bahwa port yang tidak aman (misalnya: 80) digunakan seperti yang ditunjukkan dalam contoh di bawah:

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

Port HM aman target yang tidak aman

Skenario 2: Menentukan server target yang tidak aman, tetapi Health Monitor dikonfigurasi dengan port yang aman

Untuk memperbaiki error ini, ikuti petunjuk di bawah:

  1. Hapus elemen <Port> dari konfigurasi Health Monitor atau ubah konfigurasi Health Monitor agar menggunakan port yang tidak aman (misalnya: 80) untuk melakukan health check server target dalam konfigurasi endpoint target Proxy API yang gagal seperti yang ditunjukkan di bawah ini:
    <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. Simpan perubahan ke Proxy API.

Penyebab: Health check API merespons dengan error

Diagnosis

  1. Tentukan ID pesan dari permintaan yang gagal.
  2. Telusuri ID pesan di log Message Processor (/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 kegagalan health check, scroll di atas pesan error umum ini dan periksa apakah ada Error/Peringatan HEALTH MONITOR.

    Misalnya, Anda mungkin melihat peringatan PEMANTAU KESEHATAN seperti yang ditunjukkan di bawah:

    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 dikonfigurasi dalam 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan di Proxy API tertentu tempat Anda mengalami 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 API health check 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 mengapa Edge mengharapkan kode respons sebagai 200 untuk health check API. Untuk melakukannya, periksa konfigurasi Health Monitor untuk server target dalam konfigurasi endpoint target:

    Konfigurasi Health Monitor

    <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 bagian elemen <SuccessResponse>. Artinya, jika Edge mendapatkan kode respons (seperti 400, 401, 404, 500) selain 200 dari health check API, Edge akan diperlakukan sebagai error dan 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 Message Processor.
      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 hasil 404 seperti yang terlihat dalam log Message Processor:

      < HTTP/2 404
                
    3. Hal ini menunjukkan bahwa, panggilan langsung ke URL health check pun akan 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 diketahui adalah https://mocktarget.apigee.net:443/statuscode/200 dari Mock Target API.
  7. Jika Anda mendapatkan respons error lain, tentukan penyebab error tersebut dengan mengikuti langkah-langkah di atas. Jika diperlukan, bekerja samalah dengan tim backend Anda.

Resolusi

  1. Perbaiki masalah terkait health check API 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 ini:
      <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 area masalah dengan cepat untuk mendiagnosis masalah error, performa, dan latensi beserta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Ikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx pada API Anda menggunakan API Monitoring. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan yang akan dikirimkan saat jumlah kesalahan messaging.adaptors.http.flow.NoActiveTargets melebihi batas tertentu.

Harus mengumpulkan informasi diagnostik

Jika masalah terus berlanjut bahkan setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut. 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 detail migrasi yang berisi permintaan dengan 503 Service Available with kode error NoActiveTargets
  2. Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
    1. Pesan Error Lengkap yang diamati
    2. Nama Lingkungan
    3. Paket Proxy API
    4. File detail migrasi yang berisi permintaan dengan 503 Service Available with 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)