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

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

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

इस इमेज में दिखाया गया है कि ट्रेस सेशन शुरू होने पर, API अनुरोधों को 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
  

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

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

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

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

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

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

• वजह

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

  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. प्रत्येक संदेश प्रोसेसर में लॉग इन करें और यह देखने के लिए जांच करें कि क्या अनुरोध किए गए API का विशिष्ट संशोधन निम्न आदेश का उपयोग करके संदेश प्रोसेसर के प्रासंगिक परिवेश में परिनियोजित किया गया है:

   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. हर मैसेज प्रोसेसर के लिए, पहले और दूसरे चरण को दोहराएं. अगर दिया गया एपीआई प्रॉक्सी नाम किसी भी मैसेज प्रोसेसर के क्लासिफ़िकेशन ट्री से गायब है, तो नीचे दिए गए समाधान का पालन करें.

रिज़ॉल्यूशन

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

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. संदेश प्रोसेसर के तैयार हो जाने पर, निम्न आदेश का उपयोग करके API प्रॉक्सी की उपलब्धता को सत्यापित करें:

   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