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

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

वीडियो

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 में, गड़बड़ी की वजहों को दो मुख्य कैटगरी में बांटा जा सकता है. यह बंटवारा, गड़बड़ी होने की जगह के आधार पर किया जाता है:

Edge की किसी नीति को लागू करते समय होने वाली गड़बड़ी

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

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

Private और Public Cloud के उपयोगकर्ताओं के लिए, गड़बड़ी का पता लगाने के तरीके

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

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

सिर्फ़ Private Cloud के उपयोगकर्ताओं के लिए, गड़बड़ी का पता लगाने के तरीके

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

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

रिज़ॉल्यूशन

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

यहां दिए गए उदाहरणों से, अलग-अलग तरह की समस्याओं की वजह और उन्हें ठीक करने का तरीका समझने में मदद मिलेगी.

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

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

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

पहले उदाहरण का समाधान

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

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

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

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

   

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

   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 कमांड से, "कनेक्शन टाइम आउट" गड़बड़ी हुई. यह जानकारी यहां दिखाई गई है:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out

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

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

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

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

दूसरे उदाहरण का समाधान

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

तीसरा उदाहरण: JavaCallout नीति में गड़बड़ी

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

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

   

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

   

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

तीसरे उदाहरण का समाधान

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

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

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

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

सभी उपयोगकर्ताओं के लिए, गड़बड़ी का पता लगाने के तरीके

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

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

अगर आपके पास एपीआई कॉल के उस अनुरोध के लिए ट्रेस सेशन नहीं है जो काम नहीं कर पाया:

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

अगर आपके पास एपीआई कॉल के उस अनुरोध के लिए ट्रेस सेशन है जो काम नहीं कर पाया:

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

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

   

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

   

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

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

1. अगर बैकएंड, Node.js बैकएंड सर्वर है, तो Edge के यूज़र इंटरफ़ेस (यूआई) में, एपीआई प्रॉक्सी के लिए Node.js के लॉग देखें. (Public और Private Cloud, दोनों के उपयोगकर्ता 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: सर्वर में गड़बड़ी, एपीआई प्रॉक्सी में किसी नीति को लागू करते समय हुई है या बैकएंड सर्वर की वजह से, इनमें से कोई एक तरीका अपनाएं.

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

ध्यान दें: इस सेक्शन में दिए गए तरीके, Public और Private Cloud, दोनों के उपयोगकर्ता अपना सकते हैं.

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

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

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

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

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

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

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

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. अगर गड़बड़ी, टारगेट सर्वर की वजह से हुई है, तो बैकएंड सर्वर में गड़बड़ी पर जाएं.