Bu sayfa, Cloud Translation API ile çevrilmiştir.

Sorun giderme

Apigee Edge belgelerini görüntülüyorsunuz.
Apigee X belgelerine gidin. bilgi

ISRC 404 (Bulunamadı) hatası

ISRC'de 404 (Bulunamadı) hatası ayıklamak can sıkıcı olabilir. Umarız bu bilgiler size nerede sorun olabileceğini takip etmeye başlayabileceğiniz bir kaynak sağlar.

Joker karakter Ağ Geçidi çakışması

"*" joker karakteri ana makine değeri kullanan yalnızca bir Ağ Geçidi tanımı olabilir. Joker karakterli ağ geçidi içeren başka bir dağıtım yaptıysanız istemci çağrıları 404 durumunda başarısız olur.

Örnek:

$ istioctl get gateways
GATEWAY NAME         HOSTS     NAMESPACE   AGE
bookinfo-gateway     *         default     20s
httpbin-gateway      *         default     3s

Öyleyse çakışan ağ geçitlerinden birini silmeniz veya değiştirmeniz gerekir.

Rotanın başarısız olduğu yeri çiz

Istio bir soğan (ya da belki bir canavar) gibidir, katmanları vardır. 404 hataları ayıklamanın sistematik bir yolu, hedeften uzaklaşmaktır.

Arka uç iş yükü

İş yüküne yardımcı dosyadan erişebileceğinizi doğrulayın:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers

Arka uç yardımcısı

Hizmet adresinizi ayarlayın ve iş yükü kapsülünün IP adresini alın.

SERVICE=httpbin.default.svc.cluster.local:80
  POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')

İş yüküne yardımcı dosya üzerinden erişin:

kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"

Alternatif olarak, ISRC mTLS etkinse:

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

Ağ geçidi (veya bir ön uç yardımcı dosya)

Hizmete ağ geçidinden erişin:

kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header

Alternatif olarak, ISRC mTLS etkinse:

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

Analiz eksik

Analytics kullanıcı arayüzünde analizleri göremiyorsanız bunun olası nedenleri şunlardır:

Apigee girişi birkaç dakika gecikebilir
Envoy gRPC Erişim Günlüğü doğru şekilde yapılandırılmadı
Envoy Uzaktan Hizmet'e erişemiyor
Uzak Hizmet yüklenemedi

Eksik veya bozuk API anahtarı reddedilmiyor

API anahtarı doğrulaması düzgün çalışmıyorsa şu olası nedenleri göz önünde bulundurun:

Doğrudan proxy

ext-authz yapılandırmasını kontrol edin.

Yardımcı dosya

İşleyicinin kesme noktası için yapılandırıldığından emin olun.
ext-authz yapılandırmasını kontrol edin.

Geçersiz istekler kontrol ediliyor ve izin veriliyor

Remote Service, başarısız olarak açılmak üzere yapılandırıldı
Envoy, RBAC kontrolleri için yapılandırılmadı

Bu sorunların nasıl düzeltileceği hakkında bilgi edinmek için Harici Yetkilendirme başlıklı Envoy dokümanlarının konusunu ve failure_mode_allow mülküyle ilgili bilgileri inceleyin. Bu özellik, filtrenin hatalar üzerindeki davranışını değiştirmenize olanak tanır.

Eksik veya bozuk JWT reddedilmiyor

Bunun olası nedeni Envoy JWT filtresinin yapılandırılmamış olmasıdır.

Geçerli API anahtarı başarısız

Olası nedenler

Envoy uzak hizmete ulaşamıyor
Kimlik bilgileriniz geçerli değil
Apigee API Ürünü hedef ve ortam için yapılandırılmadı

Sorun giderme adımları

Apigee'de API Ürününüzü Kontrol Etme

Ortamınız için etkin mi (test ve üretim)?
Ürün, Remote Service'inizle aynı ortama bağlı olmalıdır.
Eriştiğiniz hedefe bağlı mı?
Apigee uzak hizmet hedefleri bölümünü kontrol edin. Hizmet adının tam nitelikli bir ana makine adı olması gerektiğini unutmayın. Bu bir Istio hizmetiyse ad, default ad alanındaki helloworld hizmetini temsil eden helloworld.default.svc.cluster.localcode> gibi bir ad olur.
Kaynak Yolu isteğinizle eşleşiyor mu?
/ veya /** gibi bir yolun her yol ile eşleşeceğini unutmayın. Eşleştirme için "*" veya "**" joker karakterlerini de kullanabilirsiniz.
Geliştirici Uygulamanız var mı?
API Ürünü, anahtarlarının kontrol edilmesi için bir Geliştirici Uygulaması'na bağlanmalıdır.

İsteğinizi kontrol etme

x-api-key header içinde tüketici anahtarını iletiyor musunuz?

Örnek:

curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"

İyi bir tüketici anahtarı kullanıyor musunuz?
Kullandığınız Uygulamadaki Kimlik Bilgilerinin API Ürününüz için onaylandığından emin olun.

Uzak Hizmet günlüklerini kontrol etme

debug level adresinde günlük kaydı yaparak Remote Service'i başlatın. Uzak hizmet günlüğü düzeyleri belirleme başlıklı makaleye bakın.
Komut satırında -l debug seçeneğini kullanın. Örneğin:
```
apigee-remote-service-envoy -l debug
```

Hedefinize erişmeyi ve günlükleri kontrol etmeyi deneyin

Günlüklerde aşağıdakine benzer bir satır olup olmadığını kontrol edin:

Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: []
Selected: [helloworld]
Eliminated: [helloworld2 doesn't match path: /hello]

Uzak hizmet günlüğü düzeylerini ayarlama

Bir komut satırı işareti kullanarak uzak hizmeti, debug en ayrıntılı, error ise en az ayrıntı olacak şekilde ayrıntı sırasına göre aşağıdaki hata ayıklama modlarından birinde başlatabilirsiniz:

debug: En ayrıntılı günlük kaydı modu.
info: Varsayılan değer.
warn
error - En az ayrıntılı günlük kaydı modu.

Örneğin, hizmeti debug düzeyinde başlatmak için:

apigee-remote-service-envoy -l debug