Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
Istio 404 (नहीं मिला) गड़बड़ी
Istio पर 404 (नहीं मिला) गड़बड़ी को डीबग करना परेशानी भरा हो सकता है. उम्मीद है कि इससे आपको गड़बड़ी की वजह का पता लगाने के लिए एक जगह मिल जाएगी.
वाइल्डकार्ड गेटवे में विवाद
सिर्फ़ एक गेटवे की परिभाषा हो सकती है, जो वाइल्डकार्ड "*" होस्ट की वैल्यू का इस्तेमाल करती हो. अगर आपने वाइल्डकार्ड गेटवे वाला कोई दूसरा तरीका डिप्लॉय किया है, तो क्लाइंट कॉल 404 स्टेटस के साथ फ़ेल हो जाएंगे.
उदाहरण:
$ istioctl get gateways GATEWAY NAME HOSTS NAMESPACE AGE bookinfo-gateway * default 20s httpbin-gateway * default 3s
अगर ऐसा है, तो आपको विरोधी गेटवे में से किसी एक को मिटाना या बदलना होगा.
ट्रेस करें कि रूट कहां पर नहीं जा रहा है
इस्तियो एक प्याज़ (या शायद एक राक्षस) की तरह है, इसमें परतें होती हैं. 404 कोड को डीबग करने का एक व्यवस्थित तरीका है, टारगेट से बाहर की ओर काम करना.
बैकएंड वर्कलोड
पुष्टि करें कि आपके पास साइडकार से वर्कलोड ऐक्सेस करने का विकल्प है:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl localhost:80/headers
बैकएंड साइडकार
सेवा का पता सेट करें और वर्कलोड पॉड का आईपी पता पाएं.
SERVICE=httpbin.default.svc.cluster.local:80 POD_IP=$(kubectl get pod $WORKLOAD_POD -o jsonpath='{.status.podIP}')
साइडकार से वर्कलोड ऐक्सेस करें:
kubectl exec $WORKLOAD_POD -c istio-proxy -- curl -v http://$SERVICE/headers --resolve "$SERVICE:$POD_IP"
इसके अलावा, अगर Istio mTLS की सुविधा चालू है, तो:
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
गेटवे (या फ़्रंटएंड साइडकार)
गेटवे से सेवा ऐक्सेस करें:
kubectl -n istio-system exec $GATEWAY_POD -- curl -v http://$SERVICE/header
इसके अलावा, अगर Istio mTLS की सुविधा चालू है, तो:
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
आंकड़े मौजूद नहीं हैं
अगर आपको Analytics यूज़र इंटरफ़ेस (यूआई) में आंकड़े नहीं दिख रहे हैं, तो इन संभावित वजहों पर विचार करें:
- एपिगी लेने में कुछ मिनट लग सकते हैं
- Envoy gRPC ऐक्सेस लॉग को सही तरीके से कॉन्फ़िगर नहीं किया गया है
- Envoy रिमोट सेवा से कनेक्ट नहीं हो सका
- रिमोट सेवा अपलोड नहीं हो पा रही
एपीआई पासकोड मौजूद नहीं है या खराब है. उसे अस्वीकार नहीं किया जा रहा है
अगर एपीआई पासकोड की पुष्टि करने की सुविधा ठीक से काम नहीं कर रही है, तो इसकी ये वजहें हो सकती हैं:
डायरेक्ट प्रॉक्सी
ext-authz
के कॉन्फ़िगरेशन की जांच करें.
- पक्का करें कि लिसनर को इंटरसेप्ट करने के लिए कॉन्फ़िगर किया गया हो.
-
ext-authz
के कॉन्फ़िगरेशन की जांच करें.
अमान्य अनुरोधों की जांच की जा रही है और उन्हें अनुमति दी जा रही है
- फ़ेल ओपन के लिए कॉन्फ़िगर की गई रिमोट सेवा
- आरबीएसी जांच के लिए, एनवॉयर को कॉन्फ़िगर नहीं किया गया है
इन समस्याओं को हल करने के बारे में जानकारी के लिए, Envoy के दस्तावेज़ का यह विषय देखें: बाहरी अनुमति
और failure_mode_allow
प्रॉपर्टी के बारे में जानकारी देखें. इस प्रॉपर्टी की मदद से,
गड़बड़ियों पर फ़िल्टर के काम करने का तरीका बदला जा सकता है.
अनुपलब्ध या खराब JWT अस्वीकार नहीं किया जा रहा
संभावित वजह यह है कि Envoy JWT फ़िल्टर कॉन्फ़िगर नहीं किया गया है.
मान्य API कुंजी काम नहीं करती
संभावित वजहें
- Envoy रिमोट सेवा से कनेक्ट नहीं हो सकता
- आपके क्रेडेंशियल मान्य नहीं हैं
- Apigee API प्रॉडक्ट, टारगेट और एनवायरमेंट के लिए कॉन्फ़िगर नहीं किया गया है
समस्या हल करने का तरीका
Apigee पर अपने एपीआई प्रॉडक्ट की जांच करना
- क्या यह आपके एनवायरमेंट (टेस्ट बनाम प्रोडक्शन) के लिए चालू है?
प्रॉडक्ट उसी एनवायरमेंट से जुड़ा होना चाहिए जिससे आपकी रिमोट सेवा लागू होती है.
- क्या यह उस टारगेट से जुड़ा है जिसे ऐक्सेस किया जा रहा है?
Apigee रिमोट सेवा के टारगेट सेक्शन देखें. याद रखें, सेवा का नाम पूरी तरह क्वालिफ़ाइड होस्ट नाम होना चाहिए. अगर यह कोई Istio सेवा है, तो नाम कुछ ऐसा होगा
helloworld.default.svc.cluster.local
code> - जोdefault
नेमस्पेस मेंhelloworld
सेवा को दिखाता है. - क्या संसाधन पाथ आपके अनुरोध से मेल खाता है?
याद रखें कि
/
या/**
जैसा कोई पाथ किसी भी पाथ से मेल खाएगा. मैच करने के लिए, '*' या '**' वाइल्डकार्ड भी इस्तेमाल किए जा सकते हैं. - क्या आपके पास डेवलपर ऐप्लिकेशन है?
एपीआई प्रॉडक्ट कुंजियों की जांच करने के लिए, यह ज़रूरी है कि वह डेवलपर ऐप्लिकेशन से जुड़ा हो.
अपने अनुरोध की जांच करना
- क्या आपने
x-api-key header
में उपभोक्ता कुंजी पास की हैउदाहरण:
curl http://localhost/hello -H "x-api-key: wwTcvmHvQ7Dui2qwj43GlKJAOwmo"
- क्या आपके पास एक अच्छी उपभोक्ता कुंजी है?
पक्का करें कि आप ऐप्लिकेशन के जिन क्रेडेंशियल का इस्तेमाल कर रहे हैं उन्हें आपके एपीआई प्रॉडक्ट के लिए मंज़ूरी मिली हो.
रिमोट सर्विस के लॉग की जांच करना
-
debug level
पर लॉगिन करके रिमोट सेवा को शुरू करें. रिमोट सेवा के लॉग लेवल सेट करना देखें.कमांड लाइन पर,
-l debug
विकल्प का इस्तेमाल करें. उदाहरण के लिए:apigee-remote-service-envoy -l debug
- अपने टारगेट को ऐक्सेस करने की कोशिश करना और लॉग देखना
कुछ इस तरह दिखने वाली लाइन के लिए लॉग देखें:
Resolve api: helloworld.default.svc.cluster.local, path: /hello, scopes: [] Selected: [helloworld] Eliminated: [helloworld2 doesn't match path: /hello]
debug
- सबसे ज़्यादा जानकारी वाला लॉगिंग मोड.info
- डिफ़ॉल्ट.warn
error
- सबसे कम शब्दों में जानकारी देने वाला लॉगिंग मोड.
रिमोट सेवा के लॉग लेवल सेट करना
कमांड लाइन फ़्लैग का इस्तेमाल करके, इनमें से किसी एक डीबग मोड में रिमोट सेवा को वर्बोसिटी के क्रम में शुरू किया जा सकता है. इसमें debug
सबसे ज़्यादा वर्बोस और error
सबसे कम है:
उदाहरण के लिए, debug
लेवल पर सेवा शुरू करने के लिए:
apigee-remote-service-envoy -l debug