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

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

वीडियो

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

वीडियो ब्यौरा
समस्या हल करना और 503 सेवा उपलब्ध न होने की समस्या को हल करना - NoActiveTarget इनके बारे में जानें:
  • टारगेट सर्वर और हेल्थ मॉनिटर की अहमियत
  • रीयल-टाइम 503 सेवा उपलब्ध नहीं होने की समस्या का हल करना और उसे ठीक करना - स्वास्थ्य जांच में गड़बड़ी होने की वजह से कोई NoActiveTotal गड़बड़ी हुई

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

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

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

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

HTTP/1.1 503 Service Unavailable

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

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

संभावित कारण

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

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

परफ़ॉर्मेंस की जांच में गड़बड़ी

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

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

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

परफ़ॉर्मेंस की जांच में गड़बड़ी होने की ये वजहें हो सकती हैं:

वजह ब्यौरा समस्या हल करने वाले चरणों को कौन पूरा कर सकता है
कनेक्शन टाइम आउट की गड़बड़ी मैसेज प्रोसेसर, Load Balancer कॉन्फ़िगरेशन में बताए गए टाइम आउट अवधि के अंदर, टारगेट सर्वर से कनेक्ट नहीं कर सका. Edge Private Cloud के उपयोगकर्ता
बिना सुरक्षित पोर्ट पर सुरक्षित अनुरोध
  1. अगर टारगेट सर्वर को सुरक्षित सर्वर के तौर पर बताया गया है, लेकिन उसे गलत तरीके से किसी असुरक्षित पोर्ट के साथ कॉन्फ़िगर किया गया है.
  2. अगर टारगेट सर्वर को सुरक्षित सर्वर के तौर पर बताया गया है, लेकिन हेल्थ मॉनिटर को असुरक्षित पोर्ट पर हेल्थ जांच करने के लिए कॉन्फ़िगर किया गया है.
 Edge Private Cloud के उपयोगकर्ता
सुरक्षित पोर्ट पर असुरक्षित अनुरोध
  1. अगर टारगेट सर्वर को असुरक्षित सर्वर के तौर पर तय किया गया है, लेकिन सुरक्षित पोर्ट के साथ गलत तरीके से कॉन्फ़िगर किया गया है.
  2. अगर टारगेट सर्वर को असुरक्षित सर्वर के तौर पर बताया गया है, लेकिन हेल्थ मॉनिटर को सुरक्षित पोर्ट पर हेल्थ जांच करने के लिए कॉन्फ़िगर किया गया है.
 Edge Private Cloud के उपयोगकर्ता
Health Check API के जवाब में गड़बड़ी का मैसेज मिला अगर हेल्थ चेक एपीआई किसी गड़बड़ी या रिस्पॉन्स कोड के साथ जवाब देता है, तो HealthMonitor के SuccessResponse एलिमेंट के अलावा कुछ और. Edge Private Cloud के उपयोगकर्ता

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

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

ट्रेस टूल

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

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

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

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

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

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

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

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>

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

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

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

  1. फ़ेल न होने वाले अनुरोध का मैसेज आईडी तय करें.
  2. Message प्रोसेसर लॉग (/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 कमांड का इस्तेमाल करके, हर मैसेज प्रोसेसर से सीधे तौर पर किसी खास बैकएंड सर्वर से कनेक्ट किया जा पा रहा है या नहीं:
    5. telnet <BackendServer-HostName> 443
  5. अगर आपको बैकएंड सर्वर से कनेक्ट करने की अनुमति मिली, तो आपको बैकएंड-सर्वर से कनेक्ट किया गया जैसा एक मैसेज दिख सकता है. ऐसे में, वह समस्या कुछ समय के लिए हो सकती है. यह भी हो सकता है कि उसे ठीक कर लिया गया हो या वह कभी-कभी हो. चौथे चरण को कई बार (10 बार से ज़्यादा) दोहराएं और आउटपुट की पुष्टि करें.
    1. अगर telnet कमांड में लगातार कोई गड़बड़ी नहीं आती है, तो समस्या हल हो जाएगी. फिर से देखें कि ऐप्लिकेशन की परफ़ॉर्मेंस की जांच में गड़बड़ी हुई है या नहीं. अगर हां, तो आपको कुछ और करने की ज़रूरत नहीं है.
    2. अगर telnet कमांड का इस्तेमाल करके, हम बीच-बीच में बैकएंड सर्वर से कनेक्ट नहीं कर पा रहे हैं, तो हो सकता है कि नेटवर्क में कोई समस्या हो या आपका बैकएंड सर्वर व्यस्त हो.
  6. अगर आप लगातार telnet कमांड का इस्तेमाल करके, बैकएंड सर्वर से कनेक्ट नहीं कर पा रहे हैं, तो ऐसा इसलिए हो सकता है, क्योंकि मैसेज प्रोसेसर से किसी खास बैकएंड सर्वर पर ट्रैफ़िक की अनुमति नहीं मिलती.

रिज़ॉल्यूशन

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

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

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

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

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

    उदाहरण के लिए, आपको 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. टारगेट एंडपॉइंट के कॉन्फ़िगरेशन में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखें.

      2. टारगेट सर्वर की परिभाषा जानने के लिए, 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 कॉन्फ़िगरेशन की जांच करें:

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

      <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> एलिमेंट मौजूद नहीं है. इस मामले में, एज का मैसेज प्रोसेसर हेल्थ चेक एपीआई कॉल करने के लिए, टारगेट सर्वर डेफ़िनिशन (जो 80 है) में बताए गए पोर्ट का इस्तेमाल करता है.

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

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

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

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

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

      <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 का इस्तेमाल करता है. हालांकि, Health Monitor को असुरक्षित पोर्ट 80 (<Port> एलिमेंट में बताया गया) के साथ हेल्थ जांच करने के लिए कॉन्फ़िगर किया गया है.

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

रिज़ॉल्यूशन

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

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

इस गड़बड़ी को ठीक करने के लिए, टारगेट सर्वर की परिभाषा अपडेट करें, ताकि सही सुरक्षित पोर्ट का इस्तेमाल किया जा सके.

टारगेट सर्वर की परिभाषा को अपडेट करने के लिए, TargetServer API अपडेट करें का इस्तेमाल करें. साथ ही, पक्का करें कि एक सुरक्षित पोर्ट (उदाहरण के लिए: 443) का इस्तेमाल, नीचे दिए गए उदाहरण की तरह किया गया हो:

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

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

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

इस गड़बड़ी को ठीक करने के लिए, नीचे दिए गए निर्देशों का पालन करें:

  1. हेल्थ मॉनिटर कॉन्फ़िगरेशन में बदलाव करें, ताकि सुरक्षित पोर्ट (उदाहरण: 443) का इस्तेमाल करके, काम न करने वाले एपीआई प्रॉक्सी के टारगेट एंडपॉइंट कॉन्फ़िगरेशन में टारगेट सर्वर की हेल्थ की जांच की जा सके. इसके लिए, यहां देखें: 
    <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>
  2. एपीआई प्रॉक्सी में किए गए बदलावों को सेव करें.

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

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

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

    उदाहरण के लिए, आपको 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. टारगेट एंडपॉइंट के कॉन्फ़िगरेशन में इस्तेमाल किए गए टारगेट सर्वर की परिभाषा देखें.

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

      टारगेट सर्वर डेफ़िनिशन आउटपुट

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

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

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

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

      <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 की मदद से असुरक्षित कॉल के तौर पर हेल्थ चेक करता है और ऊपर बताई गई गड़बड़ी की वजह से काम नहीं कर पाता.

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

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

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

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

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

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

रिज़ॉल्यूशन

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

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

इस गड़बड़ी को ठीक करने के लिए, टारगेट सर्वर की परिभाषा अपडेट करें, ताकि सही सुरक्षित पोर्ट का इस्तेमाल किया जा सके.

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

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

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

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

इस गड़बड़ी को ठीक करने के लिए, नीचे दिए गए निर्देशों का पालन करें:

  1. हेल्थ मॉनिटर कॉन्फ़िगरेशन से <Port> एलिमेंट हटाएं या नॉन-सुरक्षित पोर्ट (उदाहरण के लिए: 80) का इस्तेमाल करने के लिए, HealthMonitor कॉन्फ़िगरेशन में बदलाव करें. ऐसा, काम न करने वाले एपीआई प्रॉक्सी के टारगेट एंडपॉइंट कॉन्फ़िगरेशन में, टारगेट सर्वर हेल्थ की जांच करने के लिए करें, जैसा कि यहां दिखाया गया है: 
    <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>
</HealthMonitor>
  2. एपीआई प्रॉक्सी में किए गए बदलावों को सेव करें.

वजह: सेहत की जांच करने वाला एपीआई, गड़बड़ी के साथ जवाब देता है

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

  1. फ़ेल न होने वाले अनुरोध का मैसेज आईडी तय करें.
  2. Message प्रोसेसर लॉग (/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. हेल्थ चेक एपीआई से मिली गड़बड़ी के रिस्पॉन्स की वजह का पता लगाने से पहले, यह तय करें कि Health Check API के लिए रिस्पॉन्स कोड, 200 क्यों होना चाहिए. इसके लिए, टारगेट एंडपॉइंट कॉन्फ़िगरेशन में टारगेट सर्वर के लिए HealthMonitor कॉन्फ़िगरेशन की जांच करें:

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

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