इस पेज का अनुवाद Cloud Translation API से किया गया है.

समस्या का हल

आपको 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 यूज़र इंटरफ़ेस (यूआई) में आंकड़े नहीं दिख रहे हैं, तो इन वजहों से ऐसा करें:

Apigee को लेने में कुछ मिनट लग सकते हैं
Envoy gRPC ऐक्सेस लॉग सही तरीके से कॉन्फ़िगर नहीं किया गया
Envoy रिमोट सेवा तक नहीं पहुँच सकता
रिमोट सेवा से अपलोड नहीं हो पा रहा है

एपीआई पासकोड मौजूद नहीं है या गलत है, उसे अस्वीकार नहीं किया जा रहा है

अगर एपीआई पासकोड की पुष्टि करने की सुविधा ठीक से काम नहीं कर रही है, तो इसकी ये संभावित वजहें हो सकती हैं:

डायरेक्ट प्रॉक्सी

ext-authz कॉन्फ़िगरेशन की जांच करें.

Sidecar

पक्का करें कि लिसनर को इंटरसेप्ट के लिए कॉन्फ़िगर किया गया हो.
ext-authz कॉन्फ़िगरेशन की जांच करें.

अमान्य अनुरोधों की जांच की जा रही है और उन्हें अनुमति दी जा रही है

फ़ेल होने के लिए कॉन्फ़िगर की गई रिमोट सेवा
आरबीएसी जांच के लिए एंवॉय को कॉन्फ़िगर नहीं किया गया

इन समस्याओं को हल करने के बारे में जानकारी के लिए, Envoy से जुड़ा ये दस्तावेज़ देखें topic: बाहरी अनुमति, और failure_mode_allow प्रॉपर्टी के बारे में जानकारी देखें. यह प्रॉपर्टी इसकी मदद से, गड़बड़ियों पर फ़िल्टर का व्यवहार बदला जा सकता है.

गुम या गलत JWT अस्वीकार नहीं किया जा रहा है

इसकी संभावित वजह यह है कि Envoy JWT फ़िल्टर कॉन्फ़िगर नहीं किया गया है.

मान्य एपीआई पासकोड हासिल नहीं किया जा सका

संभावित वजहें

एंवॉयर रिमोट सेवा तक नहीं पहुंच पा रहे हैं
आपके क्रेडेंशियल मान्य नहीं हैं
Apigee एपीआई प्रॉडक्ट को टारगेट और एनवायरमेंट के लिए कॉन्फ़िगर नहीं किया गया है

समस्या हल करने का तरीका

Apigee पर अपना एपीआई प्रॉडक्ट देखें

क्या यह आपके एनवायरमेंट (टेस्ट बनाम प्रोडक्शन) के लिए चालू है?
प्रॉडक्ट को उसी एनवायरमेंट से जुड़ा होना चाहिए जिससे आपकी Remote Service चालू होती है.
क्या यह उस टारगेट तक सीमित है जिसे ऐक्सेस किया जा रहा है?
Apigee रिमोट सर्विस टारगेट सेक्शन देखें. याद रखें, सेवा का नाम पूरी तरह क्वालिफ़ाइड होस्ट का नाम. अगर यह Istio सेवा है, तो नाम कुछ ऐसा होगा helloworld.default.svc.cluster.localcode> - जो helloworld सेवा के बारे में बताती है default नेमस्पेस में.
क्या संसाधन पाथ आपके अनुरोध से मेल खाता है?
याद रखें कि / या /** जैसा पाथ किसी भी पाथ से मेल खाएगा. आप '*' का भी उपयोग कर सकते हैं या '**' वाइल्डकार्ड का इस्तेमाल करें.
क्या आपके पास डेवलपर ऐप्लिकेशन है?
एपीआई प्रॉडक्ट की कुंजियों की जांच करने के लिए, यह ज़रूरी है कि वह किसी डेवलपर ऐप्लिकेशन से जुड़ा हो.

अनुरोध की जांच करना

क्या आप 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 सबसे ज़्यादा वर्बोस मैसेज है, जबकि error का मतलब सबसे कम है:

debug - सबसे ज़्यादा जानकारी वाला लॉगिंग मोड.
info - डिफ़ॉल्ट.
warn
error - बहुत कम शब्दों में जानकारी लॉग करने वाला मोड.

उदाहरण के लिए, debug लेवल पर सेवा शुरू करने के लिए:

apigee-remote-service-envoy -l debug