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

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

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

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

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

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

    अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है 
    <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. इस एपीआई के लिए यूनीक मैसेज आईडी &quot;X-Apigee.Message-ID&quot; को नोट करें ट्रेस से अनुरोध इस तरह करें:
    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 कमांड, मैसेज प्रोसेसर से बैकएंड सर्वर को भेजता है. टेलनेट निर्देश दिया गया "कनेक्शन का समय खत्म" गड़बड़ी देखें, जैसा कि नीचे दिखाया गया है: 
    telnet mybackend.domain.com 443
Trying XX.XX.XX.XX...
telnet: connect to address XX.XX.XX.XX: Connection timed out
    अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

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

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

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

उदाहरण 3: Javaकॉलआउट नीति में गड़बड़ी

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

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

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

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

रिज़ॉल्यूशन का तीसरा उदाहरण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रिज़ॉल्यूशन

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

अगर आपको 500 सर्वर में हुई गड़बड़ी को ठीक करने में और मदद चाहिए या आपको शक है Edge में कोई समस्या है, तो Apigee से संपर्क करें सहायता.

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

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

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

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

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

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

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

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

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

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

ध्यान दें: इस सेक्शन में बताया गया तरीका, EDGE प्राइवेट क्लाउड के उपयोगकर्ताओं के लिए है सिर्फ़.

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

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

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

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

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