Anda sedang melihat dokumentasi Apigee Edge.
Buka
dokumentasi Apigee X. info
Apigee Edge meningkatkan ketersediaan API Anda dengan memberikan dukungan bawaan untuk load balancing dan failover di beberapa instance server backend.
Konfigurasi TargetServer memisahkan URL endpoint konkret dari konfigurasi TargetEndpoint. Setiap TargetServer direferensikan dengan nama dalam HTTPConnection TargetEndpoint. Daripada menentukan URL konkret dalam konfigurasi, Anda dapat mengonfigurasi satu atau beberapa TargetServers bernama seperti yang dijelaskan di bagian TargetEndpoint.
Definisi TargetServer terdiri dari nama, host, dan port, dengan elemen tambahan untuk menunjukkan apakah TargetServer diaktifkan atau dinonaktifkan.
Video
Tonton video berikut untuk mempelajari lebih lanjut pemilihan rute dan load balancing API menggunakan server target
Video | Deskripsi |
---|---|
Load balancing menggunakan server target | API load balancing di seluruh server target. |
Pemilihan rute API berdasarkan lingkungan menggunakan server target | Merutekan API ke server target yang berbeda berdasarkan lingkungan. |
Pemilihan rute dan load balancing API menggunakan server target (Classic Edge) | Rutekan API ke server target yang berbeda berdasarkan lingkungan dan lakukan load balancing pada API Anda di seluruh server target pada UI Classic Edge. |
Contoh Konfigurasi TargetServer
Kode berikut menentukan server target:
<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >
Elemen Konfigurasi TargetServer
Tabel berikut menjelaskan elemen yang digunakan untuk membuat dan mengonfigurasi TargetServer:
Nama | Deskripsi | Default | Wajib diisi? |
---|---|---|---|
name |
Nama konfigurasi TargetServer, yang harus unik di dalam lingkungan. Nama TargetServer hanya boleh berisi karakter alfanumerik. | T/A | Ya |
Host |
URL host dari layanan backend (tanpa protokol). | T/A | Ya |
Port |
Port tempat layanan backend memproses | T/A | Ya |
IsEnabled |
Boolean yang menunjukkan apakah konfigurasi TargetServer diaktifkan atau dinonaktifkan. Hal ini memungkinkan Anda untuk mengeluarkan TargetServers dari rotasi tanpa mengubah konfigurasi proxy API. Penggunaan yang umum adalah menulis aplikasi atau skrip yang mengaktifkan atau menonaktifkan TargetServers secara otomatis berdasarkan persyaratan kapasitas yang diharapkan, jadwal pemeliharaan, dll. | true |
Ya |
Mengelola server target menggunakan UI
Kelola server target, seperti yang dijelaskan di bawah.
Edge
Untuk mengelola server target menggunakan UI Edge:
- Login ke apigee.com/edge.
- Pilih Admin > Environments > Target Servers di menu navigasi sebelah kiri.
- Pilih lingkungan yang diinginkan, seperti test atau prod.
- Untuk membuat server target:
- Klik + Target server.
- Masukkan nama, host, dan port server target.
Contoh:
- Nama: target1
- Host: 1.mybackendservice.com
- Porta: 80
- Pilih SSL, jika diperlukan.
- Pilih Enabled untuk mengaktifkan server target.
- Klik Tambahkan.
- Untuk mengedit server target:
- Posisikan kursor di atas server target yang ingin Anda edit untuk menampilkan menu tindakan.
- Klik
.
- Edit nilai server targer.
- Klik Perbarui.
- Untuk menghapus server target:
- Posisikan kursor di atas server target yang ingin Anda hapus untuk menampilkan menu tindakan.
- Klik
.
- Klik Hapus untuk mengonfirmasi operasi.
Edge Klasik (Private Cloud)
Untuk mengakses wizard Create Proxy menggunakan UI Classic Edge:
- Login ke
http://ms-ip:9000
, dengan ms-ip yang merupakan alamat IP atau nama DNS node Server Pengelolaan. - Pilih APIs > Environment Configuration > Target Servers di menu navigasi sebelah kiri.
- Pilih lingkungan yang diinginkan, seperti test atau prod.
- Untuk membuat server target:
- Klik Edit.
- Klik + Target server.
- Masukkan nama, host, dan port server target.
Contoh:
- Nama: target1
- Host: 1.mybackendservice.com
- Porta: 80
- Pilih Enabled untuk mengaktifkan server target.
- Klik Simpan.
- Untuk mengedit server target:
- Klik Edit.
- Edit nilai server targer.
- Klik Simpan.
- Untuk menghapus server target:
- Klik Edit.
- Klik Delete.
Mengelola server target menggunakan API
Anda dapat menggunakan Edge API untuk membuat, menghapus, mengupdate, mendapatkan, dan membuat daftar server target. Untuk mengetahui informasi selengkapnya, lihat TargetServers.
Gunakan panggilan API berikut untuk membuat server target:
$ curl -H "Content-Type:text/xml" -X POST -d \ '<TargetServer name="target1"> <Host>1.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Contoh Respons:
{ "host" : "1.mybackendservice.com", "isEnabled" : true, "name" : "target1", "port" : 80 }
Setelah Anda membuat TargetServer pertama, gunakan panggilan API berikut untuk membuat TargetServer kedua. Dengan menentukan dua TargetServers, Anda memberikan dua URL yang dapat digunakan TargetEndpoint untuk load balancing:
$ curl -H "Content-type:text/xml" -X POST -d \ '<TargetServer name="target2"> <Host>2.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer >' \ -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Contoh Respons:
{ "host" : "2.mybackendservice.com", "isEnabled" : true, "name" : "target2", "port" : 80 }
Gunakan panggilan API berikut untuk mengambil daftar TargetServers di lingkungan:
$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers
Contoh tanggapan:
[ "target2", "target1" ]
Kini ada dua TargetServers yang tersedia untuk digunakan oleh proxy API yang di-deploy di lingkungan pengujian. Untuk melakukan load balancing pada traffic di seluruh TargetServers ini, Anda perlu mengonfigurasi koneksi HTTP di endpoint target proxy API untuk menggunakan TargetServers.
Ada batas 500 TargetServer per lingkungan, seperti yang didokumentasikan dalam topik Limits.
Mengonfigurasi TargetEndpoint untuk load balancing di seluruh TargetServers bernama
Setelah memiliki dua TargetServers yang tersedia, Anda dapat memodifikasi setelan koneksi HTTP TargetEndpoint untuk mereferensikan kedua TargetServers tersebut berdasarkan nama:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Konfigurasi di atas adalah konfigurasi load balancing paling dasar. Load balancer mendukung tiga algoritma load balancing, yaitu Round Robin, Berbobot, dan Koneksi Terkecil. Round Robin adalah algoritma {i>default<i}. Karena tidak ada algoritme yang ditentukan dalam konfigurasi di atas, permintaan keluar dari proxy API ke server backend akan bergantian, satu per satu, antara target1 dan target 2.
Elemen <Path>
membentuk basepath URI TargetEndpoint untuk semua server target. Kolom ini hanya digunakan saat <LoadBalancer>
digunakan. Jika tidak, akan diabaikan. Dalam contoh di atas, permintaan yang menjangkau "target1" adalah
http://target1/test
, dan begitu juga untuk server target lainnya.
Menyetel opsi load balancer
Anda dapat menyesuaikan ketersediaan menggunakan opsi untuk load balancing dan failover di level load balancer dan TargetServer. Bagian ini menjelaskan opsi tersebut.
Algorithm
Menetapkan algoritma yang digunakan oleh <LoadBalancer>
. Algoritma
yang tersedia adalah RoundRobin
, Weighted
, dan LeastConnections
,
yang masing-masing didokumentasikan di bawah ini.
Round robin
Algoritme default, round robin, meneruskan permintaan ke setiap TargetServer sesuai urutan daftar server dalam koneksi HTTP endpoint target. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Berbobot
Algoritme load balancing berbobot memungkinkan Anda mengonfigurasi beban traffic yang proporsional untuk TargetServers Anda. LoadBalancer berbobot mendistribusikan permintaan ke TargetServers Anda secara proporsional dengan setiap bobot TargetServer. Oleh karena itu, algoritme berbobot mengharuskan Anda menetapkan atribut weight
untuk setiap TargetServer. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>Weighted</Algorithm> <Server name="target1"> <Weight>1</Weight> </Server> <Server name="target2"> <Weight>2</Weight> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Dalam contoh ini, dua permintaan akan diarahkan ke target2 untuk setiap satu permintaan yang diarahkan ke target1.
Koneksi Terkecil
LoadBalancers yang dikonfigurasi untuk menggunakan algoritma koneksi yang paling sedikit mengarahkan permintaan keluar ke TargetServer dengan koneksi HTTP terbuka yang paling sedikit. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>LeastConnections</Algorithm> <Server name="target1" /> <Server name="target2" /> </LoadBalancer> </HTTPTargetConnection> <Path>/test</Path> </TargetEndpoint>
Kegagalan maksimum
Jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain.
Kegagalan respons berarti Apigee tidak menerima respons apa pun dari server target. Jika ini terjadi, penghitung kegagalan akan bertambah satu.
Namun, saat Apigee menerima respons dari target, meskipun responsnya adalah error HTTP (seperti 500
), yang dihitung sebagai respons dari server target, dan penghitung kegagalan direset. Untuk membantu memastikan bahwa respons HTTP yang buruk (seperti 500
) juga menambah penghitung kegagalan untuk mengeluarkan server yang tidak responsif dari rotasi load balancing sesegera mungkin, Anda dapat menambahkan elemen <ServerUnhealthyResponse>
dengan elemen turunan <ResponseCode>
ke konfigurasi load balancer Anda. Edge juga akan menghitung respons dengan kode tersebut sebagai kegagalan.
Pada contoh berikut, target1
akan dihapus dari rotasi setelah lima
permintaan gagal, termasuk beberapa respons 5XX
dari server target.
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> <ServerUnhealthyResponse> <ResponseCode>500</ResponseCode> <ResponseCode>502</ResponseCode> <ResponseCode>503</ResponseCode> </ServerUnhealthyResponse> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Default MaxFailures adalah 0. Artinya, Edge selalu mencoba terhubung ke target untuk setiap permintaan dan tidak pernah menghapus server target dari rotasi.
Sebaiknya gunakan MaxFailures > 0 dengan HealthMonitor. Jika Anda mengonfigurasi MaxFailures > 0, TargetServer akan dihapus dari rotasi ketika target gagal sebanyak yang Anda tentukan. Saat HealthMonitor diterapkan, Apigee otomatis menempatkan TargetServer kembali dalam rotasi setelah target aktif dan berjalan kembali, sesuai dengan konfigurasi HealthMonitor tersebut. Lihat Pemantauan kesehatan untuk informasi selengkapnya.
Atau, jika Anda mengonfigurasi MaxFailures > 0, dan Anda tidak mengonfigurasi HealthMonitor, Apigee tidak akan otomatis menyertakan kembali TargetServer ke dalam rotasi setelah Apigee mendeteksi kegagalan. Dalam hal ini, Anda harus men-deploy ulang proxy API sebelum Apigee menempatkan kembali TargetServer. Lihat Men-deploy proxy API.
Coba lagi
Jika percobaan ulang diaktifkan, permintaan akan dicoba lagi setiap kali kegagalan respons (error I/O atau waktu tunggu HTTP) terjadi atau respons yang diterima cocok dengan nilai yang ditetapkan oleh <ServerUnhealthyResponse>
.
Lihat Kegagalan maksimum di atas untuk mengetahui informasi selengkapnya tentang cara menetapkan <ServerUnhealthyResponse>
.
Secara default, <RetryEnabled>
disetel ke true
. Setel ke false
untuk menonaktifkan percobaan ulang.
Contoh:
<RetryEnabled>false</RetryEnabled>
Penggantian
Satu (dan hanya satu) TargetServer dapat disetel sebagai server 'penggantian'. TargetServer penggantian tidak disertakan dalam rutinitas load balancing hingga semua TargetServers lainnya diidentifikasi sebagai tidak tersedia oleh load balancer. Saat load balancer menentukan bahwa semua TargetServers tidak tersedia, semua traffic akan dirutekan ke server penggantian. Contoh:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <Server name="target3"> <IsFallback>true</IsFallback> </Server> </LoadBalancer> <Path>/test</Path> </HTTPTargetConnection> </TargetEndpoint>
Konfigurasi di atas menghasilkan load balancing round robin antara target 1 dan 2 hingga kedua target 1 dan 2 tidak tersedia. Jika target 1 dan 2 tidak tersedia, semua traffic akan dirutekan ke target 3.
Path
Path menentukan fragmen URI yang akan ditambahkan ke semua permintaan yang dikeluarkan oleh TargetServer ke server backend.
Elemen ini menerima jalur string literal atau template pesan. Template
pesan memungkinkan Anda melakukan penggantian string variabel saat runtime.
Misalnya, dalam definisi endpoint target berikut, nilai {mypath}
digunakan untuk jalur:
<HTTPTargetConnection> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> <LoadBalancer> <Server name="testserver"/> </LoadBalancer> <Path>{mypath}</Path> </HTTPTargetConnection>
Mengonfigurasi server target untuk TLS/SSL
Jika Anda menggunakan TargetServer untuk menentukan layanan backend, dan layanan backend
memerlukan koneksi untuk menggunakan protokol HTTPS, Anda harus mengaktifkan TLS/SSL di
definisi TargetServer. Hal ini diperlukan karena tag <Host>
tidak mengizinkan Anda
menentukan protokol koneksi. Di bawah ini adalah definisi TargetServer untuk TLS/SSL satu arah tempat Edge membuat permintaan HTTPS ke layanan backend:
<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
Jika layanan backend memerlukan TLS/SSL dua arah, atau bersama, Anda mengonfigurasi TargetServer menggunakan setelan konfigurasi TLS/SSL yang sama dengan TargetEndpoints:
<TargetServer name="TargetServer 1"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
Untuk mengetahui informasi tentang properti <SSLInfo>
, seperti
<Ciphers>
dan <ClientAuthEnabled>
, lihat
informasi tentang cara menetapkan properti tersebut untuk Host Virtual di Mengonfigurasi akses TLS ke API
untuk Private Cloud.
Untuk mengetahui petunjuk lengkap tentang cara mengonfigurasi TLS/SSL keluar, lihat Mengonfigurasi TLS dari Edge ke backend (Cloud dan Private Cloud).
Skema TargetServer
Lihat skema untuk TargetServer dan entity lainnya di GitHub.
Pemantauan kesehatan
Pemantauan kondisi memungkinkan Anda untuk meningkatkan konfigurasi load balancing dengan secara aktif melakukan polling URL layanan backend yang ditentukan dalam konfigurasi TargetServer. Jika pemantauan kondisi diaktifkan, TargetServer yang gagal akan otomatis diputar kembali saat HealthMonitor menentukan bahwa TargetServer aktif.
Pemantauan kondisi berfungsi dengan <MaxFailures>
. Jika pemantauan kondisi tidak diaktifkan,
<MaxFailures>
akan menentukan jumlah permintaan yang gagal dari proxy API ke
TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain.
TargetServer yang gagal akan dikeluarkan dari rotasi sampai Anda men-deploy ulang proxy.
Jika pemantauan kondisi diaktifkan, TargetServer yang gagal akan otomatis dialihkan kembali dan deployment ulang proxy tidak diperlukan.
HealthMonitor bertindak sebagai klien sederhana yang memanggil layanan backend melalui TCP atau HTTP:
- Klien TCP hanya memastikan bahwa soket dapat dibuka.
- Anda mengonfigurasi klien HTTP untuk mengirimkan permintaan HTTP yang valid ke layanan backend. Anda
dapat menentukan operasi HTTP GET, PUT, POST, atau DELETE. Respons panggilan pemantau HTTP harus cocok dengan
setelan yang dikonfigurasi di blok
<SuccessResponse>
.
Keberhasilan dan kegagalan
Jika Anda mengaktifkan pemantauan kondisi, Edge akan mulai mengirimkan health check ke server target Anda. Health check adalah permintaan yang dikirim ke server target yang menentukan apakah server target responsif atau tidak.
Health check dapat memiliki salah satu dari dua kemungkinan hasil:
- Berhasil: Server target dianggap responsif jika health check yang berhasil. Hal ini biasanya terjadi karena satu atau beberapa hal berikut:
- Server target menerima koneksi baru ke port yang ditentukan, merespons permintaan pada port tersebut, lalu menutup port dalam jangka waktu yang ditentukan. Respons dari server target berisi “Koneksi: tutup”
- Server target merespons permintaan health check dengan kode status HTTP 200 (OK) atau lainnya yang Anda anggap dapat diterima.
- Server target merespons permintaan health check dengan isi pesan yang cocok dengan isi pesan yang diharapkan.
Saat Edge menentukan bahwa server responsif, Edge akan melanjutkan atau melanjutkan pengiriman permintaan ke server.
- Kegagalan: Server target dapat menggagalkan health check dengan cara yang berbeda,
bergantung pada jenis pemeriksaan. Kegagalan dapat dicatat saat server target:
- Menolak koneksi dari Edge ke port health check.
- Tidak merespons permintaan health check dalam jangka waktu tertentu.
- Menampilkan kode status HTTP yang tidak terduga.
- Merespons dengan isi pesan yang tidak cocok dengan isi pesan yang diharapkan.
Jika server target gagal dalam health check, Edge akan menambahkan jumlah kegagalan server tersebut. Jika jumlah kegagalan untuk server tersebut memenuhi atau melebihi nilai minimum yang telah ditentukan (
<MaxFailures>
), Edge akan berhenti mengirim permintaan ke server tersebut.
Mengaktifkan HealthMonitor
Untuk membuat HealthMonitor, tambahkan elemen <HealthMonitor>
ke konfigurasi HTTPConnection di TargetEndpoint
untuk proxy. Anda tidak dapat melakukannya di UI. Sebagai gantinya, buat konfigurasi proxy dan
upload sebagai file ZIP ke Edge. Konfigurasi proxy adalah deskripsi terstruktur dari semua aspek proxy API. Konfigurasi proxy terdiri dari file XML dalam struktur direktori yang telah ditetapkan sebelumnya. Untuk mengetahui informasi selengkapnya, lihat Referensi Konfigurasi Proxy API.
HealthMonitor sederhana menentukan IntervalInSec
yang dikombinasikan dengan
TCPMonitor atau HTTPMonitor. Elemen <MaxFailures>
menetapkan jumlah maksimum permintaan yang gagal dari proxy API ke TargetServer yang menyebabkan permintaan dialihkan ke TargetServer lain. Secara default, <MaxFailures>
adalah 0, yang berarti Edge tidak melakukan tindakan korektif. Saat mengonfigurasi pemantauan kondisi, pastikan Anda menetapkan
<MaxFailures>
dalam
tag <HTTPTargetConnection>
tag <TargetEndpoint>
ke nilai bukan nol.
TCPMonitor
Konfigurasi di bawah ini menentukan HealthMonitor yang melakukan polling setiap TargetServer dengan membuka koneksi pada port 80 setiap lima detik. (Transfer bersifat opsional. Jika tidak ditentukan, port TCPMonitor adalah port TargetServer.)
- Jika koneksi gagal atau memerlukan waktu lebih dari 10 detik untuk terhubung, jumlah kegagalan akan bertambah 1 untuk TargetServer tersebut.
- Jika koneksi berhasil, jumlah kegagalan untuk TargetServer akan direset ke 0.
Anda dapat menambahkan HealthMonitor sebagai elemen turunan dari elemen HTTPTargetConnetion TargetEndpoint, seperti yang ditunjukkan di bawah:
<TargetEndpoint name="default"> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="target1" /> <Server name="target2" /> <MaxFailures>5</MaxFailures> </LoadBalancer> <Path>/test</Path> <HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <TCPMonitor> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <Port>80</Port> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> . . .
HealthMonitor dengan elemen konfigurasi TCPMonitor
Tabel berikut menjelaskan elemen konfigurasi TCPMonitor:
Nama | Deskripsi | Default | Wajib diisi? |
---|---|---|---|
IsEnabled |
Boolean yang mengaktifkan atau menonaktifkan HealthMonitor. | false | Tidak |
IntervalInSec |
Interval waktu, dalam detik, di antara setiap permintaan TCP polling. | 0 | Ya |
ConnectTimeoutInSec |
Waktu saat koneksi ke port TCP harus dibuat agar dianggap berhasil. Kegagalan terhubung dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan load balancer untuk TargetServer. | 0 | Ya |
Port |
Opsional. Porta tempat koneksi TCP akan dibuat. Jika tidak ditentukan, port TCPMonitor adalah port TargetServer. | 0 | Tidak |
Pemantauan HTTP
Contoh HealthMonitor yang menggunakan HTTPMonitor akan mengirimkan permintaan GET ke layanan
backend setiap lima detik sekali. Contoh di bawah ini menambahkan header Otorisasi Dasar HTTP ke pesan permintaan. Konfigurasi Respons menentukan setelan yang akan dibandingkan dengan respons sebenarnya dari layanan backend. Dalam contoh di bawah, respons yang diharapkan adalah kode respons HTTP 200
dan header HTTP kustom ImOK
yang nilainya adalah YourOK
. Jika respons tidak cocok, permintaan akan dianggap sebagai kegagalan
oleh konfigurasi load balancer.
HTTPMonitor mendukung layanan backend yang dikonfigurasi untuk menggunakan protokol HTTP dan HTTPS satu arah. Namun, ini tidak mendukung hal berikut:
- HTTPS dua arah (juga disebut TLS/SSL dua arah)
- Sertifikat yang ditandatangani sendiri.
Perhatikan bahwa semua setelan Permintaan dan Respons dalam pemantau HTTP akan bersifat khusus untuk layanan backend yang harus dipanggil.
<HealthMonitor> <IsEnabled>true</IsEnabled> <IntervalInSec>5</IntervalInSec> <HTTPMonitor> <Request> <ConnectTimeoutInSec>10</ConnectTimeoutInSec> <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec> <Port>80</Port> <Verb>GET</Verb> <Path>/healthcheck</Path> <Header name="Authorization">Basic 12e98yfw87etf</Header> <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader> </Request> <SuccessResponse> <ResponseCode>200</ResponseCode> <Header name="ImOK">YourOK</Header> </SuccessResponse> </HTTPMonitor> </HealthMonitor>
HealthMonitor dengan elemen konfigurasi HTTPMonitor
Tabel berikut menjelaskan elemen konfigurasi HTTPMonitor:
Nama | Deskripsi | Default | Wajib diisi? |
---|---|---|---|
IsEnabled |
Boolean yang mengaktifkan atau menonaktifkan HealthMonitor. | false | Tidak |
IntervalInSec |
Interval waktu, dalam detik, di antara setiap permintaan polling. | 0 | Ya |
Request |
Opsi konfigurasi untuk pesan permintaan keluar yang dikirim oleh HealthMonitor ke TargetServers pada rotasi. Jalur tidak mendukung variabel. |
T/A | Ya |
ConnectTimeoutInSec |
Waktu, dalam detik, saat handshake koneksi TCP ke layanan HTTP harus selesai agar dianggap berhasil. Kegagalan terhubung dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan LoadBalancer untuk TargetServer. | 0 | Tidak |
SocketReadTimeoutInSec |
Waktu, dalam detik, saat data harus dibaca dari layanan HTTP agar dianggap berhasil. Kegagalan dalam membaca dalam interval yang ditentukan akan dihitung sebagai kegagalan, sehingga menambah jumlah kegagalan LoadBalancer untuk TargetServer. | 0 | Tidak |
Port |
Port tempat koneksi HTTP ke layanan backend akan dibuat. | T/A | Tidak |
Verb |
Kata kerja HTTP yang digunakan untuk setiap permintaan HTTP polling ke layanan backend . | T/A | Tidak |
Path |
Jalur yang ditambahkan ke URL yang ditetapkan di TargetServer. Gunakan elemen jalur untuk mengonfigurasi 'endpoint polling' di layanan HTTP Anda. | T/A | Tidak |
| Memungkinkan Anda
melacak permintaan health check di sistem upstream. IncludeHealthCheckIdHeader
mengambil nilai Boolean, dan
secara default ditetapkan ke false . Jika Anda menetapkannya ke true , akan ada Header bernama X-Apigee-Healthcheck-Id yang dimasukkan ke dalam permintaan healthcheck. Nilai header
ditetapkan secara dinamis dan berbentuk
ORG/ENV/SERVER_UUID/N, dengan ORG sebagai
nama organisasi, ENV sebagai nama lingkungan,
SERVER_UUID adalah ID unik yang mengidentifikasi MP, dan
N adalah jumlah milidetik yang berlalu sejak 1 Januari 1970.
Contoh header permintaan yang dihasilkan: X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123
|
false | Tidak |
Payload |
Isi HTTP yang dibuat untuk setiap permintaan HTTP polling. Perhatikan bahwa elemen ini tidak diperlukan untuk permintaan GET. | T/A | Tidak |
SuccessResponse |
Opsi pencocokan untuk pesan respons HTTP masuk yang dihasilkan oleh layanan backend yang di-polling. Respons yang tidak cocok akan menambah jumlah kegagalan sebesar 1. | T/A | Tidak |
ResponseCode |
Kode respons HTTP yang diharapkan akan diterima dari TargetServer yang di-polling. Kode yang berbeda dari kode yang ditentukan akan mengakibatkan kegagalan, dan jumlahnya bertambah untuk layanan backend yang di-polling. Anda dapat menentukan beberapa elemen ResponseCode. | T/A | Tidak |
Headers |
Daftar satu atau beberapa header dan nilai HTTP yang diharapkan akan diterima dari layanan backend yang di-polling. Setiap header atau nilai HTTP pada respons yang berbeda dengan yang ditentukan akan mengakibatkan kegagalan, dan jumlah untuk TargetServer yang di-polling bertambah 1. Anda dapat mendefinisikan beberapa elemen Header. | T/A | Tidak |