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

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

वीडियो

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

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

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

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

आपको गड़बड़ी का यह जवाब दिखेगा:

HTTP/1.1 503 Service Unavailable
  

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

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

संभावित कारण

आम तौर पर, NoActiveTargets गड़बड़ी कोड के साथ 503 Service Unavailable एचटीटीपी रिस्पॉन्स तब दिखता है, जब एपीआई प्रॉक्सी में टारगेट एंडपॉइंट कॉन्फ़िगरेशन में एक या उससे ज़्यादा टारगेट सर्वर का इस्तेमाल किया जाता है.

इस प्लेबुक में, 503 सेवा उपलब्ध नहीं है गड़बड़ी के बारे में बताया गया है. यह गड़बड़ी, हेल्थ चेक फ़ेल होने की वजह से होती है. इसका गड़बड़ी कोड NoActiveTargets है. इस गड़बड़ी की अन्य वजहों के बारे में जानने के लिए, कृपया यह प्लेबुक देखें.

हेल्थ चेक की प्रोसेस पूरी न हो पाना

अगर आपने एपीआई प्रॉक्सी के टारगेट एंडपॉइंट में, टारगेट सर्वर लोड बैलेंसिंग कॉन्फ़िगरेशन के हिस्से के तौर पर Health Monitor को कॉन्फ़िगर किया है, तो ही आपको हेल्थ चेक फ़ेल होने की सूचना मिलेगी.

जब कोई टारगेट सर्वर, हेल्थ चेक में फ़ेल हो जाता है, तो Edge उस सर्वर के फ़ेल होने की संख्या बढ़ा देता है. अगर उस सर्वर के लिए, हेल्थ चेक फ़ेल होने की संख्या पहले से तय की गई थ्रेशोल्ड (<MaxFailures>) तक पहुंच जाती है, तो Message Processor, चेतावनी वाले मैसेज को अपनी लॉग फ़ाइल में इस तरह से लॉग करता है:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

चेतावनी वाले मैसेज में यह जानकारी दी जाती है. इससे आपको यह समझने में मदद मिलती है कि किस टारगेट सर्वर ने MaxFailure काउंट हासिल किया:

• टारगेट सर्वर का नाम
• संगठन और एनवायरमेंट के नाम
• एपीआई प्रॉक्सी का नाम
• टारगेट एंडपॉइंट का नाम

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

हेल्थ मॉनिटर का इस्तेमाल करने से, Apigee Edge को टारगेट सर्वर को रोटेशन में अपने-आप शामिल करने में मदद मिलती है. ऐसा तब होता है, जब टारगेट सर्वर ठीक हो जाता है. इसके लिए, एपीआई प्रॉक्सी को फिर से डिप्लॉय करने की ज़रूरत नहीं होती.

यहां हेल्थ चेक फ़ेल होने की संभावित वजहें दी गई हैं:

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

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

आम तौर पर दिखने वाली गड़बड़ी के मैसेज

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

503 सेवा उपलब्ध नहीं है गड़बड़ी के लिए, मैसेज प्रोसेसर के लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) में गड़बड़ी के ये मैसेज दिखते हैं. इस गड़बड़ी का कोड NoActiveTargets है:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

इन गड़बड़ी के मैसेज से पता चलता है कि अनुरोध को बैकएंड सर्वर पर नहीं भेजा जा सका. इसकी वजह यह है कि अनुरोध पूरा नहीं किया जा सका. इस वजह से, मैसेज प्रोसेसर क्लाइंट को 503 सेवा उपलब्ध नहीं है गड़बड़ी कोड NoActiveTargets के साथ भेजता है.

वजह: कनेक्शन टाइम आउट हो गया

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

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

   उदाहरण के लिए, यहां दिए गए हेल्थ मॉनिटर के गड़बड़ी के मैसेज से पता चलता है कि हेल्थ चेक एपीआई का अनुरोध करते समय, मैसेज प्रोसेसर को कनेक्शन टाइम आउट की गड़बड़ी का सामना करना पड़ा:

   Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
   java.net.ConnectException: Connection timed out (Connection timed out)
   	at java.net.PlainSocketImpl.socketConnect(Native Method)
   	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   …<snipped>
           

   अगर यह गड़बड़ी, हेल्थ मॉनिटर में कॉन्फ़िगर की गई MaxFailure संख्या से ज़्यादा बार होती है, तो आपको इस तरह की चेतावनी दिखेगी:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   चेतावनी वाले मैसेज में दी गई जानकारी को ध्यान से पढ़ें. पक्का करें कि MaxFailure की संख्या, उस टारगेट सर्वर के लिए पहुंच गई हो जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आपको गड़बड़ी कोड NoActiveTargets के साथ 503 रिस्पॉन्स कोड मिल रहा है.

4. ऊपर दिए गए उदाहरण में, connection timed out गड़बड़ी की वजह से हेल्थ चेक पूरा नहीं हो सका. telnet कमांड का इस्तेमाल करके, यह देखें कि क्या हर मैसेज प्रोसेसर से सीधे तौर पर किसी बैकएंड सर्वर से कनेक्ट किया जा सकता है:

telnet <BackendServer-HostName> 443
      

5. अगर बैकएंड सर्वर से कनेक्ट किया जा सकता है, तो आपको बैकएंड-सर्वर से कनेक्ट किया गया जैसा मैसेज दिख सकता है. ऐसा हो सकता है कि यह समस्या कुछ समय के लिए हो. ऐसा भी हो सकता है कि यह समस्या ठीक हो गई हो या बार-बार हो रही हो. चौथे चरण को कुछ बार (10 से ज़्यादा बार) दोहराएं और आउटपुट की पुष्टि करें.
1. अगर telnet कमांड में लगातार कोई गड़बड़ी नहीं होती है, तो इसका मतलब है कि समस्या हल हो गई है. फिर से जांच करें कि हेल्थ चेक फ़ेल होने की समस्या ठीक हुई है या नहीं. अगर हां, तो आपको कुछ और करने की ज़रूरत नहीं है.
2. अगर आपको telnet कमांड का इस्तेमाल करके, बैकएंड सर्वर से बार-बार कनेक्ट करने में समस्या आ रही है, तो हो सकता है कि नेटवर्क में कोई समस्या हो या आपका बैकएंड सर्वर व्यस्त हो.
6. अगर आपको telnet कमांड का इस्तेमाल करके, बैकएंड सर्वर से कनेक्ट करने में लगातार समस्या आ रही है, तो ऐसा इसलिए हो सकता है, क्योंकि मैसेज प्रोसेसर को उस बैकएंड सर्वर से ट्रैफ़िक भेजने की अनुमति नहीं है.

रिज़ॉल्यूशन

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

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

वजह: असुरक्षित पोर्ट पर सुरक्षित अनुरोध किया गया

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

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

   उदाहरण के लिए, आपको नीचे दी गई इमेज में दिखाए गए तरीके से, HEALTH MONITOR की गड़बड़ी दिख सकती है:

   Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
           at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
           at sun.security.ssl.InputRecord.read(InputRecord.java:527)
           at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
   …<snipped>
           

   अगर यह गड़बड़ी, हेल्थ मॉनिटर में कॉन्फ़िगर की गई MaxFailure बार दोहराई जाती है, तो आपको इस तरह का चेतावनी वाला मैसेज दिखेगा:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   चेतावनी वाले मैसेज में दी गई जानकारी को ध्यान से पढ़ें. पक्का करें कि MaxFailure की संख्या, उस टारगेट सर्वर के लिए पहुंच गई हो जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आपको गड़बड़ी कोड NoActiveTargets के साथ 503 रिस्पॉन्स कोड मिल रहा है.

4. इस गड़बड़ी की वजह से, हेल्थ चेक पूरा नहीं हो सका:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   गड़बड़ी के मैसेज और यूआरएल से पता चलता है कि इस समस्या की वजह यह है कि सुरक्षित कॉल (एचटीटीपीएस) को गैर-सुरक्षित पोर्ट 80 पर किया गया था.

   यह गड़बड़ी इन दो स्थितियों में हो सकती है:

   • सुरक्षित टारगेट सर्वर को असुरक्षित पोर्ट के साथ तय किया गया है
   • सुरक्षित टारगेट सर्वर तय किया गया है, लेकिन हेल्थ मॉनिटर को असुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है

   सुरक्षित टारगेट, गैर-सुरक्षित पोर्ट

   पहला परिदृश्य: सुरक्षित टारगेट सर्वर को असुरक्षित पोर्ट के साथ तय किया गया है

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

   1. टारगेट एंडपॉइंट कॉन्फ़िगरेशन में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखें.

   टारगेट सर्वर की परिभाषा पाने के लिए, Get TargetServer API का इस्तेमाल करें.

   टारगेट सर्वर की परिभाषा का आउटपुट

   <TargetServer name="mocktarget">
     <Host>mocktarget.apigee.net</Host>
     <Port>80</Port>
     <IsEnabled>true</IsEnabled>
     <SSLInfo>
         <Enabled>true</Enabled>
     </SSLInfo>
   </TargetServer>
             

   ऊपर दिए गए उदाहरण में, परिभाषा से पता चलता है कि टारगेट सर्वर mocktarget एक सुरक्षित सर्वर है. यह SSLInfo ब्लॉक से पता चलता है. हालांकि, इसे असुरक्षित पोर्ट 80 के साथ कॉन्फ़िगर किया गया है.

   2. अब टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, टारगेट सर्वर के लिए हेल्थ मॉनिटर कॉन्फ़िगरेशन देखें:

      सेहत की निगरानी करने की सुविधा का कॉन्फ़िगरेशन

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      ध्यान दें कि ऊपर दिए गए हेल्थ मॉनिटर कॉन्फ़िगरेशन में, कोई <Port> एलिमेंट नहीं दिया गया है. इस मामले में, Edge का मैसेज प्रोसेसर, टारगेट सर्वर की परिभाषा में दिए गए पोर्ट (जो कि 80 है) का इस्तेमाल करके, हेल्थ चेक एपीआई कॉल करता है.

   3. ऊपर दी गई जानकारी के आधार पर, इस गड़बड़ी की वजह यह है कि टारगेट सर्वर को सुरक्षित सर्वर के तौर पर तय किया गया है. ऐसा इसलिए, क्योंकि SSLInfo ब्लॉक चालू है. हालांकि, इसके लिए असुरक्षित पोर्ट 80 का इस्तेमाल किया जा रहा है.

   सुरक्षित टारगेट, असुरक्षित एचएम पोर्ट

   दूसरा उदाहरण: सुरक्षित टारगेट सर्वर तय किया गया है, लेकिन हेल्थ मॉनिटर को असुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है

   अगर आपने सुरक्षित टारगेट सर्वर तय किया है, लेकिन हेल्थ मॉनिटर को 80 जैसे असुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है, तो आपको यह गड़बड़ी दिखेगी. इस समस्या की वजह जानने के लिए, यहां दिया गया तरीका अपनाएं:

   1. टारगेट एंडपॉइंट कॉन्फ़िगरेशन में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखें.

      टारगेट सर्वर की परिभाषा पाने के लिए, Get TargetServer API का इस्तेमाल करें.

      टारगेट सर्वर की परिभाषा का आउटपुट

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
              

      ऊपर दिए गए उदाहरण में, परिभाषा से पता चलता है कि टारगेट सर्वर mocktarget एक सुरक्षित सर्वर है. इसकी जानकारी SSLInfo ब्लॉक से मिलती है.

   2. इसके बाद, टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, टारगेट सर्वर के लिए Health Monitor कॉन्फ़िगरेशन की जांच करें:

      सेहत की निगरानी करने की सुविधा का कॉन्फ़िगरेशन

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      ऊपर दिए गए उदाहरण में, हेल्थ मॉनिटर को पोर्ट 80 के साथ कॉन्फ़िगर किया गया है. यह सुरक्षित नहीं है. इसे <Port> एलिमेंट से दिखाया गया है.

   3. ऊपर दी गई जानकारी के आधार पर, इस गड़बड़ी की वजह यह है कि टारगेट सर्वर को सुरक्षित सर्वर के तौर पर तय किया गया है. ऐसा इसलिए, क्योंकि SSLInfo ब्लॉक चालू है. साथ ही, यह सुरक्षित पोर्ट 443 का इस्तेमाल करता है. हालांकि, हेल्थ मॉनिटर को गैर-सुरक्षित पोर्ट 80 के साथ हेल्थ चेक करने के लिए कॉन्फ़िगर किया गया है. यह पोर्ट, <Port> एलिमेंट में दिया गया है.

      इसका मतलब है कि इस मामले में, Edge, हेल्थ चेक एपीआई को सुरक्षित कॉल के तौर पर बनाता है. हालांकि, इसमें पोर्ट 80 का इस्तेमाल किया जाता है, जो सुरक्षित नहीं है. इसलिए, ऊपर बताई गई गड़बड़ी होती है.

रिज़ॉल्यूशन

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    

वजह: सुरक्षित पोर्ट पर असुरक्षित अनुरोध

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

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

   उदाहरण के लिए, आपको नीचे दी गई इमेज में दिखाए गए तरीके से, HEALTH MONITOR की गड़बड़ी दिख सकती है:

   Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
   …<snipped>
             

   अगर यह गड़बड़ी, हेल्थ मॉनिटर में कॉन्फ़िगर की गई MaxFailure बार दोहराई जाती है, तो आपको इस तरह का चेतावनी वाला मैसेज दिखेगा:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

   चेतावनी वाले मैसेज में दी गई जानकारी को ध्यान से पढ़ें. पक्का करें कि MaxFailure की संख्या, उस टारगेट सर्वर के लिए पहुंच गई हो जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आपको गड़बड़ी कोड NoActiveTargets के साथ 503 रिस्पॉन्स कोड मिल रहा है.

4. इस गड़बड़ी की वजह से, हेल्थ चेक पूरा नहीं हो सका:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   गड़बड़ी के मैसेज और यूआरएल से पता चलता है कि इस समस्या की वजह यह है कि सुरक्षित पोर्ट 443 पर नॉन-सिक्योर कॉल (एचटीटीपी) किया गया था.

   यह गड़बड़ी इन दो स्थितियों में हो सकती है:

   • सुरक्षित पोर्ट के साथ तय किया गया असुरक्षित टारगेट सर्वर
   • नॉन-सिक्योर टारगेट सर्वर तय किया गया है, लेकिन हेल्थ मॉनिटर को सुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है

   गैर-सुरक्षित टारगेट सुरक्षित पोर्ट

   पहला उदाहरण: सुरक्षित पोर्ट के साथ तय किया गया असुरक्षित टारगेट सर्वर

   अगर आपने असुरक्षित टारगेट सर्वर को सुरक्षित पोर्ट (जैसे कि 443) के साथ तय किया है, तो आपको यह गड़बड़ी दिखेगी. इस समस्या की वजह जानने के लिए, यहां दिया गया तरीका अपनाएं:

   1. टारगेट एंडपॉइंट कॉन्फ़िगरेशन में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखें.

      टारगेट सर्वर की परिभाषा पाने के लिए, Get TargetServer API का इस्तेमाल करें.

      टारगेट सर्वर की परिभाषा का आउटपुट

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
                    

      ऊपर दिए गए उदाहरण में, परिभाषा से पता चलता है कि टारगेट सर्वर mocktarget एक असुरक्षित सर्वर है, क्योंकि इसमें कोई SSLInfo ब्लॉक नहीं है. हालांकि, इसे सुरक्षित पोर्ट 443 के साथ गलत तरीके से कॉन्फ़िगर किया गया है.

   2. अब टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, टारगेट सर्वर के लिए हेल्थ मॉनिटर कॉन्फ़िगरेशन देखें:

      सेहत की निगरानी करने की सुविधा का कॉन्फ़िगरेशन

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      ध्यान दें कि ऊपर दिए गए हेल्थ मॉनिटर कॉन्फ़िगरेशन में, कोई <Port> एलिमेंट नहीं दिया गया है. इस मामले में, Edge का मैसेज प्रोसेसर, टारगेट सर्वर की परिभाषा में दिया गया पोर्ट इस्तेमाल करेगा. यह पोर्ट 443 है.

   3. ऊपर दी गई जानकारी के आधार पर, इस गड़बड़ी की वजह यह है कि टारगेट सर्वर को असुरक्षित सर्वर के तौर पर तय किया गया है, क्योंकि SSLInfo ब्लॉक तय नहीं किया गया है. हालांकि, इसे सुरक्षित पोर्ट 443 के साथ तय किया गया है.

      इसका मतलब है कि Edge, हेल्थ चेक को सुरक्षित पोर्ट 443 के साथ गैर-सुरक्षित कॉल के तौर पर करता है और ऊपर बताई गई गड़बड़ी की वजह से ऐसा नहीं हो पाता.

   गैर-सुरक्षित टारगेट सुरक्षित एचएम पोर्ट

   दूसरी स्थिति: टारगेट सर्वर को असुरक्षित के तौर पर तय किया गया है, लेकिन हेल्थ मॉनिटर को सुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है

   अगर आपने असुरक्षित टारगेट सर्वर तय किया है, लेकिन हेल्थ मॉनिटर को 443 जैसे सुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है, तो आपको यह गड़बड़ी दिखेगी. इस समस्या की वजह जानने के लिए, यहां दिया गया तरीका अपनाएं:

   1. टारगेट एंडपॉइंट कॉन्फ़िगरेशन में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखें.

      टारगेट सर्वर की परिभाषा पाने के लिए, Get TargetServer API का इस्तेमाल करें.

      टारगेट सर्वर की परिभाषा का आउटपुट

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      ऊपर दिए गए उदाहरण में, परिभाषा से पता चलता है कि टारगेट सर्वर mocktarget एक असुरक्षित सर्वर है, क्योंकि इसमें कोई SSLInfo ब्लॉक नहीं है. इसे असुरक्षित पोर्ट 80 के साथ सही तरीके से कॉन्फ़िगर किया गया है.

   2. इसके बाद, टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, टारगेट सर्वर के लिए Health Monitor कॉन्फ़िगरेशन की जांच करें:

      सेहत की निगरानी करने की सुविधा का कॉन्फ़िगरेशन

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      ऊपर दिए गए उदाहरण में, हेल्थ मॉनिटर को सुरक्षित पोर्ट 443 के साथ कॉन्फ़िगर किया गया है. इसे <Port> एलिमेंट से दिखाया गया है.

   3. ऊपर दी गई जानकारी के आधार पर, इस गड़बड़ी की वजह यह है कि टारगेट सर्वर को एक असुरक्षित सर्वर के तौर पर तय किया गया है. ऐसा इसलिए, क्योंकि SSLInfo ब्लॉक को तय नहीं किया गया है. साथ ही, असुरक्षित पोर्ट 80 को सही तरीके से तय किया गया है. हालांकि, Health Monitor को सुरक्षित पोर्ट 443 के साथ हेल्थ चेक करने के लिए कॉन्फ़िगर किया गया है. यह पोर्ट, <Port> एलिमेंट में दिया गया है.

      इसका मतलब है कि इस मामले में, Edge सुरक्षित पोर्ट 443 के साथ, हेल्थ चेक को गैर-सुरक्षित कॉल के तौर पर करता है. साथ ही, ऊपर बताई गई गड़बड़ी की वजह से यह काम नहीं करता.

रिज़ॉल्यूशन

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

वजह: हेल्थ चेक एपीआई से गड़बड़ी का मैसेज मिला है

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

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

   उदाहरण के लिए, आपको हेल्थ मॉनिटर की चेतावनी इस तरह दिख सकती है:

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
   Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
           

   अगर यह गड़बड़ी, हेल्थ मॉनिटर में कॉन्फ़िगर की गई MaxFailure बार दोहराई जाती है, तो आपको इस तरह का चेतावनी वाला मैसेज दिखेगा:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   चेतावनी वाले मैसेज में दी गई जानकारी को ध्यान से पढ़ें. पक्का करें कि MaxFailure की संख्या, उस टारगेट सर्वर के लिए पहुंच गई हो जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आपको गड़बड़ी कोड NoActiveTargets के साथ 503 रिस्पॉन्स कोड मिल रहा है.

4. स्वास्थ्य जांच में यह चेतावनी मैसेज मिला है:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   ऊपर दिए गए चेतावनी वाले मैसेज में बताया गया है कि हेल्थ चेक एपीआई के लिए, रिस्पॉन्स कोड 200 होना चाहिए था. हालांकि, असल में मिला रिस्पॉन्स 404 है. इसलिए, इसे एक गड़बड़ी माना जाता है.

5. हेल्थ चेक एपीआई से गड़बड़ी वाले जवाब की वजह की जांच करने से पहले, यह पता लगाएं कि Edge को हेल्थ चेक एपीआई के लिए, रिस्पॉन्स कोड के तौर पर 200 की ज़रूरत क्यों होती है. इसके लिए, टारगेट एंडपॉइंट कॉन्फ़िगरेशन में टारगेट सर्वर के लिए, हेल्थ मॉनिटर कॉन्फ़िगरेशन की जांच करें:

   सेहत की निगरानी करने की सुविधा का कॉन्फ़िगरेशन

   <HealthMonitor>
     <IsEnabled>true</IsEnabled>
     <IntervalInSec>5</IntervalInSec>
     <HTTPMonitor>
       <Request>
         <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
         <Port>443</Port>
         <Verb>GET</Verb>
         <Path>/status/200</Path>
       </Request>
       <SuccessResponse>
         <ResponseCode>200</ResponseCode>
       </SuccessResponse>
     </HTTPMonitor>
   </HealthMonitor>
           

   ध्यान दें कि <SuccessResponse> एलिमेंट में, हेल्थ मॉनिटर कॉन्फ़िगरेशन को 200 रिस्पॉन्स कोड के साथ कॉन्फ़िगर किया गया है. इसका मतलब है कि अगर Edge को हेल्थ चेक एपीआई से 200 के अलावा कोई अन्य रिस्पॉन्स कोड (जैसे कि 400, 401, 404, 500) मिलता है, तो इसे गड़बड़ी माना जाएगा. साथ ही, गड़बड़ियों की संख्या बढ़ जाएगी.

6. अब, हेल्थ चेक एपीआई से गड़बड़ी का जवाब मिलने की वजह जानने के लिए, यह तरीका अपनाएं:
1. मैसेज प्रोसेसर के लॉग में, चेतावनी वाले मैसेज से पहले का मैसेज देखें.

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
             

   इस मैसेज में दिए गए हेल्थ चेक यूआरएल को नोट करें.

2. मैसेज प्रोसेसर से इस यूआरएल पर सीधे कॉल किया जा सकता है और असली जवाब देखा जा सकता है

   curl -i https://mocktarget.apigee.net:443/status/200
             

   ऊपर दिए गए कॉल के जवाब में, मैसेज प्रोसेसर के लॉग में दिख रहा 404 कोड दिया गया है:

   < HTTP/2 404
             

3. इससे पता चलता है कि हेल्थ चेक यूआरएल को सीधे तौर पर कॉल करने पर भी, रिस्पॉन्स कोड 404 मिलता है. इसका मतलब है कि हेल्थ चेक का यूआरएल गलत हो सकता है या यूआरएल के हिस्से के तौर पर ऐक्सेस की जा रही संसाधन अब उपलब्ध नहीं है.
4. ऊपर दिए गए उदाहरण में, हेल्थ चेक एपीआई में समस्या इसलिए आ रही है, क्योंकि हेल्थ मॉनिटर के कॉन्फ़िगरेशन में गलत यूआरएल का इस्तेमाल किया गया है. Mock Target API से, सही यूआरएल https://mocktarget.apigee.net:443/statuscode/200 मिला है.
7. अगर आपको गड़बड़ी से जुड़ा कोई दूसरा जवाब मिलता है, तो ऊपर दिए गए चरणों को अपनाकर, गड़बड़ी की वजह का पता लगाएं. अगर ज़रूरी हो, तो अपनी बैकएंड टीम के साथ मिलकर काम करें.

रिज़ॉल्यूशन

1. अपने बैकएंड सर्वर पर, हेल्थ चेक एपीआई से जुड़ी समस्या ठीक करें.
2. ऊपर दिए गए उदाहरण में समस्या को ठीक करने के लिए:
1. नीचे दिखाए गए तरीके से, हेल्थ मॉनिटर के कॉन्फ़िगरेशन में मौजूद <Path> एलिमेंट को /statuscode/200 में बदलें:

   <Path>/statuscode/200</Path>
           

2. एपीआई प्रॉक्सी में किए गए बदलावों को सेव करें.

अगर समस्या अब भी बनी रहती है, तो गड़बड़ी की जानकारी इकट्ठा करना ज़रूरी है पर जाएं.

एपीआई मॉनिटरिंग का इस्तेमाल करके समस्याओं का पता लगाना

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

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

डाइग्नोस्टिक जानकारी इकट्ठा करना ज़रूरी है

अगर ऊपर दिए गए निर्देशों का पालन करने के बाद भी समस्या बनी रहती है, तो कृपया डाइग्नोस्टिक की यह जानकारी इकट्ठा करें. इनसे संपर्क करें और इन्हें Apigee की सहायता टीम के साथ शेयर करें:

1. अगर आप पब्लिक क्लाउड का इस्तेमाल करते हैं, तो यह जानकारी दें:
1. संगठन का नाम
2. एनवायरमेंट का नाम
3. एपीआई प्रॉक्सी का नाम
4. गड़बड़ी को फिर से बनाने के लिए, कर्ल कमांड को पूरा करें
5. इस ट्रेस फ़ाइल में, NoActiveTargets गड़बड़ी कोड के साथ 503 Service Unavailable गड़बड़ी वाले अनुरोध शामिल हैं
2. अगर आप Private Cloud के उपयोगकर्ता हैं, तो यह जानकारी दें:
   1. गड़बड़ी का पूरा मैसेज मिला
   2. एनवायरमेंट का नाम
   3. एपीआई प्रॉक्सी बंडल
   4. इस ट्रेस फ़ाइल में, NoActiveTargets गड़बड़ी कोड के साथ 503 Service Unavailable गड़बड़ी वाले अनुरोध शामिल हैं
   5. NGINX ऐक्सेस लॉग

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

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

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)