Error Layanan Peering VPC 503 Tidak Tersedia dengan TARGET_CONNECT_TIMEOUT

Anda sedang melihat dokumentasi Apigee dan Apigee hybrid.
Tidak ada padanan Dokumentasi Apigee Edge untuk topik ini.

Gejala

Masalah ini muncul dengan pesan "503 - Layanan Tidak Tersedia" kesalahan dalam Pemantauan API, Debug, atau metode alat. "TARGET_CONNECT_TIMEOUT" alasan menunjukkan waktu tunggu koneksi antara Instance Apigee dan targetnya saat menggunakan Peering VPC.

Error ini tidak sama 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

Perlu diperhatikan bahwa penyebab ini berlaku khusus untuk Apigee yang disiapkan dengan Peering VPC. Lihat Opsi jaringan Apigee. Jika targetnya adalah PSC (Lampiran Endpoint), lihat playbook PSC sebagai gantinya.

Langkah-Langkah Diagnosis Umum

Debug adalah alat penting untuk memperoleh dan mengevaluasi detail masalah berikut:

• Total durasi permintaan. Biasanya memerlukan waktu tiga detik (default connect.timeout.millis) hingga waktu tunggu koneksi habis. Jika Anda melihat durasi yang lebih singkat, periksa Target Konfigurasi endpoint.
• Nama host dan alamat IP target. Alamat IP yang salah ditampilkan dapat mengindikasikan adanya masalah terkait DNS. Anda mungkin juga melihat korelasi antara IP target yang berbeda dan masalahnya.
• Frekuensi. Diperlukan pendekatan yang berbeda bergantung pada apakah masalahnya hanya sesekali atau gigih.

Penyebab: Kesalahan konfigurasi rute

Diagnosis

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

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

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

   Cari nilai target.ip di sisi kanan layar.

   Dalam contoh ini, IP adalah 10.2.0.1. Karena rentang ini bersifat pribadi, maka memerlukan tindakan pemilihan rute yang harus diterapkan untuk memastikan Apigee dapat mencapai target.

   Perlu diketahui bahwa jika target ada di internet, Anda harus mengikuti langkah ini jika Kontrol Layanan VPC diaktifkan untuk Apigee, karena hal tersebut mencegah konektivitas internet.

2. Catat region tempat instance Apigee yang terpengaruh di-deploy. Di kolom UI Apigee di Konsol Cloud, klik Instances. Di kolom Lokasi, Anda dapat menemukan region instance yang tepat.
   
   
   
3. Pada project yang di-peering dengan Apigee, buka Jaringan VPC -> VPC peering jaringan di UI. Perhatikan, jika Anda menggunakan VPC Bersama, lalu langkah-langkah tersebut perlu dilakukan di project host, bukan di project Apigee.
   
   
4. Klik servicenetworking-googleapis-com, lalu pilih RUTE YANG DIEKSPOR, lalu filter berdasarkan region yang diperoleh pada Langkah 2.
   
   Contoh ini menunjukkan rute 10.2.0.0/24 seperti yang diekspor dan menyertakan contoh target 10.2.0.1 KI. Jika Anda tidak melihat rute yang sesuai dengan target, hal itu adalah penyebab masalah.
   
   

Resolusi

Tinjau arsitektur jaringan Anda, dan pastikan rute diekspor ke peering VPC dengan Apigee. Kemungkinan besar rute yang hilang adalah statis atau dinamis. Kekurangan rute dinamis yang diperlukan mengindikasikan masalah dengan fitur terkait, misalnya, Cloud Interconnect.

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

Anda dapat membaca Pola jaringan selatan untuk informasi selengkapnya.

Penyebab: Masalah konektivitas pada target

Diagnosis

Target mungkin tidak dapat dijangkau dari VPC atau tidak dapat menerima koneksi. Dua opsinya adalah yang tersedia untuk mendiagnosis masalah.

Uji Konektivitas (alamat IP Target Pribadi)

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

1. Identifikasi alamat IP target yang diselesaikan dari instance Apigee. Salah satu metodenya adalah untuk menggunakan sesi Debug.
   
   Di Debug, buka AnalyticsPublisher (atau AX di Debug Klasik). Cari nilai target.ip di sisi kanan layar.
   
   Dalam contoh ini, IP adalah 10.2.0.1. Ini adalah alamat IP pribadi, yang berarti kita bisa menggunakan Uji Konektivitas.
   
   
2. Catat alamat IP instance Apigee yang tidak dapat terhubung ke target. Di Instance di Konsol Apigee, temukan Alamat IP instance Apigee di kolom IP Address.
   
   
3. Buka Uji Konektivitas lalu klik CreateConnectivity test. Berikan detail berikut:
   1. Alamat IP sumber: Gunakan IP instance Apigee yang diperoleh di Langkah 2 di atas. Perlu diperhatikan bahwa ini bukanlah IP sumber yang sama persis dengan yang digunakan Apigee untuk mengirim permintaan ke target, tetapi itu cukup untuk pengujian, karena dalam proses di subnet yang berbeda.
   2. Ini adalah alamat IP yang digunakan di Google Cloud: Biarkan tidak dicentang kecuali jika ada di project Google Cloud Anda. Jika memeriksa nilai ini, berikan juga proyek dan jaringan.
   3. Masukkan alamat target (Langkah 1) dan port sebagai Alamat IP Tujuan, lalu Port Tujuan.
   
4. Klik Create dan tunggu hingga pengujian selesai pada proses pertama.
5. Dalam daftar uji konektivitas, klik Lihat untuk melihat hasil dalam proses eksekusi.
6. Jika hasilnya "Tidak dapat dijangkau", berarti Anda mengalami masalah dengan konfigurasi Anda. Alat ini akan mengarahkan Anda ke Dokumentasi Status Uji Konektivitas untuk melangkah lebih jauh. Jika statusnya "Dapat dijangkau", berarti banyak masalah konfigurasi akan terjadi. Namun, hal ini bukan jaminan bahwa target dapat dijangkau. Belum ada mencoba membuat koneksi TCP dengan target. Hanya diagnosis berikutnya yang akan membantu untuk mengujinya.
   
   

Pengujian konektivitas VM (semua target)

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

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

3. Periksa output lengkapnya dan cari error ini:

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

   Munculnya error ini mengonfirmasi bahwa masalah tersebut dapat direproduksi di luar Apigee.

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

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

Resolusi

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

Jika waktu tunggu direproduksi dari VM, tidak ada panduan pasti terkait cara mengatasi di sisi target. Setelah waktu tunggu koneksi dapat direproduksi di luar Apigee, menangani masalah ini lebih lanjut dari VPC. Cobalah untuk menguji konektivitas sedekat mungkin dengan target sebaik mungkin.

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

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

Jika masalah terjadi pada jam-jam sibuk, target bisa jadi kewalahan dengan koneksi yang terjadi.

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

Penyebab: Pemberian izin IP sesuai target dengan sebagian atau semuanya IP NAT Apigee tidak ditambahkan

Diagnosis

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

Masalahnya lebih mudah ditemukan jika terjadi kesalahan sesekali, karena dalam hal ini Anda mungkin dapat untuk menemukan korelasi antara IP NAT tertentu dan kesalahannya.

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

Buat daftar IP NAT untuk sebuah instance:

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

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

Jika masalahnya berselang-seling, itu mungkin menunjukkan bahwa hanya sebagian dari IP NAT yang diizinkan sesuai target. Untuk mengidentifikasi bahwa:

1. Buat Reverse proxy baru tempat target yang terpengaruh ditetapkan di TargetEndpoint. Anda juga dapat menggunakan kembali proxy yang ada dan melanjutkan ke langkah berikutnya:
   
   
2. Tambahkan kebijakan Servicecallout ke dalam Request PreFlow. ServiceInfo akan memanggil "https://icanhazip.com", "https://mocktarget.apigee.net/ip", atau endpoint publik lainnya yang menampilkan alamat IP pemanggil dalam respons. Simpan respons dalam "response" variabel sehingga agar kontennya terlihat di Debug. Ini adalah contoh konfigurasi kebijakan ServiceInfo:
   

   <?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 khusus, tetapi Anda harus membaca ".content" variabel tersebut dengan kebijakan MenetapkanMessage untuk memunculkannya dalam alat Debug.

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

3. Jalankan sesi Debug dan klik langkah ServiceInfo:
   
   
4. Di sudut kanan bawah, Anda akan melihat bagian Response content yang berisi NAT IP (dalam Isi) instance Apigee yang membuat permintaan. Atau, jika Anda menyimpan respons ServiceInfo di tempat lain, Anda akan melihat di sana.
   
   Harap dicatat, nanti di alur, {i>proxy<i} akan memanggil target dan Tanggapan content akan ditimpa dengan error atau respons dari target.
5. Cobalah untuk menghubungkan IP NAT dengan masalah tersebut. Jika Anda melihat bahwa hanya IP tertentu yang gagal, adalah tanda bahwa beberapa, tetapi tidak semua IP diizinkan di target.
6. Jika Anda tidak melihat korelasi antara IP NAT dan {i>error<i}, misalnya, jika alamat IP yang sama gagal dalam satu permintaan tetapi tidak di permintaan lain, kemungkinan besar ini bukan masalah listingan yang diizinkan. Ini mungkin seperti kehabisan NAT. Lihat Penyebab: Port IP NAT kelelahan.

Resolusi

Pastikan Anda memiliki IP NAT yang disediakan dan diaktifkan, serta memastikan semuanya ditambahkan di sisi target.

Penyebab: Kehabisan port IP NAT

Diagnosis

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

1. Perhatikan jangka waktu masalah. Misalnya: setiap hari antara pukul 17.58–18.08.
2. Pastikan apakah ada target lain yang terpengaruh oleh masalah tersebut dalam jangka waktu yang sama. Bahwa target harus dapat diakses melalui internet dan tidak boleh di-hosting di lokasi yang sama dengan target awal yang terpengaruh.
3. Tetapkan jika error hanya terjadi di atas volume traffic tertentu di TPS. Untuk melakukannya, perhatikan jangka waktu masalah tersebut, dan buka Performa Proxy dasbor.
4. Coba hubungkan periode waktu error dengan peningkatan Transaksi rata-rata per detik (tps).

Dalam contoh ini, tps bertambah menjadi 1.000 pada pukul 17.58. Dengan asumsi bahwa dalam contoh ini, 17:58 adalah tepat kapan masalah itu terjadi, dan masalah itu mempengaruhi dua atau lebih target yang tidak terkait, yaitu sinyal dari masalah dengan kehabisan NAT.

Resolusi

Hitung ulang persyaratan IP NAT Anda dengan menggunakan instruksi di Menghitung persyaratan IP NAT statis.

Anda juga dapat menambahkan lebih banyak IP NAT dan lihat apakah langkah itu dapat menyelesaikan masalah. Perhatikan bahwa menambahkan lebih banyak IP mungkin memerlukan listingan yang diizinkan mengidentifikasinya 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 memeriksanya, buka proxy yang terpengaruh dan periksa TargetEndpoint yang dimaksud. Perhatikan "connect.timeout.millis" properti dan nilainya. Pada contoh di sini nilainya adalah 50, yang adalah 50 md dan biasanya terlalu rendah untuk menjamin terciptanya koneksi TCP. Jika Anda melihat nilai di bawah 1.000, kemungkinan itu adalah penyebab masalah. Jika Anda tidak melihat "connect.timeout.millis" maka nilai {i>default<i} akan ditetapkan dan penyebabnya belum dikonfirmasi.

Resolusi

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

Hubungi Dukungan untuk bantuan lebih lanjut

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

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