Layanan 503 Tidak Tersedia - NoActiveTargets - HealthCheckFailures

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

Video

Tonton video berikut untuk mengetahui informasi selengkapnya tentang error 503:

Video Deskripsi
Memecahkan masalah dan mengatasi 503 Service Unavailable - NoActiveTargets Pelajari hal-hal berikut:
  • Pentingnya Server Target dan Pemeriksaan Kondisi
  • Memecahkan masalah dan menyelesaikan error 503 Layanan Tidak Tersedia - NoActiveTargets real-time yang disebabkan oleh kegagalan health check

Gejala

Aplikasi klien menerima kode status respons HTTP 503 dengan pesan Service Unavailable 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 Unavailable dengan kode error NoActiveTargets biasanya diamati saat Anda menggunakan satu atau beberapa server target dalam konfigurasi endpoint target di Proxy API.

Playbook ini membahas 503 Service Unavailable dengan kode error NoActiveTargets yang disebabkan oleh kegagalan pemeriksaan kondisi. Lihat playbook ini untuk mempelajari penyebab lain terjadinya 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 pemeriksaan kondisi server tersebut mencapai nilai minimum yang telah ditentukan sebelumnya (<MaxFailures>), Prosesor Pesan akan mencatat pesan peringatan seperti yang ditunjukkan di bawah 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. Metrik 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 mengirimkan permintaan lebih lanjut ke server tertentu tersebut. Setelah semua server target yang dikonfigurasi dalam konfigurasi LoadBalancer mencapai jumlah MaxFailure, permintaan API berikutnya akan direspon dengan 503 Service Unavailable dengan kode error NoActiveTargets.

Menggunakan Health Monitor membantu Apigee Edge untuk otomatis menyertakan kembali server target ke dalam rotasi saat server tersebut menjadi 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 Message Processor tidak dapat terhubung ke server target dalam periode waktu tunggu yang ditentukan dalam konfigurasi LoadBalancer. Pengguna Edge Private Cloud
Permintaan Aman di Port Tidak Aman
  1. Jika server target ditentukan sebagai server aman, tetapi dikonfigurasi secara salah dengan port yang tidak aman.
  2. Jika server target ditentukan sebagai server yang aman, tetapi monitor kondisi dikonfigurasi untuk melakukan health check pada port yang tidak aman.
Pengguna Edge Private Cloud
Permintaan Tidak Aman di Port Aman
  1. Jika server target ditentukan sebagai server tidak aman, tetapi salah dikonfigurasi dengan port aman.
  2. Jika server target ditentukan sebagai server tidak aman, tetapi monitor kondisi dikonfigurasi untuk melakukan health check pada port aman.
Pengguna Edge Private Cloud
Health Check API merespons dengan error Jika API health check merespons dengan error atau kode respons, selain yang ditentukan dalam elemen SuccessResponse dari Health Monitor. Pengguna Edge Private Cloud

Langkah-langkah diagnosis umum

Menentukan ID Pesan dari permintaan yang gagal

Alat rekaman aktivitas

Untuk menentukan ID pesan permintaan yang gagal menggunakan alat Trace:

  1. Aktifkan sesi rekaman aktivitas, lakukan panggilan API, dan reproduksi masalah - 503 Service Unavailable dengan kode error NoActiveTargets.
  2. Pilih salah satu permintaan yang gagal.
  3. Buka fase AX, dan tentukan ID pesan (X-Apigee.Message-ID) permintaan dengan men-scroll ke bawah di bagian Detail Fase seperti yang ditunjukkan pada gambar berikut.

    ID Pesan di bagian Detail Fase

Log akses NGINX

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

Anda juga dapat merujuk ke log Akses NGINX untuk menentukan ID pesan untuk error 503. Hal ini sangat berguna jika masalah telah terjadi di masa lalu atau jika masalah bersifat tidak tetap dan Anda tidak dapat merekam 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. Cari apakah ada Error 503 untuk proxy API tertentu selama durasi tertentu (jika masalah terjadi di masa lalu) atau apakah ada permintaan yang masih gagal dengan 503.
  3. Jika ada Error 503 dengan X-Apigee-fault-code messaging.adaptors.http.flow.NoActiveTargets, catat ID pesan untuk satu atau beberapa permintaan tersebut seperti yang ditunjukkan dalam contoh berikut:

    Contoh Entri yang menampilkan Error 503

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

Pesan error yang umum

Saat server target digunakan dan terjadi error saat Message Processor mencoba terhubung dengan server backend, Anda akan melihat beberapa pesan error umum di log Message Processor. Error ini dicatat setelah pesan error/pengecualian sebenarnya yang menyebabkan kegagalan.

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

Penyebab: Waktu tunggu koneksi habis

Diagnosis

  1. Tentukan ID pesan permintaan yang gagal.
  2. Cari 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 ke atas pesan error umum ini dan periksa apakah ada Error HEALTH MONITOR.

    Misalnya, pesan error HEALTH MONITOR berikut menunjukkan bahwa Message Processor 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, maka 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 dalam Proxy API tertentu yang mengalami kode respons 503 dengan kode error NoActiveTargets.

  4. Dalam contoh di atas, health check gagal dengan error connection timed out. Periksa apakah Anda dapat terhubung ke server backend tertentu secara langsung dari setiap Prosesor Pesan menggunakan perintah telnet:
  5. telnet <BackendServer-HostName> 443
          
  6. Jika Anda dapat terhubung ke server backend, Anda mungkin akan melihat pesan seperti Connected to backend-server. Kemudian, masalah tersebut mungkin bersifat sementara dan mungkin telah teratasi atau merupakan masalah yang muncul sesekali. Ulangi langkah 4 beberapa kali (10+ kali) dan verifikasi outputnya.
    1. Jika tidak ada error dengan perintah telnet secara konsisten, berarti masalah telah terselesaikan. Periksa ulang apakah kegagalan health check telah berhenti. Jika ya, Anda tidak perlu melakukan apa pun lagi.
    2. Jika Anda tidak dapat terhubung ke server backend dengan perintah telnet secara berkala, maka mungkin ada masalah jaringan atau server backend Anda sedang sibuk.
  7. Jika Anda tidak dapat terhubung ke server backend dengan perintah telnet secara konsisten, maka hal ini mungkin disebabkan karena traffic tidak diizinkan dari Pemroses Pesan di server backend tertentu.

Resolusi

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

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

Penyebab: Permintaan aman di port tidak aman

Diagnosis

  1. Tentukan ID pesan permintaan yang gagal.
  2. Cari 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 ke atas pesan error umum ini dan periksa apakah ada Error HEALTH MONITOR.

    Misalnya, Anda dapat melihat 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang 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 bahwa 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 tidak aman
    • Server target yang aman ditentukan, tetapi Health Monitor dikonfigurasi dengan port yang tidak aman

    Menyematkan target port tidak aman

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

    Jika Anda telah menentukan server target yang aman tetapi dengan port yang tidak aman seperti 80, maka Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal ini adalah 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>
                

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

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

      Konfigurasi Pemantau Kondisi

      <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, Message Processor 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 ditentukan sebagai server aman (karena blok SSLInfo diaktifkan), tetapi dengan port 80 yang tidak aman.

    Mengamankan port HM target yang tidak aman

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

    Jika Anda telah menentukan server target yang aman, tetapi Health Monitor dikonfigurasi dengan port yang tidak aman seperti 80, Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal ini menjadi 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>
              

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

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

      Konfigurasi Pemantau Kondisi

      <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 tidak aman 80 (ditentukan dalam elemen <Port>).

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

Resolusi

Menyematkan target port tidak aman

Skenario 1: Server target aman yang ditentukan dengan port 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 yang aman (misalnya: 443) digunakan seperti yang ditunjukkan dalam contoh di bawah:

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

Mengamankan port HM target yang tidak aman

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

Untuk memperbaiki error ini, ikuti petunjuk di bawah:

  1. Ubah konfigurasi Health Monitor untuk menggunakan port yang aman (misalnya: 443) untuk melakukan pemeriksaan kondisi server target dalam konfigurasi endpoint target API Proxy 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 pada Proxy API.

Penyebab: Permintaan tidak aman di port aman

Diagnosis

  1. Tentukan ID pesan permintaan yang gagal.
  2. Cari 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 ke atas pesan error umum ini dan periksa apakah ada Error HEALTH MONITOR.

    Misalnya, Anda dapat melihat 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang 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 menunjukkan bahwa penyebab masalah ini adalah panggilan tidak aman (HTTP) dilakukan di port 443 yang aman.

    Error ini dapat terjadi dalam dua skenario berikut:

    • Server target tidak aman yang ditentukan dengan port aman
    • Server target tidak aman 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 menentukan server target yang tidak aman, tetapi dengan port yang aman seperti 443, maka Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal ini adalah 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>
                    

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

      Konfigurasi Pemantau Kondisi

      <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, Message Processor Edge akan menggunakan port 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 443 yang aman.

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

    Port HM aman target tidak aman

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

    Jika Anda telah menentukan server target yang tidak aman, tetapi Health Monitor dikonfigurasi dengan port aman seperti 443, maka Anda akan mendapatkan error ini. Ikuti langkah-langkah di bawah untuk memverifikasi apakah hal ini adalah 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 yang tidak aman (karena tidak ada blok SSLInfo) yang dikonfigurasi dengan port 80 yang tidak aman dengan benar.

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

      Konfigurasi Pemantau Kondisi

      <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 yang aman seperti yang ditunjukkan oleh elemen <Port>.

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

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

Resolusi

Port aman target 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 memperbarui 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 tidak aman

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

Untuk memperbaiki error ini, ikuti petunjuk di bawah:

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

Penyebab: Health check API merespons dengan error

Diagnosis

  1. Tentukan ID pesan permintaan yang gagal.
  2. Cari 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 ke atas pesan error umum ini dan periksa apakah ada Error/Peringatan HEALTH MONITOR.

    Misalnya, Anda mungkin melihat peringatan HEALTH MONITOR 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 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 jumlah MaxFailure telah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang mengalami kode respons 503 dengan kode error NoActiveTargets.

  4. Pemeriksaan kondisi 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 yang diterima adalah 404. Oleh karena itu, hal ini dianggap sebagai kegagalan.

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

    Konfigurasi Pemantau Kondisi

    <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 elemen <SuccessResponse>. Artinya, jika Edge mendapatkan kode respons (seperti 400, 401, 404, 500) selain 200 dari API health check, kode tersebut akan dianggap 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 sebenarnya
      curl -i https://mocktarget.apigee.net:443/status/200
                

      Respons dari panggilan di atas memberikan 404 seperti yang terlihat dalam log Message Processor:

      < HTTP/2 404
                
    3. Hal ini menunjukkan bahwa bahkan panggilan langsung ke URL health check gagal dengan kode respons 404 yang sama. Artinya, URL pemeriksaan kondisi mungkin salah atau resource yang diakses sebagai bagian dari URL tidak lagi tersedia.
    4. Dalam contoh API health check yang diberikan di atas, masalah terjadi karena URL yang salah digunakan dalam konfigurasi Health Monitor. URL yang benar adalah https://mocktarget.apigee.net:443/statuscode/200 dari Mock Target API.
  7. Jika Anda mendapatkan respons error lainnya, tentukan penyebabnya dengan mengikuti langkah-langkah di atas. Jika diperlukan, bekerjasamalah dengan tim backend Anda.

Resolusi

  1. Perbaiki masalah pada API pemeriksaan kondisi 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 Must Gather Diagnostic Information.

Mendiagnosis masalah menggunakan pemantauan API

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

Ikuti langkah-langkah dalam contoh skenario yang menunjukkan cara memecahkan masalah 5xx dengan API Anda menggunakan Pemantauan API. Misalnya, Anda dapat menyiapkan pemberitahuan untuk menerima notifikasi saat jumlah kesalahan messaging.adaptors.http.flow.NoActiveTargets melebihi batas tertentu.

Harus mengumpulkan informasi diagnostik

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

  1. Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:
    1. Nama Organisasi
    2. Nama Lingkungan
    3. Nama Proxy API
    4. Perintah curl lengkap untuk mereproduksi error
    5. File rekaman aktivitas yang berisi permintaan dengan 503 Service Unavailable dengan 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 rekaman aktivitas yang berisi permintaan dengan 503 Service Unavailable dengan kode error NoActiveTargets
    5. Log Akses NGINX

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

    6. Log Message Processor

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