404 होस्ट के लिए प्रॉक्सी की पहचान नहीं की जा सकी: <virtual होस्ट नाम> और यूआरएल: <path>

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

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

एपीआई कॉल के जवाब के तौर पर, क्लाइंट ऐप्लिकेशन को 404 एचटीटीपी स्टेटस कोड मिलता है. साथ ही, मैसेज Not Found और गड़बड़ी का मैसेज Unable to identify proxy for host: VIRTUAL_HOST and url: PATH मिलता है.

इस गड़बड़ी का मतलब है कि Edge को तय किए गए वर्चुअल होस्ट और पाथ के लिए एपीआई प्रॉक्सी नहीं मिली.

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

आपको यह एचटीटीपी स्टेटस कोड मिलेगा: 

HTTP/1.1 404 Not Found

आपको नीचे दिखाए गए गड़बड़ी के मैसेज जैसा कोई मैसेज भी दिखेगा: 

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

ऊपर दिए गए गड़बड़ी के मैसेज से पता चलता है कि Edge को default वर्चुअल होस्ट और /oauth2/token पाथ के लिए एपीआई प्रॉक्सी नहीं मिल सकी.

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

इस गड़बड़ी की कुछ संभावित वजहें यहां दी गई हैं:

वजह ब्यौरा इनके लिए समस्या हल करने के निर्देश
एपीआई प्रॉक्सी, किसी वर्चुअल होस्ट से जुड़ी नहीं है एपीआई प्रॉक्सी को, गड़बड़ी के मैसेज में बताए गए वर्चुअल होस्ट पर अनुरोध स्वीकार करने के लिए कॉन्फ़िगर नहीं किया गया है. Edge Public और Private Cloud के उपयोगकर्ताओं के लिए
एपीआई प्रॉक्सी के नए डिप्लॉय किए गए वर्शन में वर्चुअल होस्ट हटा दिया गया है क्लाइंट के अब भी किसी वर्चुअल होस्ट का इस्तेमाल करने के दौरान, वर्चुअल होस्ट को नए डिप्लॉय किए गए वर्शन से हटाने पर यह समस्या हो सकती है. Edge Public और Private Cloud के उपयोगकर्ताओं के लिए
पाथ, किसी भी एपीआई प्रॉक्सी से जुड़ा नहीं है एपीआई प्रॉक्सी को, गड़बड़ी के मैसेज में बताए गए पाथ पर अनुरोध स्वीकार करने के लिए कॉन्फ़िगर नहीं किया गया है. Edge Public और Private Cloud के उपयोगकर्ताओं के लिए
किसी एनवायरमेंट में एपीआई प्रॉक्सी डिप्लॉय नहीं की गई है एपीआई अनुरोध करने के लिए जिस एनवायरमेंट का इस्तेमाल किया जा रहा है उसमें एपीआई प्रॉक्सी डिप्लॉय नहीं की गई है. Edge Public और Private Cloud के उपयोगकर्ताओं के लिए
Message Processor पर एनवायरमेंट लोड नहीं हुआ है जिस एनवायरमेंट में एपीआई अनुरोध किए जा रहे हैं उसे गड़बड़ी की वजह से मैसेज प्रोसेसर पर लोड नहीं किया गया है. Edge Private Cloud के उपयोगकर्ता
एक या उससे ज़्यादा मैसेज प्रोसेसर पर एपीआई प्रॉक्सी डिप्लॉय नहीं की गई है ऐसा हो सकता है कि एपीआई प्रॉक्सी को एक या उससे ज़्यादा मैसेज प्रोसेसर पर डिप्लॉय न किया गया हो. इसकी वजह यह है कि डिप्लॉयमेंट के दौरान, इवेंट की सूचना नहीं मिली. Edge Private Cloud के उपयोगकर्ता

गड़बड़ी का पता लगाने के सामान्य चरण

NGINX और मैसेज प्रोसेसर के लॉग से, 404 गड़बड़ी को ठीक करने में मदद मिलेगी. लॉग देखने के लिए, यह तरीका अपनाएं:

  1. नीचे दिए गए कमांड का इस्तेमाल करके, NGINX लॉग देखें: 
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. लॉग एंट्री में इन फ़ील्ड की जांच करें:
    फ़ील्ड वैल्यू
    Upstream_status, status 404
    X-Apigee-fault-code messaging.adaptors.http.flow.ApplicationNotFound

    लॉग से मैसेज आईडी नोट करें.

  3. मैसेज प्रोसेसर के लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) देखें. इससे पता चलेगा कि आपके पास किसी खास एपीआई के लिए messaging.adaptors.http.flow.ApplicationNotFound है या नहीं. यह भी पता चलेगा कि आपके पास एपीआई अनुरोध के लिए, दूसरे चरण में मिला यूनीक मैसेज आईडी है या नहीं.

    मैसेज प्रोसेसर के लॉग में गड़बड़ी के मैसेज का उदाहरण

    4. NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractRequestListener.onException() : Request:POST, uri:/weather, message Id:null, exception:com.apigee.rest.framework.ResourceNotFoundException{ code = messaging.adaptors.http.flow.ApplicationNotFound, message = Unable to identify proxy for host: vh1 and url: /weather, associated contexts = []}, context:Context@342ea86b input=ClientInputChannel(SSLClientChannel[Accepted: Remote:10.123.123.123:8443 Local:10.135.33.68:62092]@1206954 useCount=1 bytesRead=0 bytesWritten=0 age=1ms  lastIO=0ms  isOpen=true)

    ऊपर दिए गए लॉग में, गड़बड़ी का कोड और गड़बड़ी का मैसेज इस तरह दिखता है:

    code = messaging.adaptors.http.flow.ApplicationNotFound,
message = Unable to identify proxy for host: vh1 and url: /weather

वजह: एपीआई प्रॉक्सी, किसी वर्चुअल होस्ट से जुड़ी नहीं है

अगर एपीआई प्रॉक्सी को किसी वर्चुअल होस्ट के अनुरोधों को स्वीकार करने के लिए कॉन्फ़िगर नहीं किया गया है, तो हमें गड़बड़ी के मैसेज Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. के साथ 404 Not Found जवाब मिल सकता है

संक्रमण की जांच

  1. एपीआई प्रॉक्सी के लिए, प्रॉक्सी एंडपॉइंट कॉन्फ़िगरेशन की जांच करें. साथ ही, देखें कि एपीआई प्रॉक्सी को गड़बड़ी में बताए गए वर्चुअल होस्ट के अनुरोधों को स्वीकार करने के लिए कॉन्फ़िगर किया गया है या नहीं. इसे VirtualHost एलिमेंट से दिखाया जाता है. इसे समझने के लिए, ProxyEndpoint के सैंपल कॉन्फ़िगरेशन को देखें.

    सैंपल प्रॉक्सी एंडपॉइंट कॉन्फ़िगरेशन, जिसमें दिखाया गया है कि एपीआई प्रॉक्सी, सुरक्षित वर्चुअल होस्ट पर अनुरोध स्वीकार करता है

  2. मान लें कि वर्चुअल होस्ट को किसी खास एनवायरमेंट में इस तरह से तय किया गया है:
    नाम पोर्ट होस्ट का उपनाम
    default 80 myorg-prod.apigee.net
    secure 443 myorg-prod.apigee.net
  3. आपने यूआरएल http://myorg-prod.apigee.net/weather का इस्तेमाल करके, default VirtualHost को एपीआई अनुरोध भेजा है
  4. ऊपर दिए गए उदाहरण में दिखाया गया है कि ProxyEndpoint में default VirtualHost नहीं है. इसलिए, आपको 404 रिस्पॉन्स कोड मिलता है. साथ ही, गड़बड़ी का यह मैसेज दिखता है: 
    {"fault":{"faultstring":"Unable to identify proxy for host: default and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  5. इस समस्या को हल करने के लिए, नीचे दिए गए हल सेक्शन पर जाएं.
  6. अगर ProxyEndpoint को default VirtualHost पर अनुरोध स्वीकार करने के लिए कॉन्फ़िगर किया गया है, तो अगली वजह पर जाएं - पाथ किसी एपीआई प्रॉक्सी से जुड़ा नहीं है.

रिज़ॉल्यूशन

  1. इस समस्या को ठीक करने के लिए, ProxyEndpoint कॉन्फ़िगरेशन में VirtualHost एट्रिब्यूट जोड़ें. ऊपर दिए गए उदाहरण के लिए, ProxyEndpoint कॉन्फ़िगरेशन में डिफ़ॉल्ट VirtualHost को इस तरह जोड़ा जा सकता है: 
    <VirtualHost>default</VirtualHost>

    डिफ़ॉल्ट>VirtualHost> को जोड़े जाने का तरीका दिखाने वाला, प्रॉक्सी एंडपॉइंट कॉन्फ़िगरेशन का सैंपल

  2. इसके अलावा, ऊपर दिए गए उदाहरण में, अगर आपको इस एपीआई प्रॉक्सी के लिए सिर्फ़ secure VirtualHost का इस्तेमाल करना है, तो एचटीटीपीएस प्रोटोकॉल का इस्तेमाल करके, सिर्फ़ secure VirtualHost पर एपीआई अनुरोध भेजें: 
    https://myorg-prod.apigee.net/weather

वजह: एपीआई प्रॉक्सी के नए डिप्लॉय किए गए वर्शन में वर्चुअल होस्ट हटा दिया गया है

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

संक्रमण की जांच

  1. एपीआई प्रॉक्सी के लिए, प्रॉक्सी एंडपॉइंट कॉन्फ़िगरेशन देखें. इससे यह पता चलेगा कि एपीआई प्रॉक्सी को गड़बड़ी में बताए गए वर्चुअल होस्ट के अनुरोधों को स्वीकार करने के लिए कॉन्फ़िगर किया गया है या नहीं. इसे ProxyEndpoint कॉन्फ़िगरेशन में मौजूद VirtualHost एलिमेंट से पता चलता है.
  2. अगर गड़बड़ी में बताया गया वर्चुअल होस्ट, ProxyEndpoint कॉन्फ़िगरेशन में मौजूद नहीं है, तो यह तरीका अपनाएं. अगर ऐसा नहीं है, तो अगले कारण पर जाएं - पाथ, किसी भी एपीआई प्रॉक्सी से जुड़ा नहीं है.
  3. डिप्लॉय किए गए पिछले वर्शन के ProxyEndpoint कॉन्फ़िगरेशन की तुलना, मौजूदा समय में डिप्लॉय किए गए वर्शन से करें.
    1. उदाहरण के लिए, मान लें कि आपने पहले 5 वर्शन डिप्लॉय किया था और अब 6 वर्शन डिप्लॉय किया है:
      • पांचवें वर्शन में प्रॉक्सी एंडपॉइंट में कॉन्फ़िगर किए गए वर्चुअल होस्ट
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • छठे वर्शन में प्रॉक्सी एंडपॉइंट में कॉन्फ़िगर किए गए वर्चुअल होस्ट
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. ऊपर दिए गए उदाहरण में, VirtualHost vh1, revision 5, में मौजूद था, लेकिन revision 6 में इसे हटा दिया गया है और इसकी जगह VirtualHost secure को जोड़ दिया गया है.
    3. इसलिए, अगर आपने या आपके क्लाइंट ने VirtualHost vh1 का इस्तेमाल करके, इस एपीआई प्रॉक्सी को अनुरोध भेजे हैं (जो revision 5 का हिस्सा था), तो आपको गड़बड़ी के इस मैसेज के साथ 404 रिस्पॉन्स कोड मिलेगा: 
      {"fault":{"faultstring":"Unable to identify proxy for host: vh1 and url: \/weather","detail":{"errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"}}}
  4. देखें कि वर्चुअल होस्ट में बदलाव, मौजूदा डिप्लॉय किए गए वर्शन में जान-बूझकर किया गया है या अनजाने में. इसके बाद, समस्या हल करना सेक्शन में बताए गए तरीके से ज़रूरी कार्रवाई करें.

रिज़ॉल्यूशन

अगर आपको पता चलता है कि नए वर्शन में वर्चुअल होस्ट हटा दिए गए हैं, तो हो सकता है कि ऐसा जान-बूझकर किया गया हो या गलती से हुआ हो. हर मामले में, समस्या को हल करने के लिए यहां दिया गया तरीका अपनाएं या सुझाए गए तरीके आज़माएं.

पहली स्थिति: जान-बूझकर किया गया बदलाव

अगर वर्चुअल होस्ट को जान-बूझकर हटाया गया है, तो इनमें से कोई एक विकल्प चुनें. हमारा सुझाव है कि आप पहला विकल्प चुनें:

  1. किसी दूसरे बेस पाथ के साथ एक नई प्रॉक्सी बनाएं और किसी दूसरे वर्चुअल होस्ट का इस्तेमाल करें (जो पहले डिप्लॉय किए गए संशोधन में मौजूद नहीं है).

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

    इससे यह पक्का किया जा सकेगा कि इस एपीआई प्रॉक्सी का इस्तेमाल करने वाले लोगों पर, इस बदलाव का कोई असर न पड़े.

  3. अगर आपको मौजूदा एपीआई प्रॉक्सी का इस्तेमाल करना है और सिर्फ़ वर्चुअल होस्ट को बदलना है, तो अपने उपयोगकर्ताओं को इस बारे में पहले से बताएं. साथ ही, रखरखाव की अवधि के दौरान यह बदलाव करें.

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

दूसरी स्थिति: अनजाने में बदलाव होना

अगर वर्चुअल होस्ट को गलती से हटाया गया है,तो यह तरीका अपनाएं:

  1. फ़िलहाल डिप्लॉय किए गए वर्शन में ProxyEndpoint कॉन्फ़िगरेशन को अपडेट करें, ताकि उन वर्चुअल होस्ट का इस्तेमाल किया जा सके जिनका इस्तेमाल पहले डिप्लॉय किए गए वर्शन में किया गया था. ऊपर दिए गए उदाहरण में, इस सेक्शन को यहां दिए गए सेक्शन से बदलें: 
    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

    से

    <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
  2. बदलाव को फिर से लागू करें.

सबसे सही तरीके

हमेशा यह सलाह दी जाती है कि रखरखाव की अवधि के दौरान या जब ट्रैफ़िक कम होने की संभावना हो, तब नई प्रॉक्सी या नए वर्शन डिप्लॉय करें. इससे डिप्लॉयमेंट के दौरान आने वाली किसी भी समस्या से बचा जा सकता है या ट्रैफ़िक पर पड़ने वाले असर को कम किया जा सकता है.

वजह: पाथ, किसी भी एपीआई प्रॉक्सी से जुड़ा नहीं है

अगर एपीआई प्रॉक्सी को एपीआई अनुरोध के यूआरएल में इस्तेमाल किए गए किसी खास पाथ के अनुरोधों को स्वीकार करने के लिए कॉन्फ़िगर नहीं किया गया है, तो हमें गड़बड़ी के मैसेज Unable to identify proxy for host: VIRTUAL_HOST and url: PATH. के साथ 404 Not Found रिस्पॉन्स मिल सकता है

संक्रमण की जांच

  1. उस एपीआई प्रॉक्सी के लिए ProxyEndpoint कॉन्फ़िगरेशन देखें जिसके लिए आपको एपीआई अनुरोध करने हैं.
  2. देखें कि एपीआई प्रॉक्सी को, गड़बड़ी के मैसेज में बताए गए पाथ के अनुरोधों को स्वीकार करने के लिए कॉन्फ़िगर किया गया है या नहीं. इसके लिए, पहला तरीका और दूसरा तरीका अपनाएं.

पहली स्थिति: पाथ, एपीआई प्रॉक्सी के बेसपाथ से मैच नहीं करता

  1. अगर गड़बड़ी के मैसेज में बताया गया path, किसी खास एपीआई प्रॉक्सी के basepath से मेल नहीं खाता या यह basepath से शुरू नहीं होता है, तो यह गड़बड़ी की वजह हो सकती है.
  2. इसे एक उदाहरण से समझते हैं:
    1. जिस एपीआई प्रॉक्सी का इस्तेमाल करना है उसका basepath /weather है
    2. एपीआई अनुरोध का यूआरएल https://myorg-prod.apigee.net/climate है. इसका मतलब है कि एपीआई अनुरोध यूआरएल में इस्तेमाल किया गया पाथ /climate.
  3. इस उदाहरण में, path, basepath के बराबर नहीं है और यह basepath से शुरू नहीं होता है. इसलिए, आपको यह गड़बड़ी दिखती है: 
    {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/climate",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

रिज़ॉल्यूशन

  1. पक्का करें कि आपके एपीआई अनुरोध के यूआरएल में इस्तेमाल किया गया path, किसी खास एपीआई प्रॉक्सी के basepath के जैसा हो.
  2. ऊपर दिए गए उदाहरण में, एपीआई अनुरोध का यूआरएल इस तरह होना चाहिए: 
    {
https://myorg-prod.apigee.net/weather

दूसरी स्थिति: पाथ, शर्तों के साथ उपलब्ध किसी भी फ़्लो से मैच नहीं करता

  1. अगर एपीआई अनुरोध यूआरएल में इस्तेमाल किया गया path, basepath से शुरू होता है, तो हो सकता है कि गड़बड़ी के मैसेज में बताया गया path suffix (basepath के बाद आने वाला हिस्सा) किसी भी शर्त के हिसाब से तय किए गए फ़्लो से मेल न खाए. इस वजह से, 404 गड़बड़ी हो सकती है.
  2. इसे समझने के लिए, यहां एक उदाहरण दिया गया है:
    1. जिस एपीआई प्रॉक्सी का इस्तेमाल करना है उसका basepath /weather है
    2. एपीआई अनुरोध का यूआरएल https://myorg-prod.apigee.net/weather/Delhi है. इसका मतलब है कि एपीआई अनुरोध यूआरएल में इस्तेमाल किया गया पाथ /weather/Delhi.
  3. इस उदाहरण में, path basepath /weather से शुरू होता है. इसके अलावा, इसमें /Delhi का path suffix है.
  4. अब देखें कि ProxyEndpoint में कोई शर्त वाला फ़्लो तो नहीं है.
  5. अगर कोई शर्त वाला फ़्लो नहीं है या कुछ फ़्लो में शर्त नहीं है, तो अगली वजह पर जाएं - एपीआई प्रॉक्सी को किसी एनवायरमेंट में डिप्लॉय नहीं किया गया है.
  6. अगर ProxyEndpoint में सिर्फ़ शर्त के साथ उपलब्ध फ़्लो हैं, तो इनकी जांच करें:
    1. अगर इन सभी शर्तों वाले फ़्लो में, किसी खास proxy.pathsuffix (बेसपाथ के बाद का पाथ) की जांच की जाती है.
    2. अगर एपीआई अनुरोध के यूआरएल में दिया गया path suffix, किसी भी शर्त से मेल नहीं खाता है, तो गड़बड़ी की वजह यही है.
  7. मान लें कि हमारे पास ProxyEndpoint में दो फ़्लो हैं और दोनों फ़्लो, नीचे दिखाए गए तरीके से शर्त के हिसाब से काम करने वाले फ़्लो हैं: 
    <Condition>(proxy.pathsuffix MatchesPath "/Bangalore") and (request.verb = "GET")</Condition>

<Condition>(proxy.pathsuffix MatchesPath "/Chennai") and (request.verb = "GET")</Condition>
    1. ऊपर दिए गए उदाहरण में, हमारे पास दो कंडीशनल फ़्लो हैं. इनमें से एक proxy.pathsuffix (basepath के बाद का पाथ) से /Bangalore से मैच करता है और दूसरा /Chennai से मैच करता है. हालांकि, ऐसा कोई भी यूआरएल नहीं है जो /Delhi से मेल खाता हो. , एपीआई अनुरोध के यूआरएल में पास किया गया path suffix है.
    2. 404 गड़बड़ी की वजह यही है. इसलिए, आपको यह गड़बड़ी दिखेगी: 
      {
   "fault":{
      "faultstring":"Unable to identify proxy for host: secure and url: \/weather\/Delhi",
      "detail":{
         "errorcode":"messaging.adaptors.http.flow.ApplicationNotFound"
      }
   }
}

रिज़ॉल्यूशन

  1. पक्का करें कि path suffix, आपके प्रॉक्सी एंडपॉइंट में मौजूद कम से कम एक शर्त वाले फ़्लो से मेल खाता हो.
  2. ऊपर दिए गए उदाहरण में, गड़बड़ी को ठीक करने के लिए इनमें से कोई तरीका इस्तेमाल किया जा सकता है:
    1. अगर आपको /Delhi पाथ के लिए नीतियों का कोई खास सेट लागू करना है, तो नीतियों के ज़रूरी सेट के साथ एक अलग फ़्लो जोड़ें. साथ ही, यह पक्का करें कि /proxy.pathsuffix /Delhi से मेल खाने वाली कोई शर्त मौजूद हो. जैसा कि यहां दिखाया गया है: 
      <Condition>(proxy.pathsuffix MatchesPath "/Delhi") and (request.verb = "GET")</Condition>
    2. अगर आपको /Delhi पाथ के लिए नीतियों का एक सामान्य सेट लागू करना है, तो सामान्य फ़्लो में यह पक्का करें कि ऐसी कोई शर्त मौजूद हो जो सामान्य /proxy.pathsuffix की अनुमति देती हो. इसका मतलब है कि यह basepath /weather के बाद किसी भी पाथ की अनुमति देगा. जैसा कि यहां दिखाया गया है: 
      <Condition>(proxy.pathsuffix MatchesPath "/**") and (request.verb = "GET")</Condition>

अगर ProxyEndpoint में सही basepath मौजूद है और एपीआई यूआरएल में दिया गया path suffix, किसी एक शर्त के हिसाब से काम करने वाले फ़्लो से मेल खाता है, तो अगले कारण पर जाएं - किसी एनवायरमेंट में एपीआई प्रॉक्सी डिप्लॉय नहीं की गई है.

वजह: एपीआई प्रॉक्सी को किसी एनवायरमेंट में डिप्लॉय नहीं किया गया है

संक्रमण की जांच

  1. उस एनवायरमेंट का पता लगाएं जिसमें आपके एपीआई अनुरोध यूआरएल में इस्तेमाल किया गया होस्ट एलियास मौजूद है. इसके लिए, Edge UI में अपने संगठन के हर एनवायरमेंट में मौजूद सभी वर्चुअल होस्ट की जानकारी देखें.

    उदाहरण के लिए, मान लें कि कॉन्फ़िगरेशन इस तरह है:

    • अगर http://myorg-prod.apigee.net/weather आपका यूआरएल है, तो myorg-prod.apigee.net होस्ट का एलियास है.
    • होस्ट एलियास myorg-prod.apigee.net को आपके संगठन के prod एनवायरमेंट में मौजूद किसी वर्चुअल होस्ट के हिस्से के तौर पर कॉन्फ़िगर किया गया है.
  2. देखें कि क्या एपीआई प्रॉक्सी को ऊपर दिए गए पहले चरण में तय किए गए एनवायरमेंट में डिप्लॉय किया गया है.
  3. अगर एपीआई प्रॉक्सी को किसी खास एनवायरमेंट में डिप्लॉय नहीं किया गया है, तो 404 गड़बड़ी की वजह यही है.
    1. इसलिए, ऊपर दिए गए पहले चरण में इस्तेमाल किए गए उदाहरण में, मान लें कि एपीआई प्रॉक्सी को prod एनवायरमेंट में डिप्लॉय नहीं किया गया है. ऐसे में, यह गड़बड़ी की वजह है.
    2. नीचे दिए गए समस्या हल करना सेक्शन पर जाएं.
  4. अगर एपीआई प्रॉक्सी को किसी खास एनवायरमेंट में डिप्लॉय किया गया है, तो अगली वजह पर जाएं - मैसेज प्रोसेसर पर एनवायरमेंट लोड नहीं हुआ है.

रिज़ॉल्यूशन

एपीआई प्रॉक्सी को उस एनवायरमेंट में डिप्लॉय करें जिसमें आपको एपीआई अनुरोध करने हैं.

वजह: मैसेज प्रोसेसर पर एनवायरमेंट लोड नहीं किया गया है

संक्रमण की जांच

  1. हर मैसेज प्रोसेसर में लॉग इन करें. इसके बाद, यह देखें कि जिस खास एनवायरमेंट में एपीआई अनुरोध किया जा रहा है वह मैसेज प्रोसेसर पर लोड है या नहीं. इसके लिए, यह कमांड इस्तेमाल करें: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
  2. अगर ऊपर दिए गए कमांड में कोई खास एनवायरमेंट शामिल है, तो अगली वजह पर जाएं - एक या उससे ज़्यादा मैसेज प्रोसेसर पर एपीआई प्रॉक्सी डिप्लॉय नहीं की गई है.
  3. अगर आपको कोई खास एनवायरमेंट नहीं दिख रहा है, तो मैसेज प्रोसेसर पर /opt/apigee/var/log/edge-message-processor/logs/system.log और /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log देखें. इससे आपको पता चलेगा कि एनवायरमेंट लोड करते समय कोई गड़बड़ी तो नहीं हुई.
  4. मैसेज प्रोसेसर पर एनवायरमेंट लोड न होने की कई वजहें हो सकती हैं. समस्या हल करने का तरीका, हुई गड़बड़ी पर निर्भर करता है.

रिज़ॉल्यूशन

कई वजहों से, मैसेज प्रोसेसर पर एनवायरमेंट लोड नहीं हो सकता. इस सेक्शन में, इस समस्या की कुछ संभावित वजहों के बारे में बताया गया है. साथ ही, इस समस्या को हल करने का तरीका भी बताया गया है.

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

    गड़बड़ी #1: java.security.KeyStoreException: Cannot overwrite own certificate

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na]
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na]
…
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]

    ... 20 common frames omitted

    2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    गड़बड़ी #2: java.security.KeyStoreException: Cannot overwrite secret key

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na]
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na]
...
Caused by: java.security.KeyStoreException: Cannot overwrite secret key
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144]
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144]
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert
  2. पिछले चरण में दिखाए गए गड़बड़ी के मैसेज में बताए गए कीस्टोर/ट्रस्टस्टोर की जानकारी पाने के लिए, मैनेजमेंट एपीआई के इस कॉल का इस्तेमाल करें: 
    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

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

    {
   "certs":[
      "mycert",
      "mycert-new"
   ],
   "keys":[
      "mycert"
   ],
   "name":"myTruststore"
}
  3. उदाहरण के तौर पर दिए गए आउटपुट में दिखाया गया है कि ट्रस्टस्टोर में दो सर्टिफ़िकेट और एक कुंजी है myTruststore. आम तौर पर, ट्रस्टस्टोर में कोई कुंजी नहीं होती. अगर ऐसा होता है, तो एक ही सर्टिफ़िकेट और एक ही कुंजी का इस्तेमाल करना बेहतर होता है.
  4. नीचे दिए गए एपीआई का इस्तेमाल करके, दोनों सर्टिफ़िकेट के बारे में जानकारी पाएं: 
    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>
  5. हर सर्टिफ़िकेट की समयसीमा खत्म होने की तारीख देखें और पता लगाएं कि कौनसे सर्टिफ़िकेट की समयसीमा खत्म हो गई है या कौनसे सर्टिफ़िकेट पुराने हैं.
  6. ट्रस्टस्टोर myTruststore से, समयसीमा खत्म हो चुके या अनचाहे सर्टिफ़िकेट को मिटाएं.

अगर समस्या अब भी बनी रहती है या आपको ऊपर दिए गए पहले चरण में बताई गई गड़बड़ियों के अलावा कोई और गड़बड़ी दिखती है, तो डाइग्नोस्टिक की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

वजह: एपीआई प्रॉक्सी को एक या उससे ज़्यादा मैसेज प्रोसेसर पर डिप्लॉय नहीं किया गया है

ऐसा हो सकता है कि एपीआई प्रॉक्सी को एक या उससे ज़्यादा मैसेज प्रोसेसर पर डिप्लॉय न किया गया हो. यह समस्या बहुत कम होती है. ऐसा ज़्यादातर तब होता है, जब किसी खास एपीआई प्रॉक्सी को डिप्लॉय करते समय, मैनेजमेंट सर्वर से मैसेज प्रोसेसर को गतिविधि की सूचना नहीं मिलती है. इस मामले में भी, Edge UI में ट्रेस सेशन नहीं बनाया जा सकेगा.

संक्रमण की जांच

  1. हर मैसेज प्रोसेसर में लॉगिन करें और देखें कि एपीआई प्रॉक्सी का खास वर्शन डिप्लॉय किया गया है या नहीं. इसके लिए, यह कमांड इस्तेमाल करें: 
    curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  2. अगर एपीआई प्रॉक्सी का कोई खास वर्शन, ऊपर दिए गए पहले चरण में बताई गई कमांड के आउटपुट के तौर पर नहीं दिखता है, तो मैसेज प्रोसेसर को फिर से चालू करें. इसके लिए, समस्या हल करना सेक्शन में दिया गया तरीका अपनाएं.
  3. सभी मैसेज प्रोसेसर के लिए, पहले और दूसरे चरण को दोहराएं.
  4. अगर एपीआई प्रॉक्सी के किसी खास वर्शन को सभी मैसेज प्रोसेसर पर डिप्लॉय किया गया है, तो इस समस्या की वजह यह नहीं है. गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

रिज़ॉल्यूशन

उन मैसेज प्रोसेसर को फिर से शुरू करें जिन पर एपीआई प्रॉक्सी का खास वर्शन डिप्लॉय नहीं किया गया है.

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

एपीआई मॉनिटरिंग का इस्तेमाल करके समस्याओं का पता लगाना

एपीआई मॉनिटरिंग की मदद से, गड़बड़ी, परफ़ॉर्मेंस, और लोड होने में लगने वाले समय से जुड़ी समस्याओं और उनके सोर्स का पता लगाया जा सकता है. जैसे, डेवलपर ऐप्लिकेशन, एपीआई प्रॉक्सी, बैकएंड टारगेट या एपीआई प्लैटफ़ॉर्म.

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

यूज़र इंटरफ़ेस (यूआई) में गड़बड़ी का कोड और स्टेटस कोड

  • गड़बड़ी का कोड: messaging.adaptors.http.flow.ApplicationNotFound
  • स्टेटस कोड: 404
  • गड़बड़ी का सोर्स: Apigee या MP

इसके अलावा, ऊपर दिए गए स्क्रीनशॉट में दिखाए गए तरीके से, लॉग देखें पर क्लिक करके ज़्यादा जानकारी देखी जा सकती है.

लॉग देखना

उदाहरण के तौर पर दिए गए किसी एक मामले को हल करने का तरीका लेख में, एपीआई मॉनिटरिंग का इस्तेमाल करके, अपने एपीआई से जुड़ी 5xx समस्याओं को हल करने का तरीका बताया गया है. उदाहरण के लिए, आपको ऐसी सूचना सेट अप करनी पड़ सकती है जिससे आपको तब सूचना मिले, जब 404 स्टेटस कोड की संख्या किसी तय थ्रेशोल्ड से ज़्यादा हो जाए.

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

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

  1. अगर आप Public Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
    • संगठन का नाम
    • परिवेश का नाम
    • एपीआई प्रॉक्सी का नाम
    • गड़बड़ी को फिर से बनाने के लिए, कर्ल कमांड को पूरा करें
  2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
    • गड़बड़ी का पूरा मैसेज मिला
    • परिवेश का नाम
    • एपीआई प्रॉक्सी बंडल
    • मैसेज प्रोसेसर के लॉग /opt/apigee/var/log/edge-message-processor/logs/system.log
    • हर मैसेज प्रोसेसर पर, यहां दिए गए निर्देशों का आउटपुट. 
      • curl -v 0:8082/v1/runtime/organizations/<orgname>/environments
       
      curl -v 0:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions
  3. इस प्लेबुक के किन सेक्शन में दिए गए तरीके आपने आज़माए हैं और इस समस्या को तेज़ी से हल करने में मदद करने वाली कोई अन्य अहम जानकारी.