Halaman ini berlaku untuk Apigee dan Apigee Hybrid.
Baca dokumentasi Apigee Edge.
Error Istio 404 (Tidak Ditemukan)
Men-debug error 404 (Not Found) pada Istio bisa menjengkelkan. Semoga hal ini akan memberi Anda titik untuk melacak kesalahan yang terjadi.
Konflik Gateway Karakter Pengganti
Hanya ada satu definisi Gateway yang menggunakan nilai host "*" karakter pengganti. Jika Anda telah men-deploy fungsi lain yang menyertakan Gateway karakter pengganti, panggilan klien akan gagal dengan status 404.
Contoh:
$ istioctl get gateways GATEWAY NAME HOSTS NAMESPACE AGE bookinfo-gateway * default 20s httpbin-gateway * default 3s
Jika demikian, Anda harus menghapus atau mengubah salah satu gateway yang mengalami konflik.
Telusuri rute yang gagal
Istio itu seperti bawang (atau, mungkin, Ogre), ia memiliki lapisan. Cara sistematis untuk men-debug 404 adalah dengan menanganinya dari target.
Workload backend
Pastikan Anda dapat mengakses beban kerja dari file bantuan:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers
File bantuan backend
Tetapkan alamat layanan Anda dan dapatkan alamat IP pod workload.
SERVICE=httpbin.default.svc.cluster.local:80 POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')
Akses beban kerja melalui file bantuan:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"
Atau, jika Istio mTLS diaktifkan:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v https://$SERVICE/headers --resolve "$SERVICE:$POD_IP" --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure
Gateway (atau sidecar frontend)
Akses layanan dari gateway:
kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header
Atau, jika Istio mTLS diaktifkan:
kubectl -n istio-system exec $GATEWAY_POD -- curl -v https://$SERVICE/headers --key /etc/certs/key.pem --cert /etc/certs/cert-chain.pem --cacert /etc/certs/root-cert.pem --insecure
Analisis tidak ada
Jika Anda tidak melihat analisis di UI Analytics, pertimbangkan kemungkinan penyebab berikut:
- Asupan Apigee dapat tertunda beberapa menit
- Log Akses Envoy gRPC tidak dikonfigurasi dengan benar
- Envoy tidak dapat menjangkau Layanan Jarak Jauh
- Layanan Jarak Jauh gagal diupload
Kunci API tidak ada atau buruk tidak ditolak
Jika validasi kunci API tidak berfungsi dengan baik, pertimbangkan kemungkinan penyebab berikut:
Proxy langsung
Periksa konfigurasi ext-authz
.
- Pastikan pemroses dikonfigurasi untuk intersepsi.
- Periksa konfigurasi
ext-authz
.
Permintaan yang tidak valid akan diperiksa dan diizinkan
- Layanan Jarak Jauh dikonfigurasi untuk membuka kegagalan
- Envoy tidak dikonfigurasi untuk pemeriksaan RBAC
Untuk informasi tentang cara mengatasi masalah ini, lihat topik dokumentasi Envoy
berikut: Otorisasi Eksternal,
dan lihat informasi tentang properti failure_mode_allow
. Properti ini memungkinkan Anda mengubah perilaku filter pada error.
JWT tidak ada atau buruk tidak ditolak
Kemungkinan penyebabnya adalah filter Envoy JWT tidak dikonfigurasi.
Kunci API yang valid gagal
Kemungkinan penyebab
- Envoy tidak dapat menjangkau layanan jarak jauh
- Kredensial Anda tidak valid
- Produk Apigee API tidak dikonfigurasi untuk target dan env
- Envoy tidak mengetahui Produk API Apigee
Langkah pemecahan masalah
Periksa Produk API Anda di Apigee
- Apakah ini diaktifkan untuk lingkungan Anda (pengujian vs produksi)?
Produk harus terikat dengan lingkungan yang sama dengan Remote Service Anda.
- Apakah data terikat dengan target yang Anda akses?
Periksa bagian Target layanan jarak jauh Apigee. Ingat, nama layanan harus berupa nama host yang sepenuhnya memenuhi syarat. Jika ini adalah layanan Istio, namanya akan seperti
helloworld.default.svc.cluster.local
code> - yang mewakili layananhelloworld
di namespacedefault
. - Apakah Jalur Resource cocok dengan permintaan Anda?
Ingat, jalur seperti
/
atau/**
akan cocok dengan jalur apa pun. Anda juga dapat menggunakan karakter pengganti '*' atau '**' untuk pencocokan. - Apakah Anda memiliki Aplikasi Developer?
Produk API harus terikat dengan Aplikasi Developer untuk memeriksa kuncinya.
- Apakah OperationsConfigType Produk Apigee API ditetapkan ke remoteservice?
Periksa konfigurasi Produk API menggunakan Apigee Management API, dan pastikan
operationConfigType
disetel keremoteservice
.
Memeriksa permintaan
- Apakah Anda meneruskan Kunci Konsumen di
x-api-key header
Contoh:
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
- Apakah Anda menggunakan Kunci Konsumen yang baik?
Pastikan Kredensial dari Aplikasi yang Anda gunakan disetujui untuk Produk API Anda.
Memeriksa log Remote Service
- Mulai Remote Service dengan logging di
debug level
. Lihat Menetapkan tingkat log layanan jarak jauh.Gunakan opsi
-l debug
pada command line. Contoh:apigee-remote-service-envoy -l debug
- Mencoba mengakses target Anda dan memeriksa log
Periksa log untuk menemukan baris yang terlihat seperti ini:
Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: [] Selected: [helloworld] Eliminated: [helloworld2 doesn't match path: /hello]
Menyetel level log layanan jarak jauh
Dengan menggunakan tanda command line, Anda dapat memulai layanan jarak jauh di salah satu mode debug berikut, sesuai urutan panjangnya, dengan debug
adalah yang paling panjang dan error
yang paling sedikit:
debug
- Mode logging paling panjang.info
- Default.warn
error
- Mode logging panjang paling tidak.
Misalnya, untuk memulai layanan di level debug
:
apigee-remote-service-envoy -l debug