Error 503 Layanan Tidak Tersedia dengan TARGET_CONNECT_TIMEOUT (Target peering internet dan VPC)

Anda sedang melihat dokumentasi Apigee dan Apigee Hybrid.
Tidak ada dokumentasi Apigee Edge yang setara untuk topik ini.

Gejala

Masalah ini muncul sebagai error "503 - Service Unavailable" di Pemantauan API, Debug, atau alat lainnya. Alasan "TARGET_CONNECT_TIMEOUT" menunjukkan waktu tunggu koneksi antara instance Apigee dan target internet atau target yang dapat dijangkau dengan VPC Peering.

Error ini tidak boleh disamakan dengan error waktu tunggu lainnya, seperti 504 Gateway Timeout.

Pesan Error

Ini adalah error umum dalam sesi Debug atau payload respons. Harap perhatikan alasannya: TARGET_CONNECT_TIMEOUT.

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

Kemungkinan Penyebab

Perhatikan bahwa penyebab ini khusus untuk target internet atau target yang dapat dijangkau dengan Peering VPC. Lihat Opsi jaringan Apigee. Jika targetnya adalah PSC (Lampiran Endpoint), lihat buku pedoman PSC.

Penyebab	Deskripsi
Kesalahan konfigurasi rute	Rute target tidak diekspor ke peering dengan instance Apigee.
Masalah konektivitas di target	Target tidak selalu dapat menerima koneksi TCP.
Daftar IP yang diizinkan di target dengan beberapa atau semua IP NAT Apigee tidak ditambahkan	Tidak semua IP NAT Apigee masuk dalam daftar yang diizinkan di target.
Kehabisan port IP NAT	Port NAT yang disediakan untuk traffic tidak cukup.
Nilai connect.timeout.millis ditetapkan terlalu rendah	Setelan waktu tunggu koneksi terlalu rendah di sisi Apigee.

Langkah-Langkah Diagnosis Umum

Debug adalah alat penting untuk merekam dan mengevaluasi detail berikut tentang masalah:

• Total durasi permintaan. Biasanya diperlukan waktu tiga detik (default connect.timeout.millis) hingga terjadi timeout koneksi. Jika Anda melihat durasi yang lebih rendah, periksa konfigurasi Endpoint Target.
• Nama host target dan alamat IP. Alamat IP yang salah mungkin menunjukkan masalah terkait DNS. Anda mungkin juga melihat korelasi antara berbagai IP target dan masalah tersebut.
• Frekuensi. Diperlukan pendekatan yang berbeda, bergantung pada apakah masalahnya terjadi sesekali atau terus-menerus.

Penyebab: Error konfigurasi rute

Diagnosis

Jika masalah terus berlanjut, meskipun baru dimulai baru-baru ini, masalah tersebut mungkin disebabkan oleh kesalahan konfigurasi rute.

Hal ini dapat memengaruhi target internal (dirutekan dalam VPC yang di-peering) dan eksternal (internet).

1. Pertama, identifikasi alamat IP target yang di-resolve dari instance Apigee. Salah satu metodenya adalah dengan menggunakan sesi Debug. Di Debug, buka AnalyticsPublisher (atau AX di Debug Klasik):
   
   

   Cari nilai target.ip di sisi kanan layar.

   Dalam contoh ini, IP-nya adalah 10.2.0.1. Karena rentang ini bersifat pribadi, tindakan perutean tertentu harus dilakukan untuk memastikan Apigee dapat menjangkau target.

   Perhatikan bahwa jika target berada di internet, Anda harus mengikuti langkah ini jika Kontrol Layanan VPC diaktifkan untuk Apigee, karena hal itu mencegah konektivitas internet.

2. Catat region tempat instance Apigee yang terpengaruh di-deploy. Di UI Apigee di Konsol Cloud, klik Instances. Di kolom Location, Anda dapat menemukan wilayah persis instance.
   
   
   
3. Di project yang di-peering dengan Apigee, buka bagian VPC Network -> VPC network peering di UI. Perhatikan, jika Anda menggunakan VPC Bersama, maka langkah-langkah tersebut harus dilakukan di project host, bukan project Apigee.
   
   
4. Klik servicenetworking-googleapis-com, pilih tab EXPORTED ROUTES, lalu filter menurut region yang diperoleh di Langkah 2.
   
   Contoh ini menunjukkan rute 10.2.0.0/24 yang diekspor dan menyertakan contoh target IP 10.2.0.1. Jika Anda tidak melihat rute yang sesuai dengan target, itulah penyebab masalahnya.
   
   Catatan: Jika targetnya eksternal, rute biasanya tidak ada di Rute yang Diekspor dan permintaan Apigee dirutekan ke internet secara langsung. Hal ini mungkin tidak selalu terjadi, jadi pastikan untuk mengklarifikasi topologi jaringan yang diinginkan. Misalnya, jika Kontrol Layanan VPC diaktifkan, Anda juga perlu mengekspor rute default atau rute lainnya untuk menjangkau target eksternal.
   
   

Resolusi

Tinjau arsitektur jaringan Anda, dan pastikan rute diekspor ke peering VPC dengan Apigee. Kemungkinan besar rute yang tidak ada adalah statis atau dinamis. Kurangnya rute dinamis yang diperlukan menunjukkan masalah pada fitur yang sesuai, misalnya, Cloud Interconnect.

Perlu diperhatikan, peering transitif tidak didukung. Dengan kata lain, jika jaringan VPC N1 di-peering dengan N2 dan N3, tetapi N2 dan N3 tidak terhubung langsung, jaringan VPC N2 tidak dapat berkomunikasi dengan jaringan VPC N3 melalui Peering Jaringan VPC.

Anda dapat membaca Pola jaringan southbound untuk mengetahui informasi selengkapnya.

Penyebab: Masalah konektivitas di target

Diagnosis

Target mungkin tidak dapat dijangkau dari VPC atau tidak dapat menerima koneksi. Dua opsi tersedia untuk mendiagnosis masalah ini.

Uji Konektivitas (Alamat IP Target Pribadi)

Jika target berada di jaringan pribadi, Anda dapat menggunakan fitur Uji Konektivitas untuk mendiagnosis penyebab umum.

1. Identifikasi alamat IP target yang di-resolve dari instance Apigee. Salah satu metodenya adalah dengan menggunakan sesi Debug.
   
   Di Debug, buka AnalyticsPublisher (atau AX di Debug Klasik). Cari nilai target.ip di sisi kanan layar.
   
   Dalam contoh ini, IP-nya adalah 10.2.0.1. Ini adalah alamat IP pribadi, yang berarti kita dapat menggunakan Uji Konektivitas.
   
   
2. Catat alamat IP instance Apigee yang tidak dapat terhubung ke target. Di Instances di Konsol Apigee, temukan Alamat IP instance Apigee di kolom IP Address.
   
   
3. Buka Uji Konektivitas lalu klik Buat uji konektivitas. Berikan detail berikut:
   1. Alamat IP Sumber: Gunakan IP instance Apigee yang diperoleh di Langkah 2 di atas. Perhatikan bahwa ini bukan IP sumber persis yang digunakan oleh Apigee untuk mengirim permintaan ke target, tetapi sudah cukup untuk pengujian, karena berada di subnet yang sama.
   2. Ini adalah alamat IP yang digunakan di Google Cloud: Jangan hapus centang kecuali jika alamat tersebut ada di salah satu project Google Cloud Anda. Jika memeriksa nilai ini, berikan juga project dan jaringan.
   3. Masukkan alamat target (Langkah 1) dan port sebagai Destination IP Address dan Destination Port.
   
4. Klik Buat dan tunggu hingga pengujian selesai menjalankan yang pertama.
5. Dalam daftar uji konektivitas, klik Lihat untuk melihat hasil eksekusi.
6. Jika hasilnya "Tidak dapat dijangkau", berarti Anda mengalami masalah dengan konfigurasi. Alat ini akan mengarahkan Anda ke dokumentasi Status Uji Konektivitas untuk melanjutkan. Jika statusnya "Dapat dijangkau", berarti banyak masalah konfigurasi yang dapat diatasi. Namun, hal ini tidak menjamin bahwa target dapat dijangkau. Belum ada upaya sebenarnya untuk membuat koneksi TCP dengan target. Hanya diagnosis berikutnya di bawah yang akan membantu untuk mengujinya.
   
   

Uji konektivitas VM (semua target)

1. Di VPC yang sama yang di-peering dengan Apigee, buat Instance VM di Linux.
2. Lakukan uji konektivitas dari VM, sebaiknya pada saat masalah dapat direproduksi dari Apigee. Anda dapat menggunakan telnet, curl, dan utilitas lainnya untuk membuat koneksi. Contoh curl ini berjalan dalam loop dengan waktu tunggu tiga detik. Jika curl tidak dapat membuat koneksi TCP dalam tiga detik, curl akan gagal.

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. Periksa output lengkap dan cari error ini:

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   Adanya error ini mengonfirmasi bahwa masalah dapat direproduksi di luar Apigee.

   Perhatikan, jika Anda melihat error lain, seperti error terkait TLS, kode status yang salah, dll., tidak mengonfirmasi waktu tunggu koneksi dan tidak terkait dengan masalah ini.

4. Jika target memerlukan daftar IP yang diizinkan, Anda mungkin tidak dapat mengujinya dari VM kecuali jika Anda mengizinkan IP sumber instance VM juga.

Resolusi

Jika Anda mengidentifikasi masalah berdasarkan Uji Konektivitas, lanjutkan dengan langkah-langkah penyelesaian yang didokumentasikan.

Jika timeout direproduksi dari VM, maka tidak ada panduan pasti tentang cara menyelesaikan masalah di sisi target. Setelah waktu tunggu koneksi dapat direproduksi di luar Apigee, selidiki lebih lanjut masalah ini dari VPC. Coba uji konektivitas sedekat mungkin dengan target.

Jika target berada di balik koneksi VPN, Anda mungkin juga dapat mengujinya dari jaringan lokal.

Jika target berada di internet, Anda dapat mencoba mereproduksi masalah di luar Konsol Google Cloud.

Jika masalah terjadi pada jam sibuk, target mungkin kewalahan dengan koneksi.

Jika Anda perlu mengajukan kasus dukungan Google Cloud pada tahap tersebut, Anda tidak perlu lagi memilih komponen Apigee, karena masalahnya kini dapat direproduksi langsung dari VPC.

Penyebab: Pemberian izin IP di target dengan beberapa atau semua IP NAT Apigee tidak ditambahkan

Diagnosis

Hal ini berkaitan dengan target eksternal (internet) yang mengaktifkan daftar yang diizinkan IP. Pastikan semua IP NAT Apigee ditambahkan di sisi target yang terpengaruh. Jika tidak ada daftar yang diizinkan di target, Anda dapat melewati bagian ini.

Masalah ini lebih mudah ditemukan jika error terjadi secara tidak teratur, karena dalam hal ini Anda mungkin dapat menemukan korelasi antara IP NAT tertentu dan error.

Jika masalah berlanjut (semua panggilan gagal), pastikan IP NAT diaktifkan di Apigee dan ambil dengan langkah-langkah berikut:

Mencantumkan IP NAT untuk instance:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Contoh respons:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Jika Anda tidak menerima alamat apa pun dalam output, berarti IP NAT tidak ditambahkan di sisi Apigee. Jika Anda mendapatkan alamat, tetapi tidak ada yang AKTIF, berarti tidak ada alamat yang digunakan untuk mengizinkan akses ke internet, yang juga merupakan masalah.

Jika Anda memiliki setidaknya satu alamat AKTIF, alamat tersebut dapat dimasukkan ke daftar yang diizinkan di target, sehingga tidak ada kesalahan konfigurasi di sisi Apigee. Dalam hal ini, alamat mungkin tidak ada dalam daftar yang diizinkan di target.

Jika masalahnya bersifat sementara, hal itu mungkin menunjukkan bahwa hanya sebagian kecil IP NAT yang telah ditambahkan ke daftar yang diizinkan di target. Untuk mengidentifikasinya:

1. Buat Reverse proxy baru dengan target yang terpengaruh ditentukan di TargetEndpoint. Anda juga dapat menggunakan kembali proxy yang ada dan melanjutkan ke langkah berikutnya:
   
   
2. Tambahkan kebijakan ServiceCallout ke PreFlow Permintaan. ServiceCallout harus memanggil "https://icanhazip.com", "https://mocktarget.apigee.net/ip", atau endpoint publik lainnya yang menampilkan alamat IP pemanggil dalam respons. Simpan respons dalam variabel "response" agar konten dapat dilihat di Debug. Berikut adalah contoh konfigurasi kebijakan ServiceCallout:
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
       <DisplayName>Service Callout-1</DisplayName>
       <Properties/>
       <Request clearPayload="true" variable="myRequest">
           <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       </Request>
       <Response>response</Response>
       <HTTPTargetConnection>
           <Properties/>
           <URL>https://icanhazip.com</URL>
       </HTTPTargetConnection>
   </ServiceCallout>

   Anda juga dapat menyimpan respons dalam variabel kustom, tetapi Anda harus membaca ".content" variabel tersebut dengan kebijakan AssignMessage untuk menampilkannya di alat Debug.

   Pastikan target dikonfigurasi dengan cara yang sama persis seperti di proxy yang terpengaruh.

   Catatan: Permintaan ServiceCallout dan permintaan Target harus terjadi dalam satu transaksi. Hal ini untuk memastikan bahwa server yang sama memproses permintaan sehingga IP NAT permintaan yang terpengaruh cocok dengan IP NAT yang diperoleh dari ServiceCallout.
3. Jalankan sesi Debug dan klik langkah ServiceCallout:
   
   
4. Di pojok kanan bawah, Anda akan melihat bagian Response content yang berisi IP NAT (di Body) instance Apigee yang membuat permintaan. Atau, jika Anda menyimpan respons ServiceCallout di tempat lain, Anda akan melihatnya di sana.
   
   Perhatikan bahwa di alur selanjutnya, proxy akan memanggil target dan konten Respons akan diganti dengan error atau respons dari target.
5. Coba korelasikan IP NAT dengan masalah tersebut. Jika Anda melihat bahwa hanya IP tertentu yang gagal, ini adalah tanda bahwa beberapa, tetapi tidak semua IP diizinkan di target.
6. Jika Anda tidak melihat korelasi antara IP NAT dan error, misalnya, jika IP yang sama gagal dalam satu permintaan, tetapi tidak dalam permintaan lainnya, kemungkinan besar ini bukan masalah daftar yang diizinkan. Masalah ini mungkin disebabkan oleh kehabisan NAT. Lihat Penyebab: Port IP NAT habis.

Resolusi

Pastikan Anda telah menyediakan dan mengaktifkan IP NAT dan pastikan semua IP tersebut ditambahkan di sisi target.

Penyebab: Kehabisan port IP NAT

Diagnosis

Catatan: Penyebab ini tidak umum dan relevan jika masalah tidak dapat direproduksi dari VPC Anda atau tempat lain di luar Apigee. Jika Anda belum melakukan pengujian tersebut, ikuti bagian Masalah konektivitas di target di atas untuk mendapatkan panduan. Bagian ini juga tidak relevan jika Anda tidak menggunakan IP NAT.

Jika masalah hanya dapat direproduksi dari Apigee dan IP NAT disediakan untuk organisasi Anda, dan Anda melihatnya terjadi untuk target yang berbeda pada saat yang sama, Anda mungkin kehabisan port sumber NAT:

1. Catat jangka waktu masalah. Misalnya: harian antara 17.58 - 18.08.
2. Konfirmasi apakah target lain terpengaruh oleh masalah tersebut dalam jangka waktu yang sama. Target lain tersebut harus dapat diakses melalui internet dan tidak boleh dihosting di lokasi yang sama dengan target asli yang terpengaruh.
3. Tentukan apakah error hanya terjadi di atas volume traffic tertentu dalam TPS. Untuk melakukannya, catat rentang waktu masalah, lalu buka dasbor Performa Proxy.
4. Coba korelasikan jangka waktu error dengan peningkatan Rata-rata transaksi per detik (tps).

Dalam contoh ini, tps meningkat menjadi 1.000 pada pukul 17.58. Dengan asumsi bahwa dalam contoh ini, masalah terjadi tepat pada pukul 17.58, dan masalah tersebut memengaruhi dua atau lebih target yang tidak terkait, hal itu merupakan sinyal masalah kelelahan NAT.

Resolusi

Hitung ulang persyaratan IP NAT Anda menggunakan petunjuk di Menghitung persyaratan IP NAT statis.

Anda juga dapat menambahkan lebih banyak IP NAT dan melihat apakah hal tersebut menyelesaikan masalah. Perlu diperhatikan bahwa penambahan IP lainnya mungkin memerlukan izin untuk memasukkannya ke daftar yang diizinkan di semua target terlebih dahulu.

Penyebab: Nilai connect.timeout.millis ditetapkan terlalu rendah

Diagnosis

Anda mungkin telah salah mengonfigurasi nilai waktu tunggu di proxy.

Untuk memeriksa, buka proxy yang terpengaruh dan periksa TargetEndpoint yang dimaksud. Perhatikan properti "connect.timeout.millis" dan nilainya. Dalam contoh di sini, nilainya adalah 50, yang adalah 50 milidetik dan biasanya terlalu rendah untuk menjamin pembuatan koneksi TCP. Jika Anda melihat nilai di bawah 1.000, kemungkinan itulah penyebab masalahnya. Jika Anda tidak melihat properti "connect.timeout.millis", nilai default akan ditetapkan dan penyebabnya belum dikonfirmasi.

Resolusi

Perbaiki nilai connect.timeout.millis, pastikan untuk mencatat bahwa satuan waktu dalam milidetik. Nilai defaultnya adalah 3000, yaitu 3000 milidetik. Untuk mengetahui informasi selengkapnya, lihat Referensi properti endpoint.

Hubungi Dukungan untuk mendapatkan bantuan lebih lanjut

Jika masalah berlanjut setelah mengikuti petunjuk di atas, kumpulkan informasi diagnostik berikut untuk Dukungan Google Cloud:

1. Project ID dan nama organisasi Apigee
2. Nama proxy dan lingkungan
3. Jangka waktu terjadinya masalah
4. Frekuensi masalah
5. Nama host target
6. Sesi debug dengan masalah
7. Hasil pemeriksaan yang dilakukan untuk kemungkinan penyebab di atas. Misalnya, output perintah curl dari VM