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

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

वीडियो

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

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

क्लाइंट ऐप्लिकेशन को सेवा उपलब्ध नहीं है मैसेज और गड़बड़ी कोड NoActiveTarget का इस्तेमाल किया जा सकता है.

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

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

HTTP/1.1 503 Service Unavailable
  

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

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

संभावित कारण

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

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

स्वास्थ्य जांच में गड़बड़ी

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

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

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

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

यहां स्वास्थ्य जांच विफल होने के संभावित कारण दिए गए हैं:

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

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

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

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

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

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 उस टारगेट सर्वर की संख्या पूरी हो गई है जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आप हैं 503 रिस्पॉन्स कोड का सामना कर रहा है. साथ ही, गड़बड़ी कोड NoActiveTargets दिख रहा है.

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

telnet <BackendServer-HostName> 443
      

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

रिज़ॉल्यूशन

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

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

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

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

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

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

   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 उस टारगेट सर्वर की संख्या पूरी हो गई है जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आप हैं 503 रिस्पॉन्स कोड का सामना कर रहा है. साथ ही, गड़बड़ी कोड NoActiveTargets दिख रहा है.

4. गड़बड़ी की वजह से, कैंपेन की परफ़ॉर्मेंस की जांच नहीं की जा सकी:

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

   अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

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

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

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

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

   इसका इस्तेमाल करें 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. अब टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, टारगेट सर्वर के लिए Health Monitor कॉन्फ़िगरेशन देखें:

      हेल्थ मॉनिटर का कॉन्फ़िगरेशन

      <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 हो.

   सुरक्षित टारगेट असुरक्षित HM पोर्ट

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

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

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

      का उपयोग करें टारगेट सर्वर की परिभाषा पाने के लिए, 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>
              

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

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

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

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

   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 उस टारगेट सर्वर की संख्या पूरी हो गई है जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आप हैं 503 रिस्पॉन्स कोड का सामना कर रहा है. साथ ही, गड़बड़ी कोड NoActiveTargets दिख रहा है.

4. गड़बड़ी की वजह से, कैंपेन की परफ़ॉर्मेंस की जांच नहीं की जा सकी:

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

   अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

   असुरक्षित टारगेट सिक्योर पोर्ट

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

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

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

      का उपयोग करें टारगेट सर्वर की परिभाषा पाने के लिए, TargetServer API पाएं.

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

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

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

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

      हेल्थ मॉनिटर का कॉन्फ़िगरेशन

      <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>
                      

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

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

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

   असुरक्षित टारगेट सुरक्षित HM पोर्ट

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

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

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

      का उपयोग करें टारगेट सर्वर की परिभाषा पाने के लिए, 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>
            

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

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

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

रिज़ॉल्यूशन

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

वजह: Health Check API की क्वेरी के जवाब में गड़बड़ी दिख रही है

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

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

   उदाहरण के लिए, आपको स्वास्थ्य पर निगरानी रखने वाली चेतावनी दिख सकती है, जैसा कि यहां दिखाया गया है:

   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 उस टारगेट सर्वर की संख्या पूरी हो गई है जिसका इस्तेमाल उस खास एपीआई प्रॉक्सी में किया गया है जिसके लिए आप हैं 503 रिस्पॉन्स कोड का सामना कर रहा है. साथ ही, गड़बड़ी कोड NoActiveTargets दिख रहा है.

4. कैंपेन की परफ़ॉर्मेंस की जांच के दौरान चेतावनी वाला यह मैसेज मिला:

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

   अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

5. Health Check API की मदद से गड़बड़ी के जवाब की वजह जानने से पहले, यह पता कर लें कि Edge Health Check API के लिए रिस्पॉन्स कोड 200 होना चाहिए. इसके लिए, Health Monitor का इस्तेमाल करें टारगेट एंडपॉइंट कॉन्फ़िगरेशन में टारगेट सर्वर का कॉन्फ़िगरेशन:

   हेल्थ मॉनिटर का कॉन्फ़िगरेशन

   <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>
           

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

6. अब Health Check API से मिलने वाली गड़बड़ी की वजह का पता लगाने के लिए, यह तरीका अपनाएं:
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. ऊपर दिए गए हेल्थ चेक एपीआई के उदाहरण में, यह समस्या इसलिए आती है, क्योंकि हेल्थ मॉनिटर के कॉन्फ़िगरेशन में गलत यूआरएल का इस्तेमाल किया गया था. सही यूआरएल https://mocktarget.apigee.net:443/statuscode/200 से पाया गया था मॉक टारगेट एपीआई.
7. अगर आपको गड़बड़ी का कोई और जवाब मिलता है, तो उसकी वजह जानने के लिए, ऊपर दिए गए चरण देखें. अगर ज़रूरी हो, तो अपनी बैकएंड टीम की मदद लें.

रिज़ॉल्यूशन

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

   <Path>/statuscode/200</Path>
           

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

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

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

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

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

ऐप्लिकेशन की परफ़ॉर्मेंस से जुड़ी जानकारी इकट्ठा करना ज़रूरी है

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

1. अगर आप Public Cloud उपयोगकर्ता हैं, तो यह जानकारी दें:
1. संगठन का नाम
2. एनवायरमेंट का नाम
3. एपीआई प्रॉक्सी का नाम
4. गड़बड़ी को ठीक करने के लिए curl कमांड पूरा करें
5. 503 सेवा वाले अनुरोधों वाली ट्रेस फ़ाइल. यह गड़बड़ी कोड NoActiveTargets के साथ उपलब्ध नहीं है
2. अगर आप प्राइवेट क्लाउड उपयोगकर्ता हैं, तो यह जानकारी दें:
   1. पूरा गड़बड़ी का मैसेज दिखा
   2. एनवायरमेंट का नाम
   3. एपीआई प्रॉक्सी बंडल
   4. 503 सेवा वाले अनुरोधों वाली ट्रेस फ़ाइल. यह गड़बड़ी कोड NoActiveTargets के साथ उपलब्ध नहीं है
   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)