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

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

वीडियो

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

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

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

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

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

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

HTTP/1.1 503 Service Unavailable

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

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

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

संभावित कारण

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

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

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

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

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

ट्रेस टूल

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

  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 message.adaptors.http.flow.ServiceUnavailable में कोई 503 गड़बड़ियां पाई गई हैं, तो नीचे दिए गए उदाहरण के मुताबिक, ऐसे एक या एक से ज़्यादा अनुरोधों के लिए मैसेज आईडी का ध्यान रखें:

    503 गड़बड़ी दिखाने वाली सैंपल एंट्री

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

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

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

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

    onConnectTimeout गड़बड़ी से पता चलता है कि मैसेज प्रोसेसर, पहले से सेट किए गए कनेक्शन के टाइम आउट (डिफ़ॉल्ट: 3 सेकंड) में बैकएंड सर्वर से कनेक्ट नहीं हो सका. 
    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) में, मुख्य शब्द डीएनएस रीफ़्रेश वाले मैसेज खोजें. देखें कि Message प्रोसेसर की मदद से डीएनएस कैश मेमोरी में, गलत या अमान्य आईपी पते कभी-कभी जोड़े जा रहे हैं या नहीं. 
    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 में दिए गए आधिकारिक डीएनएस सर्वर या नेम सर्वर में समस्या हमेशा बनी रहती है, तो खराब/अमान्य आईपी पते, मैसेज प्रोसेसर की डीएनएस कैश मेमोरी में मौजूद रहेंगे. जब तक खराब आईपी पते, Message प्रोसेसर के डीएनएस कैश मेमोरी में सेव रहते हैं, तब तक खास बैकएंड सर्वर का इस्तेमाल करने वाले सभी एपीआई के अनुरोध, 503 गड़बड़ी के साथ रद्द हो जाएंगे.
    2. अगर /etc/resolv.conf में बताए गए भरोसेमंद डीएनएस सर्वर या नेम सर्वर में आने वाली समस्या बार-बार होती है, तो अच्छे और खराब आईपी पते, बीच-बीच में डीएनएस कैश मेमोरी में सेव किए जाएंगे. इस मामले में, आपको चुनिंदा बैकएंड सर्वर का इस्तेमाल करने वाले सभी एपीआई के लिए, कभी-कभी 503 गड़बड़ियां दिखेंगी.
  9. अगर डीएनएस सर्वर से जुड़ी समस्या लगातार बनी रहती है, तो आपको लगातार गड़बड़ी के मैसेज दिखेंगे. अगर डीएनएस सर्वर में समस्या कभी-कभी होती है, तो आपको थोड़ी-थोड़ी देर के लिए गड़बड़ियां दिखेंगी. इसका मतलब है कि जब भी बैकएंड सर्वर होस्ट के नाम से खराब आईपी पते ठीक हो जाते हैं, तो आपको 503 गड़बड़ियां दिखती हैं. जब बैकएंड सर्वर के होस्ट के नामों का इस्तेमाल अच्छे आईपी पतों के लिए किया जाएगा, तब आपको सही रिस्पॉन्स मिलेंगे.

रिज़ॉल्यूशन

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

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

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

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

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

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

  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.Connectexcept: कनेक्शन को अस्वीकार कर दिया गया गड़बड़ी का मतलब है कि बैकएंड सर्वर ने कनेक्शन को अस्वीकार कर दिया. 
      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 प्रोसेसर के आईपी पतों को किसी खास बैकएंड सर्वर पर अनुमति वाली सूची में शामिल न किया गया हो.

रिज़ॉल्यूशन

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

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

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

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

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

ट्रेस टूल

ट्रेस टूल की मदद से विश्लेषण करने के लिए:

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

    ट्रेस में गड़बड़ी दिखाने वाले अनुरोध का उदाहरण

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

      उदाहरण के लिए, नीचे दिखाए गए तरीके के हिसाब से, होस्ट के नाम में अनचाही स्पेस है:
      "demo-target.apigee.net "
    • AssignmentMessage या 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. Message प्रोसेसर लॉग में मैसेज आईडी खोजें. (/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. कभी-कभी होस्ट के नाम की समस्या हल न होने या उसका ऐक्सेस न मिलने की वजह से, यह शून्य के तौर पर दिख सकता है: 
    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
    • AssignmentMessage या JavaScript नीति का इस्तेमाल करके एपीआई प्रॉक्सी में, target.url वैरिएबल से ओवरराइट किया गया होस्ट नाम गलत है या उसमें खाली जगह या दूसरे अनचाहे विशेष वर्ण मौजूद हैं.
  8. नीचे दिए गए किसी एक तरीके का इस्तेमाल करके तय करें कि मैसेज प्रोसेसर किस टारगेट सर्वर होस्ट पर कम्यूनिकेट करने की कोशिश कर रहा है:
    1. Host not reachable वाले गड़बड़ी के मैसेज को ध्यान से देखें.
    2. अगर गड़बड़ी का मैसेज, होस्ट का नाम दिखाता है, तो स्पेस या खास वर्णों के साथ होस्ट नेम कॉपी करें.
    3. अगर गड़बड़ी का मैसेज, होस्ट के नाम के लिए शून्य दिखाता है, जैसा कि गड़बड़ी के इस मैसेज में दिखाया गया है, 
      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 नीति का इस्तेमाल किया जाता है, तो नीति की परिभाषा और कोड की जांच करें. साथ ही, पक्का करें कि टारगेट सर्वर का होस्टनेम सही तरीके से जनरेट किया गया हो.

एसएसएल हैंडशेक काम नहीं करना

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

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

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

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

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

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

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

नीचे दिए गए डायग्राम में, Apigee Edge के लिए, उत्तर की और दक्षिण की ओर जाने वाले कनेक्शन को दिखाया गया है.

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

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

यह पता लगाने के लिए कि क्या '503 सेवा उपलब्ध नहीं है' गड़बड़ी, उत्तर की तरफ़ या दक्षिण की तरफ़ मौजूद कनेक्शन पर हुई है, इनमें से किसी एक प्रोसेस का इस्तेमाल करें.

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

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

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