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

गड़बड़ी की जांच करने के सामान्य तरीके

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. यूआरएल का इस्तेमाल करके, default VirtualHost को एपीआई अनुरोध भेजा जाता है http://myorg-prod.apigee.net/weather
  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. मौजूदा VirtualHost को ProxyEndpoint कॉन्फ़िगरेशन में जोड़ें, ताकि समस्या को हल करें. ऊपर दिखाए गए उदाहरण के लिए, आपके पास डिफ़ॉल्ट VirtualHost जोड़ने का विकल्प है ProxyEndpoint कॉन्फ़िगरेशन में इस तरह से शामिल होगा: 
    <VirtualHost>default</VirtualHost>

    डिफ़ॉल्ट प्रॉक्सी एंडपॉइंट कॉन्फ़िगरेशन का सैंपल> VirtualHost&gt; जोड़ा जा रहा है

  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. बदलावों को फिर से डिप्लॉय करें.

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

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

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

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

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

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

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

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

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

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

    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. आउटपुट के उदाहरण से पता चलता है कि Truststore में दो सर्टिफ़िकेट और एक कुंजी मौजूद है myTruststore. आम तौर पर, Truststore में कोई कुंजी नहीं होती है. अगर हां, तो एक ही प्रमाणपत्र और एक कुंजी का होना बेहतर है.
  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 उपयोगकर्ता हैं, तो यह जानकारी दें:
    • संगठन का नाम
    • परिवेश का नाम
    • एपीआई प्रॉक्सी का नाम
    • गड़बड़ी को ठीक करने के लिए curl कमांड पूरा करें
  2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो यह जानकारी दें:
    • गड़बड़ी का पूरा मैसेज दिखा
    • परिवेश का नाम
    • एपीआई प्रॉक्सी बंडल
    • मैसेज प्रोसेसर के लॉग /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. इस प्लेबुक में आज़माए गए सेक्शन के बारे में जानकारी और ऐसी अन्य अहम जानकारी इस समस्या के समाधान के लिए हम तेज़ी से काम करेंगे.