503 सेवा उपलब्ध नहीं है

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

पर क्लिक करें.

वीडियो

503 गड़बड़ियों के बारे में ज़्यादा जानने के लिए, ये वीडियो देखें:

वीडियो ब्यौरा
डीएनएस की समस्या की वजह से, "गड़बड़ी 503: सेवा उपलब्ध नहीं है" गड़बड़ी को ठीक करना और उसका समाधान करना इनके बारे में जानें:
  • Apigee Edge में डीएनएस रिज़ॉल्यूशन और नेटवर्क से जुड़ी समस्याओं की वजह से, 503 Service Unavailable गड़बड़ी हुई
  • डीएनएस रिज़ॉल्यूशन की समस्या की वजह से, रीयल-टाइम में दिखने वाली 503 सेवा उपलब्ध नहीं है गड़बड़ी को ठीक करना
नेटवर्क की समस्या की वजह से, "गड़बड़ी 503: सेवा उपलब्ध नहीं है" मैसेज दिखने की समस्या हल करना Apigee Edge में नेटवर्क की समस्या की वजह से, रीयल-टाइम में दिखने वाली 503 Service Unavailable गड़बड़ी को ठीक करना और उसे हल करना

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

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

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

आपको गड़बड़ी का यह मैसेज दिख सकता है:

HTTP/1.1 503 Service Unavailable

आपको एचटीटीपी रिस्पॉन्स में गड़बड़ी का यह मैसेज भी दिख सकता है:

सेवा उपलब्ध नहीं है

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

संभावित कारण

अगर Apigee Edge के मैसेज प्रोसेसर को बैकएंड सर्वर से कम्यूनिकेट करते समय, कनेक्शन टाइम आउट, गलत होस्ट नेम या एसएसएल हैंडशेक की गड़बड़ियों की वजह से गड़बड़ियां होती हैं, तो एचटीटीपी रिस्पॉन्स 503 सेवा उपलब्ध नहीं है, गड़बड़ी कोड messaging.adaptors.http.flow.ServiceUnavailable के साथ दिखता है.

503 कोड वाली गड़बड़ी: सेवा उपलब्ध नहीं है की ये वजहें हो सकती हैं:

वजह ब्यौरा समस्या हल करने के तरीके कौन आज़मा सकता है
डीएनएस रिज़ॉल्यूशन के गलत होने की वजह से कनेक्शन से जुड़ी गड़बड़ियां टारगेट सर्वर के डीएनएस रिज़ॉल्यूशन से ऐसे आईपी पते मिले हैं जिनकी वजह से कनेक्शन की गड़बड़ियां हुई हैं. Edge Private Cloud के उपयोगकर्ता
कनेक्शन से जुड़ी गड़बड़ियां नेटवर्क या कनेक्टिविटी से जुड़ी समस्याओं की वजह से, क्लाइंट सर्वर से कनेक्ट नहीं हो पाता. Edge Private Cloud के उपयोगकर्ता
टारगेट सर्वर का होस्टनेम गलत है टारगेट सर्वर का होस्टनेम गलत है या उसमें स्पेस जैसे अवांछित वर्ण मौजूद हैं. Edge Public और Private Cloud के उपयोगकर्ताओं के लिए
एसएसएल हैंडशेक नहीं हो सका क्लाइंट और सर्वर के बीच टीएलएस/एसएसएल हैंडशेक नहीं हो सका. (इस तरह की समस्या को हल करने के बारे में, किसी दूसरे विषय में बताया गया है.) Edge Public और Private Cloud के उपयोगकर्ताओं के लिए

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

अनुरोध पूरा न होने पर, मैसेज आईडी का पता लगाना

ट्रेस टूल

ट्रेस टूल का इस्तेमाल करके, अनुरोध पूरा न होने पर मैसेज आईडी का पता लगाने के लिए:

  1. अगर समस्या अब भी बनी हुई है, तो समस्या वाले एपीआई के लिए ट्रेस सेशन चालू करें.
  2. एपीआई कॉल करें और समस्या को फिर से दोहराएं - गड़बड़ी कोड messaging.adaptors.http.flow.ServiceUnavailable. के साथ 503 सेवा उपलब्ध नहीं है
  3. उन अनुरोधों में से किसी एक को चुनें जो पूरे नहीं हुए.
  4. AX फ़ेज़ पर जाएं. इसके बाद, फ़ेज़ की जानकारी सेक्शन में नीचे की ओर स्क्रोल करके, अनुरोध का मैसेज आईडी (X-Apigee.Message-ID) पता करें. यह आईडी, यहां दी गई इमेज में दिखाया गया है.

    'फ़ेज़ की जानकारी' सेक्शन में मौजूद मैसेज आईडी

NGINX ऐक्सेस लॉग

NGINX ऐक्सेस लॉग का इस्तेमाल करके, अनुरोध पूरा न होने का मैसेज आईडी पता करने के लिए:

503 गड़बड़ियों के लिए मैसेज आईडी का पता लगाने के लिए, NGINX के ऐक्सेस लॉग भी देखे जा सकते हैं. यह खास तौर पर तब काम आता है, जब समस्या पहले भी हो चुकी हो या समस्या कभी-कभी होती हो और यूज़र इंटरफ़ेस (यूआई) में ट्रेस कैप्चर न किया जा सके. NGINX के ऐक्सेस लॉग से यह जानकारी पाने के लिए, यह तरीका अपनाएं:

  1. NGINX के ऐक्सेस लॉग देखें: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
  2. देखें कि क्या किसी खास समयावधि के दौरान, किसी खास एपीआई प्रॉक्सी के लिए कोई 503 गड़बड़ी हुई है (अगर समस्या पहले हुई थी) या क्या अब भी कोई अनुरोध 503 गड़बड़ी की वजह से पूरा नहीं हो पा रहा है.
  3. अगर X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable से जुड़ी कोई 503 गड़बड़ी है, तो ऐसे एक या उससे ज़्यादा अनुरोधों के लिए मैसेज आईडी नोट करें. यहां दिए गए उदाहरण में दिखाया गया है:

    503 गड़बड़ी दिखाने वाली एंट्री का उदाहरण

    स्टेटस कोड, मैसेज आईडी, गड़बड़ी का सोर्स, और गड़बड़ी का कोड दिखाने वाली सैंपल एंट्री

डीएनएस रिज़ॉल्यूशन के गलत होने की वजह से कनेक्शन से जुड़ी गड़बड़ियां

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

  1. अनुरोध पूरा न होने पर, मैसेज आईडी का पता लगाएं.
  2. मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) में, अनुरोध के मैसेज आईडी को खोजें. आपको ये गड़बड़ियां दिख सकती हैं:

    onConnectTimeout गड़बड़ी से पता चलता है कि मैसेज प्रोसेसर, कनेक्शन के लिए तय किए गए टाइम आउट पीरियड (डिफ़ॉल्ट: तीन सेकंड) के अंदर बैकएंड सर्वर से कनेक्ट नहीं हो सका. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22

2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
  3. onConnectTimeout गड़बड़ी में हल किए गए आईपी पते को नोट करें. साथ ही, देखें कि आईपी पता आपके बैकएंड सर्वर के लिए मान्य है या नहीं. अगर आईपी पता मान्य है, तो कनेक्शन से जुड़ी गड़बड़ियों पर जाएं.
  4. अगर आईपी पता अमान्य है, तो ऐसा डीएनएस रिज़ॉल्यूशन से जुड़ी समस्याओं की वजह से हो सकता है.
  5. एपीआई के कुछ और अनुरोधों के लिए, तीसरे और चौथे चरण को दोहराएं. साथ ही, पुष्टि करें कि आपको वही या कोई अन्य अमान्य आईपी पते दिख रहे हैं.
  6. डीएनएस रीफ़्रेश कीवर्ड वाले मैसेज के लिए, मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) में खोजें. देखें कि मैसेज प्रोसेसर पर डीएनएस कैश में, कभी-कभी खराब या अमान्य आईपी पते तो नहीं जोड़े जा रहे हैं. 
    2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
  7. यह समस्या तब हो सकती है, जब आधिकारिक डीएनएस सर्वर या /etc/resolv.conf में कॉन्फ़िगर किए गए नेम सर्वर में कोई समस्या हो.

    आम तौर पर, डीएनएस रिज़ॉल्यूशन करने के लिए, एक या उससे ज़्यादा आधिकारिक डीएनएस सर्वर कॉन्फ़िगर किए जा सकते हैं. अगर कोई आधिकारिक डीएनएस सर्वर नहीं है, तो यह /etc/resolv.conf में सेट अप किए गए कॉन्फ़िगरेशन पर वापस चला जाएगा और डीएनएस रिज़ॉल्यूशन को सही तरीके से पूरा करेगा. उदाहरण के लिए: अगर /etc/resolv.conf को कुछ खास नेम सर्वर का इस्तेमाल करने के लिए कॉन्फ़िगर किया गया है, तो डीएनएस रिज़ॉल्यूशन के लिए उन नेम सर्वर का इस्तेमाल किया जाएगा.
  8. अगर /etc/resolv.conf में बताए गए आधिकारिक डीएनएस सर्वर या नेम सर्वर में कोई समस्या है, तो बैकएंड सर्वर के होस्टनेम, गलत/अमान्य आईपी पतों में बदल जाएंगे. इसके बाद, खराब/अमान्य आईपी पतों को मैसेज प्रोसेसर की डीएनएस कैश मेमोरी में सेव किया जाएगा.
    1. अगर /etc/resolv.conf में बताए गए आधिकारिक डीएनएस सर्वर या नेम सर्वर से जुड़ी समस्या बनी रहती है, तो खराब/अमान्य आईपी पते, मैसेज प्रोसेसर के डीएनएस कैश मेमोरी में बने रहेंगे. जब तक खराब आईपी पते, मैसेज प्रोसेसर की डीएनएस कैश मेमोरी में सेव रहेंगे, तब तक खास बैकएंड सर्वर का इस्तेमाल करने वाले सभी एपीआई के अनुरोध पूरे नहीं किए जा सकेंगे. साथ ही, गड़बड़ी 503 का मैसेज दिखेगा.
    2. अगर /etc/resolv.conf में बताए गए आधिकारिक डीएनएस सर्वर या नेम सर्वर से जुड़ी समस्या कभी-कभी होती है, तो डीएनएस कैश मेमोरी में अच्छे और खराब आईपी पते कभी-कभी सेव होंगे. इस स्थिति में, आपको उस खास बैकएंड सर्वर का इस्तेमाल करने वाले सभी एपीआई के लिए, समय-समय पर 503 गड़बड़ियां दिखेंगी.
  9. अगर डीएनएस सर्वर से जुड़ी समस्या बनी रहती है, तो आपको लगातार गड़बड़ियां दिखेंगी. अगर डीएनएस सर्वर में समस्या कभी-कभी होती है, तो आपको कभी-कभी गड़बड़ियां दिखेंगी. इसका मतलब है कि जब भी बैकएंड सर्वर का होस्टनेम, गलत आईपी पतों पर रीडायरेक्ट होता है, तब आपको 503 गड़बड़ियां दिखती हैं. साथ ही, जब बैकएंड सर्वर के होस्ट नामों को सही आईपी पतों में बदल दिया जाता है, तब आपको सही जवाब मिलेंगे.

रिज़ॉल्यूशन

कृपया अपने ऑपरेटिंग सिस्टम एडमिन से संपर्क करें और डीएनएस सर्वर से जुड़ी समस्याओं को ठीक करें.

  1. अगर /etc/resolv.conf में बताए गए आधिकारिक डीएनएस सर्वर या नेम सर्वर में कोई समस्या है, तो इस समस्या को ठीक करने के लिए सही सर्वर का इस्तेमाल करें.
  2. अगर मैसेज प्रोसेसर वाले सिस्टम पर /etc/resolv.conf के कॉन्फ़िगरेशन में कोई समस्या है, तो उसे ठीक करें.

कनेक्शन की गड़बड़ियां

कनेक्शन से जुड़ी गड़बड़ी तब होती है, जब Apigee Edge Message Processor, बैकएंड सर्वर से कनेक्ट करने की कोशिश करता है और इनमें से कोई समस्या होती है:

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

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

  1. अनुरोध पूरा न होने पर, मैसेज आईडी का पता लगाएं.
  2. मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) में, अनुरोध के मैसेज का आईडी खोजें. आपको ये गड़बड़ियां दिख सकती हैं:
    1. onConnectTimeout गड़बड़ी से पता चलता है कि मैसेज प्रोसेसर, कनेक्शन के लिए तय की गई समयसीमा के अंदर बैकएंड सर्वर से कनेक्ट नहीं हो सका. 
      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
    2. java.net.ConnectException: Connection refused गड़बड़ी का मतलब है कि बैकएंड सर्वर ने कनेक्शन अस्वीकार कर दिया है. 
      14:40:16.531 +0530
2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
  3. जांच करें कि क्या telnet कमांड का इस्तेमाल करके, हर मैसेज प्रोसेसर से सीधे किसी बैकएंड सर्वर से कनेक्ट किया जा सकता है:
    1. अगर बैकएंड सर्वर एक ही आईपी पते पर काम करता है, तो इस कमांड का इस्तेमाल करें: 
      telnet BackendServer-IPaddress 443
    2. अगर बैकएंड सर्वर कई आईपी पतों पर रीडायरेक्ट होता है, तो telnet कमांड में बैकएंड सर्वर के होस्टनेम का इस्तेमाल करें. जैसा कि यहां दिखाया गया है: 
      telnet BackendServer-HostName 443
  4. अगर बैकएंड सर्वर से कनेक्ट किया जा सकता है, तो आपको Connected to backend-server जैसा मैसेज दिख सकता है. अगर बैकएंड सर्वर से कनेक्ट नहीं किया जा सकता, तो इसकी वजह यह हो सकती है कि मैसेज प्रोसेसर के आईपी पतों को किसी खास बैकएंड सर्वर पर अनुमति वाली सूची में शामिल नहीं किया गया है.

रिज़ॉल्यूशन

किसी खास बैकएंड सर्वर पर Message Processor के आईपी पतों को ऐक्सेस करने की अनुमति दें, ताकि Edge Message Processors से आने वाला ट्रैफ़िक आपके बैकएंड सर्वर को ऐक्सेस कर सके. उदाहरण के लिए, Linux पर बैकएंड सर्वर पर मैसेज प्रोसेसर के आईपी पतों से आने वाले ट्रैफ़िक को अनुमति देने के लिए, iptables का इस्तेमाल किया जा सकता है.

अगर समस्या बनी रहती है, तो अपने नेटवर्क एडमिन के साथ मिलकर समस्या का पता लगाएं और उसे ठीक करें. अगर आपको Apigee से कोई और मदद चाहिए, तो Apigee की सहायता टीम से संपर्क करें.

टारगेट सर्वर का होस्टनेम गलत है

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

अगर टारगेट सर्वर में दिया गया होस्ट नेम गलत है, तो आपको गड़बड़ी कोड messaging.adaptors.http.flow.ServiceUnavailable. के साथ 503 सेवा उपलब्ध नहीं है रिस्पॉन्स मिल सकता है

ट्रेस टूल

ट्रेस टूल का इस्तेमाल करके समस्या का पता लगाने के लिए:

  1. अगर समस्या अब भी बनी हुई है, तो समस्या वाले एपीआई के लिए ट्रेस सेशन चालू करें.
  2. एपीआई कॉल करें और समस्या को फिर से दोहराएं - गड़बड़ी कोड messaging.adaptors.http.flow.ServiceUnavailable. के साथ 503 सेवा उपलब्ध नहीं है
  3. उन अनुरोधों में से किसी एक को चुनें जो पूरे नहीं हुए.
  4. ट्रेस के अलग-अलग फ़ेज़ में नेविगेट करें और पता लगाएं कि गड़बड़ी कहां हुई.
  5. उस FlowInfo को चुनें जिसमें गड़बड़ी है. आपको error.cause फ़ील्ड में ज़्यादा जानकारी मिल सकती है. इससे आपको गड़बड़ी की वजह का पता चल सकता है. उदाहरण के लिए, यहां देखें:

    ट्रेस में error.cause दिखाने वाला अनुरोध का सैंपल

    ट्रेस में error.cause दिखाने वाला सैंपल अनुरोध
  6. अगर आपको दिखता है कि error.cause में Host not reachable, दिख रहा है, तो गड़बड़ी की वजह इनमें से कोई एक हो सकती है:
    • टारगेट सर्वर/टारगेट एंडपॉइंट कॉन्फ़िगरेशन में दिया गया होस्टनेम गलत है या उसमें गैर-ज़रूरी स्पेस या खास वर्ण हैं.

      उदाहरण के लिए, होस्ट के नाम में अनचाहा स्पेस है. इसे यहां दिखाया गया है:
      "demo-target.apigee.net "
    • एपीआई प्रॉक्सी में AssignMessage या JavaScript नीति का इस्तेमाल करके, target.url वैरिएबल से बदले गए होस्टनेम में गड़बड़ी है. इसमें स्पेस या कोई अन्य अवांछित खास वर्ण मौजूद है.
  7. टारगेट एंडपॉइंट कॉन्फ़िगरेशन और/या टारगेट सर्वर की परिभाषा देखें. इससे पता चलेगा कि टारगेट सर्वर का होस्ट नेम गलत है या उसमें कोई अनचाहा स्पेस या खास वर्ण मौजूद है.
  8. अगर टारगेट सर्वर होस्ट को डाइनैमिक तरीके से बनाया गया है, तो उसे बनाने के लिए इस्तेमाल की गई सही नीति (उदाहरण के लिए, AssignMessage/JavaScript नीति) की जांच करें. जांच करें कि टारगेट सर्वर का होस्ट नेम गलत तो नहीं है. साथ ही, यह भी देखें कि उसमें कोई अनचाही खाली जगह या खास वर्ण तो नहीं है.
  9. टारगेट सर्वर के होस्ट नाम का पता लगाने के बाद, होस्ट नाम पर nslookup/dig कमांड चलाएं. इससे यह पता चलेगा कि होस्ट नाम को हल किया जा सकता है या नहीं.

    उदाहरण के लिए, होस्ट नेम में अनचाहे स्पेस के साथ nslookup कमांड चलाने पर, यह आउटपुट मिलता है:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. अगर ऑपरेटिंग सिस्टम कमांड nslookup भी होस्टनेम को हल नहीं कर पाती है, तो इस समस्या की वजह टारगेट सर्वर के लिए इस्तेमाल किया गया गलत होस्टनेम है.

    रिज़ॉल्यूशन पर जाएं.

मैसेज प्रोसेसर के लॉग

मैसेज प्रोसेसर के लॉग का इस्तेमाल करके समस्या का पता लगाने के लिए:

  1. अनुरोध पूरा न होने पर, मैसेज आईडी का पता लगाएं.
  2. मैसेज प्रोसेसर के लॉग में मैसेज आईडी खोजें. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. अगर आपको यहां दी गई चेतावनी या गड़बड़ी के मैसेज दिखते हैं, तो इसका मतलब है कि मैसेज प्रोसेसर, होस्ट नेम का पता नहीं लगा सका. मैसेज को कुछ समय के लिए छिपा दिया जाएगा. इसलिए, हो सकता है कि आपको सभी मैसेज आईडी/अनुरोधों के लिए, चेतावनी वाला यह मैसेज न दिखे. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. इसके बाद, आपको एक चेतावनी वाला मैसेज दिखेगा. इसमें मैसेज प्रोसेसर, पते को डीएनएस कैश मेमोरी से हटा देता है, क्योंकि टारगेट सर्वर होस्ट तक नहीं पहुंचा जा सका. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. इसके बाद, आपको एक मैसेज दिख सकता है. इसमें मैसेज प्रोसेसर, “होस्ट से संपर्क नहीं किया जा सका” अपवाद के साथ फ़ेल हो जाता है. कभी-कभी, गड़बड़ी के मैसेज में होस्ट का नाम दिखता है: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. कभी-कभी, होस्टनेम को हल नहीं किया जा सकता या उस तक नहीं पहुंचा जा सकता. इसलिए, यह null के तौर पर दिख सकता है. जैसा कि यहां दिखाया गया है: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. Host not reachable गड़बड़ी आम तौर पर इन मामलों में होती है:
    • टारगेट सर्वर/टारगेट एंडपॉइंट कॉन्फ़िगरेशन में दिया गया होस्टनेम गलत है या उसमें गैर-ज़रूरी स्पेस या खास वर्ण हैं.

      उदाहरण के लिए, यहां दिए गए गड़बड़ी के मैसेज में होस्ट नेम "demo-target.apigee.net " में अनचाहा स्पेस मौजूद है: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • एपीआई प्रॉक्सी में AssignMessage या JavaScript नीति का इस्तेमाल करके, target.url वैरिएबल से बदले गए होस्टनेम में कोई गड़बड़ी है. इसके अलावा, हो सकता है कि उसमें स्पेस या कोई अन्य अवांछित खास वर्ण मौजूद हो.
  8. इनमें से किसी एक तरीके का इस्तेमाल करके, उस टारगेट सर्वर के होस्टनेम का पता लगाएं जिससे Message Processor कम्यूनिकेट करने की कोशिश कर रहा है:
    1. Host not reachable वाले गड़बड़ी के मैसेज को ध्यान से देखें.
    2. अगर गड़बड़ी के मैसेज में होस्ट का नाम दिखता है, तो स्पेस या खास वर्णों के साथ होस्ट का नाम कॉपी करें.
    3. अगर गड़बड़ी के मैसेज में होस्ट नेम के लिए null दिखता है, जैसा कि यहां दिखाया गया है, 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. एपीआई प्रॉक्सी में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखकर, होस्टनेम का पता लगाएं.
      2. अगर टारगेट सर्वर होस्ट को डाइनैमिक तरीके से बनाया गया है, तो उसे बनाने के लिए इस्तेमाल की गई सही नीति (उदाहरण के लिए, AssignMessage/JavaScript नीति) की जांच करें.
  9. टारगेट सर्वर के होस्ट नेम का पता लगाने के बाद, होस्ट नेम पर nslookup/dig कमांड चलाएं और देखें कि क्या इसे हल किया जा सकता है.

    उदाहरण के लिए, स्पेस वाले होस्ट नेम पर nslookup कमांड चलाएं

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. अगर ऑपरेटिंग सिस्टम कमांड nslookup भी होस्टनेम को ठीक नहीं कर पाती है, तो इस समस्या की वजह टारगेट सर्वर के लिए इस्तेमाल किया गया गलत होस्टनेम है.

रिज़ॉल्यूशन

  1. पक्का करें कि टारगेट एंडपॉइंट कॉन्फ़िगरेशन या टारगेट सर्वर की परिभाषा में दिया गया टारगेट सर्वर होस्ट नेम सही हो. साथ ही, उसमें कोई अनचाहा स्पेस या खास वर्ण न हो.
  2. अगर टारगेट सर्वर के होस्ट नेम को डाइनैमिक तरीके से जनरेट करने के लिए, किसी AssignMessage/JavaScript नीति का इस्तेमाल किया जाता है, तो नीति की परिभाषा और कोड की जांच करें. साथ ही, पक्का करें कि टारगेट सर्वर का होस्टनेम सही तरीके से जनरेट किया गया हो.

एसएसएल हैंडशेक की प्रोसेस पूरी न हो पाने की वजह से होने वाली गड़बड़ियां

पूरी समस्या हल करने की गाइड, टीएलएस/एसएसएल हैंडशेक से जुड़ी गड़बड़ियों के लिए बनाई गई है. एसएसएल हैंडशेक से जुड़ी गड़बड़ियां देखें.

समस्या की वजह का पता लगाना

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

उत्तर की ओर जाने वाले और दक्षिण की ओर जाने वाले कनेक्शन के बारे में जानकारी

Edge में, आपको आने वाले या जाने वाले कनेक्शन पर, 503 सेवा उपलब्ध नहीं है गड़बड़ी का सामना करना पड़ सकता है:

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

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

इस इमेज में, Apigee Edge के लिए नॉर्थबाउंड और साउथबाउंड कनेक्शन दिखाए गए हैं.

क्लाइंट ऐप्लिकेशन (नॉर्थबाउंड कनेक्शन) से एज के ज़रिए बैकएंड सर्वर (साउथबाउंड कनेक्शन) तक डेटा फ़्लो

यह पता लगाना कि 503 कोड वाली गड़बड़ी कहां हुई

यह पता लगाने के लिए कि 503 सेवा उपलब्ध नहीं है वाली गड़बड़ी, नॉर्थबाउंड या साउथबाउंड कनेक्शन पर हुई है, इनमें से कोई एक तरीका अपनाएं.

यूज़र इंटरफ़ेस (यूआई) ट्रेस

यूज़र इंटरफ़ेस (यूआई) ट्रेस का इस्तेमाल करके, यह पता लगाने के लिए कि गड़बड़ी कहां हुई है:

  1. अगर समस्या अब भी बनी हुई है, तो जिस एपीआई पर असर पड़ा है उसके लिए यूज़र इंटरफ़ेस (यूआई) ट्रेसिंग चालू करें.
  2. अगर एपीआई अनुरोध के लिए यूज़र इंटरफ़ेस (यूआई) ट्रेस में यह दिखता है कि टारगेट अनुरोध के फ़्लो के दौरान या बैकएंड सर्वर से 503 Service Unavailable गड़बड़ी हुई है, तो इसका मतलब है कि समस्या southbound में है. इसका मतलब है कि समस्या मैसेज प्रोसेसर और बैकएंड सर्वर के बीच है.
  3. अगर आपको किसी खास एपीआई कॉल के लिए ट्रेस नहीं मिलता है, तो इसका मतलब है कि समस्या नॉर्थबाउंड है. यह समस्या, क्लाइंट ऐप्लिकेशन और राउटर के बीच है.

एपीआई मॉनिटरिंग

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

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

NGINX ऐक्सेस लॉग

यूज़र इंटरफ़ेस (यूआई) ट्रेस का इस्तेमाल करके, यह पता लगाने के लिए कि गड़बड़ी कहां हुई है:

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

  1. NGINX के ऐक्सेस लॉग (/opt/apigee/var/log/edge-router/nginx/ org-env.port_access_log ) देखें.
  2. देखें कि किसी एपीआई प्रॉक्सी के लिए, 503 गड़बड़ियां तो नहीं हैं.
  3. अगर आपको किसी खास समय पर किसी एपीआई के लिए 503 गड़बड़ियां दिखती हैं, तो इसका मतलब है कि साउथबाउंड कनेक्शन (मैसेज प्रोसेसर और बैकएंड सर्वर के बीच) में समस्या आई है.
  4. अगर ऐसा नहीं होता है, तो समस्या नॉर्थबाउंड कनेक्शन (क्लाइंट ऐप्लिकेशन और राउटर के बीच) में हुई है.