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:
|
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 |
|
Pengguna Edge Private Cloud |
| Permintaan Tidak Aman di 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:
- Aktifkan sesi rekaman aktivitas, lakukan panggilan API, dan reproduksi masalah - 503 Service Unavailable dengan kode error NoActiveTargets.
- Pilih salah satu permintaan yang gagal.
- 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.
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:
- Periksa log akses NGINX: (
/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log) - 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.
- 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
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
- Tentukan ID pesan permintaan yang gagal.
- Cari ID pesan di log Message Processor (
/opt/apigee/var/log/edge-message-processor/logs/system.log). - 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
MaxFailurekali 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
MaxFailuretelah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang mengalami kode respons 503 dengan kode error NoActiveTargets. - 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 perintahtelnet: - 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.
- Jika tidak ada error dengan perintah
telnetsecara konsisten, berarti masalah telah terselesaikan. Periksa ulang apakah kegagalan health check telah berhenti. Jika ya, Anda tidak perlu melakukan apa pun lagi. - Jika Anda tidak dapat terhubung ke server backend dengan perintah
telnetsecara berkala, maka mungkin ada masalah jaringan atau server backend Anda sedang sibuk. - Jika Anda tidak dapat terhubung ke server backend dengan perintah
telnetsecara konsisten, maka hal ini mungkin disebabkan karena traffic tidak diizinkan dari Pemroses Pesan di server backend tertentu.
telnet <BackendServer-HostName> 443
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
- Tentukan ID pesan permintaan yang gagal.
- Cari ID pesan di log Message Processor (
/opt/apigee/var/log/edge-message-processor/logs/system.log). - 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
MaxFailurekali 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
MaxFailuretelah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang mengalami kode respons 503 dengan kode error NoActiveTargets. - 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:
- Periksa definisi server target yang digunakan dalam konfigurasi endpoint target.
- 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. - 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.
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
mocktargetadalah server yang aman seperti yang ditunjukkan oleh blok SSLInfo. Namun, server ini dikonfigurasi 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:
- 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
mocktargetadalah server yang aman seperti yang ditunjukkan oleh blok SSLInfo. - 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>. - 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:
- 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> - Simpan perubahan pada Proxy API.
Penyebab: Permintaan tidak aman di port aman
Diagnosis
- Tentukan ID pesan permintaan yang gagal.
- Cari ID pesan di log Message Processor (
/opt/apigee/var/log/edge-message-processor/logs/system.log). - 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
MaxFailurekali 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
MaxFailuretelah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang mengalami kode respons 503 dengan kode error NoActiveTargets. - Health check gagal dengan error:
Error sending request Request URL : http://mocktarget.apigee.net:443/status java.net.SocketException: Unexpected end of file from serverPesan 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:
- 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
mocktargetadalah server yang tidak aman karena tidak ada blok SSLInfo. Namun, salah dikonfigurasi dengan Port 443 yang aman. - 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. - 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:
- 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
mocktargetadalah server yang tidak aman (karena tidak ada blok SSLInfo) yang dikonfigurasi dengan port 80 yang tidak aman dengan benar. - 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>. - 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:
- 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> - Simpan perubahan pada Proxy API.
Penyebab: Health check API merespons dengan error
Diagnosis
- Tentukan ID pesan permintaan yang gagal.
- Cari ID pesan di log Message Processor (
/opt/apigee/var/log/edge-message-processor/logs/system.log). - 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 : 404Jika error ini berulang selama
MaxFailurekali 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
MaxFailuretelah tercapai untuk server target yang digunakan dalam Proxy API tertentu yang mengalami kode respons 503 dengan kode error NoActiveTargets. - Pemeriksaan kondisi menampilkan pesan peringatan:
HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404Pesan 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.
- 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. - Sekarang, untuk menyelidiki penyebab respons error dari health check API, ikuti langkah-langkah di bawah ini:
- 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/200Catat URL health check dari pesan ini.
- Anda dapat melakukan panggilan langsung ke URL ini dari Pemroses Pesan dan memeriksa respons sebenarnya
curl -i https://mocktarget.apigee.net:443/status/200Respons dari panggilan di atas memberikan 404 seperti yang terlihat dalam log Message Processor:
< HTTP/2 404 - 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.
- 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/200dari Mock Target API. - Jika Anda mendapatkan respons error lainnya, tentukan penyebabnya dengan mengikuti langkah-langkah di atas. Jika diperlukan, bekerjasamalah dengan tim backend Anda.
Resolusi
- Perbaiki masalah pada API pemeriksaan kondisi di server backend Anda.
- Untuk memperbaiki masalah dalam contoh yang dibahas di atas:
- Ubah elemen
<Path>dalam konfigurasi Health Monitor menjadi/statuscode/200seperti yang ditunjukkan di bawah:<Path>/statuscode/200</Path> - 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:
- Jika Anda adalah pengguna Public Cloud, berikan informasi berikut:
- Nama Organisasi
- Nama Lingkungan
- Nama Proxy API
- Perintah curl lengkap untuk mereproduksi error
- File rekaman aktivitas yang berisi permintaan dengan 503 Service Unavailable dengan kode error NoActiveTargets
- Jika Anda adalah pengguna Private Cloud, berikan informasi berikut:
- Pesan Error Lengkap yang diamati
- Nama Lingkungan
- Paket Proxy API
- File rekaman aktivitas yang berisi permintaan dengan 503 Service Unavailable dengan kode error NoActiveTargets
- Log Akses NGINX
(
/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log) - Log Message Processor
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)