500 सर्वर में गड़बड़ी

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

वीडियो

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

वीडियो ब्यौरा
शुरुआती जानकारी यह 500 सर्वर की गड़बड़ियों और संभावित वजहों के बारे में जानकारी देता है. साथ ही, गड़बड़ी को ठीक करने और उसे ठीक करने के तरीकों के साथ, रीयल-टाइम में 500 सर्वर में सर्वर की गड़बड़ी दिखाता है.
सेवा के कॉलआउट को मैनेज करना और वैरिएबल की गड़बड़ियां निकालना यह सेवा कॉलआउट और एक्सट्रैक्ट वैरिएबल नीतियों की वजह से होने वाली दो 500 सर्वर की गड़बड़ियों को दिखाता है. साथ ही, इन गड़बड़ियों को ठीक करने और समस्या को हल करने का तरीका भी दिखाता है.
JavaScript नीति की गड़बड़ियां मैनेज करना JavaScript नीति की वजह से होने वाली 500 सर्वर में गड़बड़ी दिखाता है. साथ ही, इस गड़बड़ी को ठीक करने और इसे हल करने का तरीका दिखाता है.
बैकएंड सर्वर से जुड़ी गड़बड़ी ठीक करना बैकएंड सर्वर में गड़बड़ी की वजह से होने वाली, 500 सर्वर में होने वाली गड़बड़ियों के उदाहरण दिखाता है. साथ ही, गड़बड़ियों को ठीक करने का तरीका भी दिखाता है.

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

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

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

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

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

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

संभावित वजहें

500 सर्वर में गड़बड़ी होने की कई वजहें हो सकती हैं. Edge में, गड़बड़ी होने की जगह के आधार पर इन वजहों को दो मुख्य कैटगरी में बांटा जा सकता है:

Cause जानकारी समस्या हल करने के तरीके के बारे में ज़्यादा जानकारी, यहां दी गई है
Edge नीति में एक्ज़ीक्यूशन की गड़बड़ी एपीआई प्रॉक्सी में मौजूद कोई नीति किसी वजह से काम नहीं कर सकती. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता
बैकएंड सर्वर में गड़बड़ी किसी वजह से बैकएंड सर्वर काम नहीं कर सकता. Edge के निजी और सार्वजनिक क्लाउड के उपयोगकर्ता

Edge नीति में एक्ज़ीक्यूट करने में गड़बड़ी होना

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

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

निजी और सार्वजनिक क्लाउड के उपयोगकर्ताओं के लिए गड़बड़ी की जानकारी के चरण

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

  1. पुष्टि करें कि गड़बड़ी किसी नीति के चलने की वजह से हुई थी. ज़्यादा जानकारी के लिए, समस्या की वजह का पता लगाना देखें.
  2. अगर नीति लागू करने के दौरान गड़बड़ी हुई है, तो आगे बढ़ें.. अगर यह गड़बड़ी बैकएंड सर्वर की वजह से हुई थी, तो बैकएंड सर्वर में गड़बड़ी पर जाएं.
  3. वह एपीआई अनुरोध चुनें जो ट्रेस में 500 सर्वर में गड़बड़ी की वजह से काम नहीं कर रहा है.
  4. अनुरोध की जांच करें और उस नीति को चुनें जो फ़ेल हो गई है या "गड़बड़ी" नाम का वह फ़्लो चुनें जो ट्रेस में फ़ेल हो चुकी नीति के तुरंत बाद है.
  5. गड़बड़ी के बारे में ज़्यादा जानकारी पाने के लिए, प्रॉपर्टी सेक्शन में मौजूद "गड़बड़ी" फ़ील्ड या गड़बड़ी वाले कॉन्टेंट की जांच करें.
  6. गड़बड़ी के बारे में इकट्ठा की गई जानकारी का इस्तेमाल करके, इसकी वजह का पता लगाने की कोशिश करें.

सिर्फ़ प्राइवेट क्लाउड उपयोगकर्ताओं के लिए डाइग्नोस्टिक्स के चरण

अगर आपके पास ट्रेस यूज़र इंटरफ़ेस (यूआई) सेशन नहीं है, तो:

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

रिज़ॉल्यूशन

अगर आपने नीति से जुड़ी समस्या की वजह का पता लगा लिया है, तो नीति को ठीक करके प्रॉक्सी को फिर से डिप्लॉय करके, समस्या को ठीक करने की कोशिश करें.

इन उदाहरणों में, अलग-अलग तरह की समस्याओं की वजह और उनका समाधान ढूंढने का तरीका बताया गया है.

अगर आपको '500 इंटरनल सर्वर एरर' की समस्या हल करने के लिए और मदद चाहिए या आपको लगता है कि यह Edge में कोई समस्या है, तो Apigee की सहायता टीम से संपर्क करें.

उदाहरण 1: बैकएंड सर्वर में किसी गड़बड़ी की वजह से सेवा कॉलआउट की नीति में गड़बड़ी

अगर सेवा कॉलआउट नीति के तहत, 4XX या 5XX जैसी किसी गड़बड़ी की वजह से बैकएंड सर्वर पर कॉल नहीं हो पाता, तो इसे 500 सर्वर की गड़बड़ी माना जाएगा.

  1. यहां एक उदाहरण दिया गया है, जिसमें सेवा कॉलआउट नीति में 404 गड़बड़ी की वजह से बैकएंड सेवा काम नहीं करती. असली उपयोगकर्ता को गड़बड़ी का यह मैसेज भेजा गया है: 
    {
"fault":
     { "detail":
           { "errorcode":"steps.servicecallout.ExecutionFailed"
           },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
 failed. Reason: ResponseCode 404 is treated as error"
          }
     }
}
  2. नीचे दिए गए ट्रेस यूज़र इंटरफ़ेस (यूआई) सेशन में, 500 स्टेटस कोड दिखाया गया है. यह कोड, सेवा कॉलआउट नीति में किसी गड़बड़ी की वजह से बना है:

  3. इस उदाहरण में, "गड़बड़ी" प्रॉपर्टी, सेवा कॉलआउट नीति की गड़बड़ी "ResponseCode 404 को गड़बड़ी के तौर पर मानी जाती है" की वजह बताती है. यह गड़बड़ी तब हो सकती है, जब सेवा कॉलआउट की नीति में, बैकएंड सर्वर यूआरएल से ऐक्सेस किया जा रहा संसाधन उपलब्ध न हो.
  4. बैकएंड सर्वर पर देखें कि संसाधन उपलब्ध है या नहीं. हो सकता है कि यह कुछ समय के लिए/हमेशा के लिए उपलब्ध न हो या इसे किसी दूसरी जगह भेज दिया गया हो.

उदाहरण 1 रिज़ॉल्यूशन

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

उदाहरण 2: वैरिएबल निकालने की नीति में गड़बड़ी

आइए अब एक और उदाहरण देखते हैं, जहां 'वैरिएबल एक्सट्रैक्ट करें' नीति में किसी गड़बड़ी की वजह से 500 सर्वर में गड़बड़ी होती है और हम इस समस्या को हल करने का तरीका जानते हैं.

  1. यूज़र इंटरफ़ेस (यूआई) सेशन में यह ट्रेस, वैरिएबल एक्सट्रैक्ट करने की नीति में हुई किसी गड़बड़ी की वजह से 500 स्टेटस कोड दिखाता है:

  2. काम न करने वाले वैरिएबल एक्सट्रैक्ट करने के लिए बनी नीति चुनें. नीचे स्क्रोल करें और ज़्यादा जानकारी के लिए "गड़बड़ी कॉन्टेंट" सेक्शन देखें:

  3. गड़बड़ी वाला कॉन्टेंट बताता है कि वैरिएबल एक्सट्रैक्ट करने की नीति में "serviceकॉलआउट.oamCookie खबरResponse" वैरिएबल उपलब्ध नहीं है. वैरिएबल के नाम से पता चलता है कि इसमें पिछली सेवा कॉलआउट नीति का रिस्पॉन्स मौजूद होना चाहिए.
  4. ट्रेस में सेवा कॉलआउट की नीति चुनने पर, हो सकता है कि आपको यह दिखे कि "serviceCallout.oamCookieValidationResponse" वैरिएबल को सेट नहीं किया गया था. इससे पता चलता है कि बैकएंड सेवा को कॉल नहीं किया जा सका, जिसकी वजह से रिस्पॉन्स वैरिएबल खाली हो गया है.
  5. हालांकि, सेवा कॉलआउट की नीति लागू नहीं हो सकी, लेकिन सेवा कॉलआउट की नीति के बाद नीतियों का पालन जारी है, क्योंकि सेवा की कॉलआउट नीति में "ContinueOnError" फ़्लैग को 'सही' पर सेट किया गया, जैसा कि यहां दिखाया गया है:

    <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
  <DisplayName>Callout.OamCookieValidation</DisplayName>
  <Properties />
  <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  </Request>
  <Response>serviceCallout.oamCookieValidationResponse</Response>
  <HTTPTargetConnection>
    <Properties />
    <URL>http://{Url}</URL>
  </HTTPTargetConnection>
</ServiceCallout>
  6. ट्रेस से इस खास एपीआई अनुरोध के लिए, यूनीक मैसेज आईडी "X-Apigee.Message-ID" को इस तरह नोट करें:
    1. अनुरोध से, "Analytics डेटा रिकॉर्ड किया गया" चरण चुनें.
    2. नीचे की ओर स्क्रोल करें और X-Apigee.Message-ID की वैल्यू नोट करें.

  7. मैसेज प्रोसेसर लॉग (/opt/apigee/var/log/edge-message-processor/system.log) देखें और चरण #6 में नीचे बताए गए यूनीक मैसेज आईडी को खोजें. किसी खास एपीआई अनुरोध के लिए, गड़बड़ी का यह मैसेज मिला है: 
    2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX

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

  8. कनेक्शन के टाइम आउट होने की गड़बड़ी की वजह का पता लगाने के लिए, मैसेज प्रोसेसर से बैकएंड सर्वर पर टेलनेट कमांड लागू किया गया. टेलनेट निर्देश ने "कनेक्शन का समय खत्म हो गया" गड़बड़ी दी थी, जैसा कि यहां दिखाया गया है: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out

    आम तौर पर, यह गड़बड़ी इन स्थितियों में दिखती है:

    • जब बैकएंड सर्वर को Edge Message प्रोसेसर से ट्रैफ़िक की अनुमति देने के लिए कॉन्फ़िगर नहीं किया गया हो.
    • अगर बैकएंड सर्वर किसी खास पोर्ट पर जवाब नहीं दे रहा हो.

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

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

उदाहरण 2 रिज़ॉल्यूशन

  1. एक्सट्रैक्ट वैरिएबल नीति में गड़बड़ी या गड़बड़ी की वजह को सही तरीके से ठीक करें.
  2. ऊपर दिए गए उदाहरण में बताया गया है कि नेटवर्क कॉन्फ़िगरेशन में सुधार किया जाना चाहिए, ताकि Edge Message प्रोसेसर से आने वाले ट्रैफ़िक को आपके बैकएंड सर्वर पर भेजा जा सके. ऐसा करने के लिए, Message प्रोसेसर के आईपी पतों को खास बैकएंड सर्वर पर अनुमति वाली सूची में शामिल किया गया. उदाहरण के लिए, Linux पर, बैकएंड सर्वर पर Message प्रोसेसर के आईपी पतों से आने वाले ट्रैफ़िक की अनुमति देने के लिए, iptables का इस्तेमाल किया जा सकता है.

उदाहरण 3: Javaकॉलआउट नीति में विफलता

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

  1. नीचे दिया गया यूज़र इंटरफ़ेस (यूआई) ट्रेस, Java की कॉलआउट नीति में हुई किसी गड़बड़ी की वजह से 500 स्टेटस कोड दिखाता है:

  2. नीचे दिए गए चित्र में दिखाए गए तरीके से गड़बड़ियों के बारे में जानकारी पाने के लिए, "गड़बड़ी" नाम के फ़्लो को चुनें और उसके बाद, सफल नहीं हुई Java कॉलआउट नीति चुनें:

  3. इस उदाहरण में, प्रॉपर्टी सेक्शन में मौजूद "error" प्रॉपर्टी से पता चलता है कि Java कॉलआउट नीति के तहत, Oracle डेटाबेस से कनेक्ट करते समय इस्तेमाल किए गए पासवर्ड की समयसीमा खत्म हो जाने की वजह से गड़बड़ी हुई. आपका Java कॉलआउट अलग तरीके से काम करेगा और गड़बड़ी प्रॉपर्टी में एक अलग मैसेज दिखाएगा.
  4. Javaकॉलआउट नीति कोड की जांच करें और इस्तेमाल किए जाने वाले सही कॉन्फ़िगरेशन की पुष्टि करें.

उदाहरण 3 रिज़ॉल्यूशन

रनटाइम अपवाद से बचने के लिए, Java कॉलआउट कोड या कॉन्फ़िगरेशन को सही तरीके से ठीक करें. ऊपर दिए गए उदाहरण में, Java कॉलआउट की गड़बड़ी का उदाहरण दिया गया है, जिसमें Oracle डेटाबेस से कनेक्ट करने के लिए, समस्या को हल करने के लिए सही पासवर्ड का इस्तेमाल करना होगा.

बैकएंड सर्वर में गड़बड़ी

500 सर्वर में गड़बड़ी वाली गड़बड़ी, बैकएंड सर्वर से भी शुरू हो सकती है. इस सेक्शन में, बैकएंड सर्वर से गड़बड़ी आने पर, समस्या को हल करने का तरीका बताया गया है.

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

सभी उपयोगकर्ताओं के लिए डाइग्नोस्टिक के चरण

अन्य बैकएंड गड़बड़ियों की वजहें काफ़ी अलग हो सकती हैं. आपको हर स्थिति का अलग-अलग विश्लेषण करना होगा.

  1. पुष्टि करें कि बैकएंड सर्वर की वजह से गड़बड़ी हुई थी. ज़्यादा जानकारी के लिए, समस्या की वजह का पता लगाना देखें.
  2. अगर बैकएंड सर्वर की वजह से गड़बड़ी हुई थी, तो जारी रखें. अगर नीति को लागू करने के दौरान गड़बड़ी होती है, तो Edge की नीति में एक्ज़ीक्यूशन एरर पर जाएं.
  3. आपके पास, काम न कर रहे एपीआई के लिए ट्रेस सेशन का ऐक्सेस है या नहीं, या बैकएंड, Node.js सर्वर है या नहीं, इसके आधार पर नीचे दिया गया तरीका अपनाएं:

अगर आपके पास पूरे न हो पाने वाले एपीआई कॉल के लिए ट्रेस सेशन नहीं है:

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

अगर आपके पास पूरे न होने वाले एपीआई कॉल के लिए ट्रेस सेशन है, तो:

अगर आपका ट्रेस सेशन होता है, तो नीचे दिए गए तरीके अपनाकर समस्या का पता लगाया जा सकता है.

  1. ट्रेस टूल में, वह एपीआई अनुरोध चुनें जो 500 Internal Server की गड़बड़ी के साथ फ़ेल हो गया हो.
  2. नीचे दिए गए चित्र के मुताबिक काम न करने वाले एपीआई अनुरोध से "टारगेट सर्वर से मिला रिस्पॉन्स" फ़ेज़ को चुनें:

  3. गड़बड़ी के बारे में जानकारी पाने के लिए, "जवाब का कॉन्टेंट" सेक्शन देखें.

  4. इस उदाहरण में, रिस्पॉन्स कॉन्टेंट जो कि SOAP एन्वेलप है, गड़बड़ी वाली स्ट्रिंग को "Authorized नहीं" मैसेज के तौर पर दिखाता है. इस समस्या की सबसे आम वजह यह है कि उपयोगकर्ता ने बैकएंड सर्वर पर सही क्रेडेंशियल (उपयोगकर्ता नाम/पासवर्ड, ऐक्सेस टोकन वगैरह) पास नहीं किए. इस समस्या को ठीक करने के लिए, बैकएंड सर्वर पर सही क्रेडेंशियल भेजे जा सकते हैं.

अगर बैकएंड एक Node.js सर्वर है, तो:

  1. अगर बैकएंड एक Node.js बैकएंड सर्वर है, तो Edge यूज़र इंटरफ़ेस (यूआई) में खास एपीआई प्रॉक्सी के लिए Node.js लॉग देखें (सार्वजनिक और निजी क्लाउड, दोनों के उपयोगकर्ता Node.js लॉग देख सकते हैं). अगर आप Edge Private Cloud के उपयोगकर्ता हैं, तो गड़बड़ी के बारे में ज़्यादा जानकारी के लिए, Message प्रोसेसर के लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log) भी देखे जा सकते हैं.

    Edge के यूज़र इंटरफ़ेस (यूआई) में NodeJS लॉग विकल्प - एपीआई प्रॉक्सी की खास जानकारी देने वाला टैब

रिज़ॉल्यूशन

  1. गड़बड़ी की वजह पता चलने के बाद, अपने बैकएंड सर्वर में समस्या को ठीक करें.
  2. अगर यह Node.js बैकएंड सर्वर है, तो:
    1. देखें कि कहीं आपके कस्टम कोड में गड़बड़ी तो नहीं है. अगर हो सके, तो समस्या को ठीक करें.
    2. अगर आपके कस्टम कोड से गड़बड़ी नहीं दिखती है या आपको मदद चाहिए, तो Apigee सहायता से संपर्क करें.

अगर आपको '500 इंटरनल सर्वर एरर' की समस्या हल करने के लिए और मदद चाहिए या आपको लगता है कि यह Edge में कोई समस्या है, तो Apigee की सहायता टीम से संपर्क करें.

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

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

यूज़र इंटरफ़ेस (यूआई) में Trace का इस्तेमाल करना

ध्यान दें: इस सेक्शन में दिए गए चरणों को, सार्वजनिक और प्राइवेट क्लाउड, दोनों तरह के उपयोगकर्ता पूरे कर सकते हैं.

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

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

ध्यान दें: इस सेक्शन में दिए गए चरणों को, सिर्फ़ Public Cloud के उपयोगकर्ता ही पूरा कर सकते हैं.

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

उदाहरण के तौर पर दिए गए उदाहरण को देखें. इसमें, एपीआई मॉनिटरिंग का इस्तेमाल करके, अपने एपीआई की 5xx समस्याओं को हल करने का तरीका बताया गया है. उदाहरण के लिए, हो सकता है कि आप 500 स्टेटस कोड या steps.servicecallout.ExecutionFailed गड़बड़ियों की संख्या किसी खास थ्रेशोल्ड से ज़्यादा होने पर सूचना पाने के लिए, एक सूचना सेट अप करना चाहें.

NGINX ऐक्सेस लॉग का इस्तेमाल करना

ध्यान दें: इस सेक्शन में दिया गया चरण सिर्फ़ Edge प्राइवेट क्लाउड का इस्तेमाल करने वालों के लिए है.

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

  1. NGINX के ऐक्सेस लॉग (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ) देखें.
  2. तय करें कि किसी खास समय पर किसी खास एपीआई प्रॉक्सी के लिए 500 गड़बड़ियां हैं या नहीं.
  3. अगर कोई 500 गड़बड़ियां हैं, तो देखें कि यह गड़बड़ी नीति है या टारगेट सर्वर की गड़बड़ी है, जैसा कि नीचे दिखाया गया है:

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

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

  4. जब आप यह पता लगाएं कि यह नीति के उल्लंघन या टारगेट सर्वर की गड़बड़ी है, तो:
    1. अगर नीति से जुड़ी कोई गड़बड़ी है, तो Edge नीति में एक्ज़ीक्यूट करने में गड़बड़ी पर जाएं.
    2. अगर यह टारगेट सर्वर में गड़बड़ी है, तो बैकएंड सर्वर में गड़बड़ी पर जाएं.