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

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

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

क्लाइंट ऐप्लिकेशन को एपीआई कॉल के जवाब के तौर पर, Not Found मैसेज के साथ 404 का एचटीटीपी स्टेटस कोड और गड़बड़ी का मैसेज 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 के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता
एपीआई प्रॉक्सी के डिप्लॉय किए गए नए वर्शन में, वर्चुअल होस्ट को हटाया गया जब क्लाइंट किसी खास वर्चुअल होस्ट का इस्तेमाल कर रहा हो, तब नए डिप्लॉय किए गए वर्शन से वर्चुअल होस्ट को हटाने से यह समस्या हो सकती है. Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता
पाथ किसी भी एपीआई प्रॉक्सी से जुड़ा नहीं है खास एपीआई प्रॉक्सी को गड़बड़ी के मैसेज में बताए गए पाथ पर अनुरोध स्वीकार करने के लिए कॉन्फ़िगर नहीं किया गया है. Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता
एपीआई प्रॉक्सी को किसी एनवायरमेंट में डिप्लॉय नहीं किया गया है खास एपीआई प्रॉक्सी को उस खास एनवायरमेंट में डिप्लॉय नहीं किया जाता है जिसमें आपको एपीआई अनुरोध भेजने हैं. Edge के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता
मैसेज प्रोसेसर पर एनवायरमेंट लोड नहीं हुआ किसी गड़बड़ी की वजह से, मैसेज प्रोसेसर पर उस एनवायरमेंट (जिसमें एपीआई अनुरोध को भेजने की कोशिश की जा रही है) लोड नहीं किया जा सका. Edge Private Cloud के उपयोगकर्ता
एक या उससे ज़्यादा मैसेज प्रोसेसर पर एपीआई प्रॉक्सी डिप्लॉय नहीं की गई है डिप्लॉयमेंट के दौरान इवेंट की सूचना मौजूद न होने की वजह से, हो सकता है कि एपीआई प्रॉक्सी को एक या उससे ज़्यादा मैसेज प्रोसेसर पर डिप्लॉय न किया जाए. Edge Private Cloud के उपयोगकर्ता

निदान के सामान्य चरण

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

  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

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

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

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

  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 है:
      • रिविज़न 5 में प्रॉक्सी एंडपॉइंट में कॉन्फ़िगर किए गए वर्चुअल होस्ट
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>vh1</VirtualHost>
</HTTPProxyConnection>
      • रिविज़न 6 में प्रॉक्सी एंडपॉइंट में कॉन्फ़िगर किए गए वर्चुअल होस्ट
        • <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
    <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
    2. ऊपर दिए गए उदाहरण में, revision 5, में VirtualHost vh1 मौजूद था, लेकिन उसे 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: सोच-समझकर बदलाव करना

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

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

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

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

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

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

स्थिति #2: अनजाने में हुआ बदलाव

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

  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 और स्थिति #2 में दिया गया तरीका अपनाएं.

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

  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

स्थिति #2: पाथ किसी भी उपलब्ध कंडीशनल फ़्लो से मेल नहीं खाता

  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 (बेसपाथ के बाद का पाथ) को /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 यूज़र इंटरफ़ेस (यूआई) में अपने संगठन के हर एनवायरमेंट में मौजूद सभी वर्चुअल होस्ट की जानकारी देखें.

    उदाहरण के लिए, मान लें कि नीचे दिया गया कॉन्फ़िगरेशन:

    • अगर 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. ऐसी कई अलग-अलग गड़बड़ियां हो सकती हैं जिनकी वजह से, Message प्रोसेसर पर एनवायरमेंट को लोड नहीं किया जा सका. रिज़ॉल्यूशन हुई गड़बड़ी के हिसाब से तय होती है.

रिज़ॉल्यूशन

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

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

    गड़बड़ी #1: java.security.KeyStore4: खुद के सर्टिफ़िकेट को ओवरराइट नहीं कर सकता

    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.KeyStore अपवाद: सीक्रेट कुंजी को ओवरराइट नहीं किया जा सकता

    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 यूआई में ट्रेस सेशन नहीं बनाया जा सकता.

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

  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. इस प्लेबुक के उन सेक्शन के बारे में जानकारी जिन्हें आपने आज़माया है और ऐसी अन्य अहम जानकारी जिससे हमें इस समस्या को तेज़ी से हल करने में मदद मिलेगी.