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

Apigee Edge का दस्तावेज़ देखा जा रहा है.
Apigee X के दस्तावेज़ पर जाएं. info

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

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

गड़बड़ी का मैसेज

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

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

यहां दी गई टेबल में, Edge UI Trace में एपीआई अनुरोधों को कैप्चर न कर पाने की संभावित वजहें बताई गई हैं:

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

गड़बड़ी का पता लगाना

ट्रेस सेशन में एपीआई अनुरोध को कैप्चर करने के लिए, एपीआई अनुरोध को 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 Router पर अनुरोध पूरे नहीं होते

• वजह

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

  Received fatal alert: handshake_failure
  

  HTTP/1.1 400 Bad Request
  

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

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

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

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

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

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

• वजह

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

  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