Halaman ini diterjemahkan oleh Cloud Translation API.

Error Layanan Tidak Tersedia 503 Peering VPC dengan TARGET_CONNECT_TIMEOUT

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 - Layanan Tidak Tersedia" di Pemantauan API, Debug, atau alat lainnya. Alasan "TARGET_CONNECT_TIMEOUT" menunjukkan waktu tunggu koneksi antara instance Apigee dan target saat menggunakan Peering VPC.

Error ini tidak boleh disamakan dengan error waktu tunggu habis lainnya, seperti Waktu Tunggu Gateway 504.

Pesan Error

Ini adalah error umum dalam sesi Debug atau payload respons. 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 Apigee yang disiapkan dengan Peering VPC. Lihat Opsi jaringan Apigee. Jika targetnya adalah PSC (Lampiran Endpoint), lihat playbook PSC sebagai gantinya.

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 diizinkan di target.
Kehabisan port IP NAT	Port NAT tidak cukup untuk mengakomodasi traffic.
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 perlu waktu tiga detik (connect.timeout.millis default) hingga waktu tunggu koneksi habis. Jika Anda melihat durasi yang lebih rendah, periksa konfigurasi Endpoint Target.
Nama host target dan alamat IP. Alamat IP yang salah ditampilkan mungkin menunjukkan masalah terkait DNS. Anda mungkin juga melihat korelasi antara berbagai IP target dan masalah tersebut.
Frekuensi. Pendekatan yang berbeda diperlukan bergantung pada apakah masalahnya bersifat intermiten atau persisten.

Penyebab: Error konfigurasi rute

Diagnosis

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

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

Pertama, identifikasi alamat IP target yang di-resolve dari instance Apigee. Salah satu metodenya adalah 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, diperlukan langkah-langkah pemilihan rute tertentu untuk memastikan Apigee dapat mencapai target.

Perhatikan bahwa jika target berada di internet, Anda harus mengikuti langkah ini jika Kontrol Layanan VPC diaktifkan untuk Apigee, karena hal itu akan mencegah konektivitas internet.
Perhatikan region tempat instance Apigee yang terpengaruh di-deploy. Di UI Apigee di konsol Cloud, klik Instance. Di kolom Location, Anda dapat menemukan region instance yang tepat.
Di project yang di-peering dengan Apigee, buka bagian VPC Network -> VPC network peering di UI. Perhatikan bahwa jika Anda menggunakan VPC Bersama, langkah-langkah tersebut harus dilakukan di project host, bukan project Apigee.
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 seperti yang diekspor dan menyertakan contoh IP target 10.2.0.1. Jika Anda tidak melihat rute yang sesuai dengan target, itulah penyebab masalahnya.
Catatan: Jika target bersifat eksternal, rute biasanya tidak ada di Rute yang Diekspor dan permintaan Apigee dirutekan langsung ke internet. Hal ini mungkin tidak selalu demikian, 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 bersifat statis atau dinamis. Kurangnya rute dinamis yang diperlukan menunjukkan masalah pada fitur yang sesuai, 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, 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. Ada dua opsi yang tersedia untuk mendiagnosis masalah.

Uji Konektivitas (Alamat IP Target Pribadi)

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

Identifikasi alamat IP target yang di-resolve dari instance Apigee. Salah satu metodenya adalah 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.
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.
Buka Uji Konektivitas dan 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 yang tepat yang digunakan oleh Apigee untuk mengirim permintaan ke target, tetapi cukup untuk pengujian, karena berada di subnet yang sama.
2. Ini adalah alamat IP yang digunakan di Google Cloud: Biarkan tidak dicentang kecuali jika alamat tersebut ada di project Google Cloud Anda. Jika memeriksa nilai ini, berikan juga project dan jaringan.
3. Masukkan alamat target (Langkah 1) dan port sebagai Alamat IP Tujuan dan Port Tujuan.
Klik Create dan tunggu hingga pengujian menyelesaikan operasi pertama.
Dalam daftar uji konektivitas, klik Lihat untuk melihat hasil eksekusi.
Jika hasilnya "Tidak dapat dijangkau", artinya Anda mengalami masalah dengan konfigurasi. Alat ini akan mengarahkan Anda ke dokumentasi Status Uji Konektivitas untuk melanjutkan lebih lanjut. Jika statusnya "Dapat Dijangkau", berarti banyak masalah konfigurasi yang dapat dikecualikan. Namun, hal ini tidak menjamin bahwa target dapat dijangkau. Belum ada upaya sebenarnya untuk membuat koneksi TCP dengan target. Hanya diagnosis berikutnya di bawah ini yang akan membantu mengujinya.

Pengujian konektivitas VM (semua target)

Di VPC yang sama dengan yang di-peering dengan Apigee, buat Instance VM di Linux.
Lakukan pengujian 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
```
Periksa output lengkap dan cari error ini:
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
Kehadiran error ini mengonfirmasi bahwa masalah dapat direproduksi di luar Apigee.

Perhatikan bahwa jika Anda melihat error lain, seperti error terkait TLS, kode status yang buruk, dll., pesan tersebut tidak mengonfirmasi waktu tunggu koneksi habis dan tidak terkait dengan masalah ini.
Jika target memerlukan daftar yang diizinkan IP, Anda mungkin tidak dapat mengujinya dari VM kecuali jika Anda juga mengizinkan IP sumber instance VM.

Resolusi

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

Jika waktu tunggu diproduksi ulang dari VM, tidak ada panduan pasti tentang cara menyelesaikan masalah di sisi target. Setelah waktu tunggu koneksi dapat direproduksi di luar Apigee, lanjutkan masalah dari VPC. Cobalah untuk menguji 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 perlu mengajukan kasus dukungan Google Cloud pada tahap tersebut, Anda tidak perlu lagi memilih komponen Apigee, karena masalah tersebut sekarang 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 izin di target, Anda dapat melewati bagian ini.

Masalah ini lebih mudah ditemukan jika error bersifat intermiten, karena dalam hal ini Anda mungkin dapat menemukan korelasi antara IP NAT tertentu dan error.

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

Cantumkan 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 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 yang mengizinkan akses ke internet, yang juga merupakan masalah.

Jika Anda memiliki minimal satu alamat ACTIVE, alamat tersebut dapat 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 intermiten, hal itu mungkin menunjukkan bahwa hanya sebagian IP NAT yang telah diizinkan di target. Untuk mengidentifikasinya:

Buat Reverse proxy baru dengan target yang terpengaruh ditentukan di TargetEndpoint. Anda juga dapat menggunakan kembali proxy yang ada dan melanjutkan ke langkah berikutnya:
Tambahkan kebijakan ServiceCallout ke Pra-Alur 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" sehingga konten terlihat 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 NAT IP dari permintaan yang terpengaruh cocok dengan NAT IP yang diperoleh dari ServiceCallout.
Jalankan sesi Debug dan klik langkah ServiceCallout:
Di sudut kanan bawah, Anda akan melihat bagian Response content yang berisi NAT IP (di Body) dari instance Apigee yang membuat permintaan. Atau, jika Anda menyimpan respons ServiceCallout di tempat lain, Anda akan melihatnya di sana.

Perhatikan bahwa nanti dalam alur, proxy akan memanggil target dan Konten respons akan ditimpa dengan error atau respons dari target.
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.
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. Hal ini mungkin karena kehabisan NAT. Lihat Penyebab: Kehabisan port IP NAT.

Resolusi

Pastikan Anda telah menyediakan dan mengaktifkan IP NAT dan memastikan bahwa semuanya ditambahkan di sisi target.

Penyebab: Kehabisan port IP NAT

Diagnosis

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

Perhatikan jangka waktu masalah. Misalnya: setiap hari antara pukul 17.58 - 18.08.
Konfirmasi apakah target lain terpengaruh oleh masalah 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.
Tentukan apakah error hanya terjadi di atas volume traffic tertentu di TPS. Untuk melakukannya, catat rentang waktu masalah, lalu buka dasbor Performa Proxy.
Coba korelasikan periode waktu error dengan peningkatan Transaksi rata-rata per detik (tps).

Dalam contoh ini, tps meningkat menjadi 1.000 pada pukul 17.58. Dengan asumsi bahwa dalam contoh ini, pukul 17.58 adalah waktu terjadinya masalah, dan masalah tersebut memengaruhi dua atau beberapa target yang tidak terkait, yang merupakan sinyal masalah terkait kehabisan 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 tindakan tersebut dapat menyelesaikan masalah. Perhatikan bahwa menambahkan lebih banyak IP mungkin memerlukan izin terlebih dahulu di semua target.

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 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 itu adalah penyebab masalahnya. Jika Anda tidak melihat properti "connect.timeout.millis" tersebut, nilai default akan ditetapkan dan penyebabnya tidak dikonfirmasi.

Proxy dengan waktu tunggu

Resolusi

Perbaiki nilai connect.timeout.millis, pastikan untuk memperhatikan bahwa satuan waktu dalam milidetik. Nilai defaultnya adalah 3000, yaitu 3.000 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:

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