Edge यूज़र इंटरफ़ेस (यूआई) में एपीआई अनुरोध शामिल नहीं हैं

आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस पेज पर जाएं Apigee X दस्तावेज़. जानकारी

समस्या का ब्यौरा

इस इमेज में दिखाया गया है कि ट्रेस सेशन शुरू होने पर, एपीआई अनुरोधों को Edge यूज़र इंटरफ़ेस (यूआई) में कैप्चर नहीं किया जाता:

गड़बड़ी संदेश

ऐसा होने पर, Edge के यूज़र इंटरफ़ेस (यूआई) में गड़बड़ी का कोई मैसेज नहीं दिखेगा.

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

Edge यूज़र इंटरफ़ेस (यूआई) ट्रेस में एपीआई अनुरोधों को कैप्चर नहीं कर पाने की संभावित वजहें नीचे दी गई हैं:

वजह: वे अनुरोध जिन्हें मैसेज प्रोसेसर ने प्रोसेस नहीं किया

डायग्नोसिस

ट्रेस सेशन में एपीआई अनुरोध को कैप्चर करने के लिए, Edge के कॉम्पोनेंट मैसेज प्रोसेसर से एपीआई अनुरोध को प्रोसेस करना ज़रूरी है. किसी ट्रेस लेन-देन में, एपीआई अनुरोध को कैप्चर न किए जाने की कई वजहें हो सकती हैं.

उदाहरण के लिए, अगर कोई एपीआई अनुरोध, Apigee Edge तक नहीं पहुंच पाता है, तो Edge के एंट्री पॉइंट पर फ़ेल हो जाता है (यानी, राऊटर) बंद हो जाता है या मैसेज प्रोसेसर के प्रोसेस करने से पहले काम नहीं करता, तो ट्रेस कैप्चर नहीं किया जा सकता. इन सभी स्थितियों के बारे में नीचे ज़्यादा जानकारी दी गई है.

पहली स्थिति: अनुरोध, Apigee Edge तक नहीं पहुंच पा रहे हैं

• वजह

  ऐसी स्थिति में, गड़बड़ी की वजह डीएनएस रिज़ॉल्यूशन या नेटवर्क कनेक्टिविटी की समस्या हो सकती है. अगर ऐसा है, तो इस निर्देश को चलाते समय आपको गड़बड़ी का यह मैसेज दिख सकता है:

  curl https://hostName:port/apiProxyBasePath/requestPath
  

  curl: (6) Could not resolve host: hostName
  

• रिज़ॉल्यूशन

  यहां दिए गए निर्देश की मदद से, डीएनएस कॉन्फ़िगरेशन की पुष्टि की जा सकती है:

  dig hostName

  नेटवर्क कनेक्टिविटी की पुष्टि करने के लिए, नीचे दिए गए निर्देश का इस्तेमाल करें:

  telnet hostName port

दूसरी स्थिति: Apigee Edge राऊटर पर अनुरोध पूरा नहीं हो पा रहे हैं

• वजह

  ऐसी स्थिति में, TLS/एसएसएल हैंडशेक के काम न करने की वजह से गड़बड़ी हो सकती है. अगर ऐसा है, तो आपको इनमें से कोई एक गड़बड़ी दिख सकती है:

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

  आपको एसएसएल सर्टिफ़िकेट से जुड़ी गड़बड़ी भी दिख सकती है.

• रिज़ॉल्यूशन

  इन समस्याओं को हल करने के लिए, ये प्लेबुक देखें:

  टीएलएस/एसएसएल हैंडशेक की गड़बड़ियां

  400 गलत अनुरोध - एसएसएल सर्टिफ़िकेट की गड़बड़ी

तीसरी स्थिति: मैसेज प्रोसेसर, अनुरोधों को प्रोसेस नहीं कर सकता

• वजह

  इस स्थिति में, Apigee मैसेज प्रोसेसर को इनके लिए एपीआई प्रॉक्सी नहीं मिल सकता दर्ज वर्चुअल होस्ट और पथ. इस वजह से, आपको निम्न त्रुटियां:

  HTTP/1.1 404 Not Found
  

  {
    "fault":{
      "faultstring":"Unable to identify proxy for host: default and url: \/apiProxyBasePath/requestPath",
      "detail":{
        "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
    }
  }
  
  

• रिज़ॉल्यूशन

  इस समस्या को हल करने और इसे ठीक करने के लिए, यह प्लेबुक देखें: 404 होस्ट के लिए प्रॉक्सी की पहचान नहीं की जा सकी.

वजह: क्लासिफ़िकेशन ट्री में एपीआई प्रॉक्सी नहीं मिला

डायग्नोसिस

अगर किसी मैसेज प्रोसेसर को अपने क्लासिफ़िकेशन ट्री में एपीआई प्रॉक्सी नहीं मिलती, तो उस खास प्रॉक्सी के लिए किया गया कोई भी एपीआई अनुरोध, Edge के यूज़र इंटरफ़ेस (यूआई) में ट्रेस सेशन में नहीं दिखेगा.

अगर ऐसा है, तो यह तय करने के लिए नीचे दिया गया तरीका अपनाएं:

1. हर मैसेज प्रोसेसर में लॉग इन करें और यह देखें कि अनुरोध किए गए एपीआई में, नीचे दिए गए कमांड का इस्तेमाल करके मैसेज प्रोसेसर के सही एनवायरमेंट में उसे डिप्लॉय किया गया है या नहीं:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   आउटपुट का उदाहरण:

   ऊपर दिए गए निर्देश से, डिप्लॉय किए गए बदलावों की सूची दिखेगी. उदाहरण के लिए, अगर संशोधन 12 लागू किया जाता है, तो आपको यह आउटपुट दिखेगा:

   [ "12" ]
   

   अगर आपको बार-बार एचटीटीपी 404 वाली गड़बड़ियों का सामना नहीं करना पड़ता, तो हो सकता है कि आपको यह पता चले कि खास बदलाव लागू किया गया है.

2. क्लासिफ़िकेशन ट्री को पढ़ें और नीचे दिए गए कमांड का इस्तेमाल करके, देखें कि एपीआई प्रॉक्सी का नाम मौजूद है या नहीं:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

3. हर मैसेज प्रोसेसर के लिए, पहले और दूसरे चरण को दोहराएं. अगर किसी मैसेज प्रोसेसर के क्लासिफ़िकेशन ट्री में, एपीआई प्रॉक्सी का नाम मौजूद नहीं है, तो नीचे दिए गए समाधान को अपनाएं.

रिज़ॉल्यूशन

इस समस्या को हल करने के लिए, कृपया यहां बताया गया तरीका अपनाएं. बहुत ज़्यादा अनुरोध लोड होने के दौरान, मैसेज प्रोसेसर को रीस्टार्ट करने पर, प्रोडक्शन में रुकावट से बचने के लिए सभी ज़रूरी सावधानी बरतें.

1. हर उस मैसेज प्रोसेसर होस्ट में लॉग इन करें जिसके लिए क्लासिफ़िकेशन ट्री में खास एपीआई प्रॉक्सी मौजूद नहीं है. साथ ही, मैसेज प्रोसेसर को रीस्टार्ट करने के लिए, नीचे दिए गए निर्देश का इस्तेमाल करें:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
   

2. रीस्टार्ट होने के बाद, इसके चालू होने तक इंतज़ार करने के लिए, नीचे दिए गए निर्देश का इस्तेमाल करें:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready
   

3. मैसेज प्रोसेसर तैयार हो जाने के बाद, नीचे दिए गए निर्देश का इस्तेमाल करके, एपीआई प्रॉक्सी की उपलब्धता की पुष्टि करें:

   curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions
   

   आउटपुट का उदाहरण:

   ऊपर दिए गए निर्देश से, डिप्लॉय किए गए बदलावों की सूची दिखेगी. उदाहरण के लिए, अगर संशोधन 12 लागू किया जाता है, तो आपको यह आउटपुट दिखेगा:

   [ "12" ]
   

   अगर आपको बार-बार एचटीटीपी 404 वाली गड़बड़ियों का सामना नहीं करना पड़ता, तो हो सकता है कि आपको यह पता चले कि खास बदलाव लागू किया गया है.

4. क्लासिफ़िकेशन ट्री को पढ़ें और इस कमांड का इस्तेमाल करके, एपीआई प्रॉक्सी नाम की पुष्टि करें:

   curl -i http://localhost:8082/v1/classification/tree | grep apiName
   

   अगर इसके बाद भी समस्या बनी रहती है, तो गड़बड़ी की जानकारी ज़रूर इकट्ठा करें पर जाएं.

गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है

अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया गड़बड़ी से जुड़ी यह जानकारी इकट्ठा करें और उसे Apigee Edge की सहायता टीम के साथ शेयर करें:

curl -v management-server-host:8080/v1/runtime/organizations/orgName/environments/envName/apis/apiProxyName/revisions/revisionNumber/debugsessions -u user

/opt/apigee/var/log/edge-management-server/logs/system.log

/opt/apigee/var/log/edge-message-processor/logs/system.log

telnet MessageProcessor_IP 8082

nc -vz MessageProcessor_IP 8082

netstat -an > netstat.txt

curl -v http://localhost:8082/v1/runtime/organizations/orgName/environments/envName/apis/apiName/revisions

curl -i http://localhost:8082/v1/classification/tree