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 के प्राइवेट क्लाउड के उपयोगकर्ता
कनेक्शन की गड़बड़ियां नेटवर्क या कनेक्टिविटी से जुड़ी समस्याएं, क्लाइंट को सर्वर से कनेक्ट करने से रोकती हैं. Edge के प्राइवेट क्लाउड के उपयोगकर्ता
टारगेट सर्वर होस्ट का गलत नाम तय किया गया टारगेट सर्वर होस्ट गलत है या उसमें अनचाहे वर्ण (जैसे कि स्पेस) हैं. Edge के सार्वजनिक और प्राइवेट क्लाउड उपयोगकर्ता
एसएसएल हैंडशेक की गड़बड़ी क्लाइंट और सर्वर के बीच TLS/SSL हैंडशेक विफल हो गया. (इस वर्ग के लिए समस्या निवारण सवाल किसी अलग विषय में दिया गया है.) Edge के सार्वजनिक और प्राइवेट क्लाउड उपयोगकर्ता

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

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

ट्रेस करने वाला टूल

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

  1. अगर समस्या अब भी बनी हुई है, तो जिस एपीआई पर असर हुआ है उसके लिए ट्रेस सेशन चालू करें.
  2. एपीआई कॉल करें और समस्या के बारे में फिर से बताएं - 503 सेवा, गड़बड़ी कोड messaging.adaptors.http.flow.ServiceUnavailable. के साथ उपलब्ध नहीं है
  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.adapters.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 मैसेज प्रोसेसर, बैकएंड से कनेक्ट करने की कोशिश करता है, तब कनेक्शन में गड़बड़ी होती है सर्वर और इनमें से कोई समस्या होती है:

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

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

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

रिज़ॉल्यूशन

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

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

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

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

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

ट्रेस करने वाला टूल

ट्रेस करने वाले टूल की मदद से पता लगाने के लिए:

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

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

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

      उदाहरण के लिए, होस्ट के नाम में अनचाहा स्पेस है, जैसा कि नीचे दिखाया गया है:
      "demo-target.apigee.net "
                        
    • assignMessage का इस्तेमाल करके एपीआई प्रॉक्सी में target.url वैरिएबल से बदला गया होस्ट नाम या JavaScript की नीति गलत है या इसमें खाली जगह या दूसरे खास वर्ण का इस्तेमाल किया गया है.
  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. कभी-कभी यह शून्य के तौर पर दिख सकता है, क्योंकि होस्ट नेम को ठीक नहीं किया जा सकता या ऐक्सेस नहीं किया जा सकता, जैसा कि नीचे दिखाया गया है:
    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. टारगेट सर्वर होस्ट का वह नाम पता करें जिस पर मैसेज प्रोसेसर, नीचे दिए गए विकल्पों में से किसी एक का इस्तेमाल करके मैसेज भेजने की कोशिश कर रहा है:
    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/एसएसएल हैंडशेक की गड़बड़ियों के बारे में बताती है. SSL हैंडशेक विफलताएं देखें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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