मानक गड़बड़ी जवाब
मैनेजमेंट एपीआई का अनुरोध स्वीकार होने पर, एपीआई 200
स्टेटस कोड दिखाता है. अगर किसी अनुरोध में कोई गड़बड़ी होती है, तो एपीआई गड़बड़ी के टाइप के आधार पर रिस्पॉन्स में एक एचटीटीपी स्टेटस कोड, स्टेटस, और वजह दिखाता है.
इसके अलावा, जवाब के मुख्य हिस्से में गड़बड़ी की वजह
की पूरी जानकारी शामिल होती है. यहां गड़बड़ी के जवाब का उदाहरण दिया गया है:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "invalidParameter",
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]",
"locationType": "parameter",
"location": "max-results"
}
],
"code": 400,
"message": "Invalid value '-1' for max-results. Value must be within the range: [1, 1000]"
}
}
गड़बड़ी की टेबल
कोड | वजह | ब्यौरा | सुझाई गई कार्रवाई |
---|---|---|---|
400 | invalidParameter |
इससे पता चलता है कि अनुरोध पैरामीटर में अमान्य वैल्यू शामिल है. गड़बड़ी के जवाब में locationType और location फ़ील्ड से जानकारी मिलती है कि कौनसा मान अमान्य था. |
समस्या को ठीक किए बिना फिर से कोशिश न करें. गड़बड़ी के जवाब में बताए गए पैरामीटर के लिए आपको एक मान्य वैल्यू देनी होगी. |
400 | badRequest |
इससे पता चलता है कि क्वेरी अमान्य थी. उदाहरण के लिए, पैरंट आईडी मौजूद नहीं था या डाइमेंशन या मेट्रिक का अनुरोध मान्य नहीं था. | समस्या को ठीक किए बिना फिर से कोशिश न करें. एपीआई क्वेरी के काम करने के लिए आपको उसमें बदलाव करने होंगे. |
401 | invalidCredentials |
इससे पता चलता है कि पुष्टि करने वाला टोकन अमान्य है या इसकी समयसीमा खत्म हो गई है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. आपको पुष्टि करने वाला नया टोकन लेना होगा. |
403 | insufficientPermissions |
इससे पता चलता है कि उपयोगकर्ता के पास, क्वेरी में बताई गई इकाई के लिए ज़रूरी अनुमतियां नहीं हैं. | समस्या को ठीक किए बिना फिर से कोशिश न करें. किसी खास इकाई पर कार्रवाई करने के लिए, आपके पास ज़रूरी अनुमतियां होनी चाहिए. |
403 | dailyLimitExceeded |
इससे पता चलता है कि उपयोगकर्ता ने हर प्रोजेक्ट के लिए या हर व्यू (प्रोफ़ाइल) के लिए तय की गई सीमा को पार कर लिया है. | समस्या को ठीक किए बिना फिर से कोशिश न करें. आप हर दिन के लिए तय की गई सीमा का इस्तेमाल कर चुके हैं. एपीआई की सीमाएं और कोटा देखें. |
403 | userRateLimitExceeded |
इससे पता चलता है कि हर उपयोगकर्ता के हिसाब से, 100 सेकंड में क्वेरी करने की सीमा पार हो गई है. Google API कंसोल में डिफ़ॉल्ट रूप से, हर उपयोगकर्ता के हिसाब से हर 100 सेकंड में 100 क्वेरी सेट की जाती हैं. Google API कंसोल में इस सीमा को बढ़ाकर 1,000 तक किया जा सकता है. | एक्स्पोनेंशियल बैक-ऑफ़ सुविधा का इस्तेमाल करके, फिर से कोशिश करें. आपको अनुरोध भेजने की दर कम करनी होगी. |
403 | rateLimitExceeded |
इससे पता चलता है कि प्रोजेक्ट के लिए, हर 100 सेकंड में क्वेरी करने की दर की सीमा पार हो गई है. | एक्स्पोनेंशियल बैक-ऑफ़ सुविधा का इस्तेमाल करके, फिर से कोशिश करें. आपको अनुरोध भेजने की दर कम करनी होगी. |
403 | quotaExceeded |
यह बताता है कि Core Reporting API में हर व्यू (प्रोफ़ाइल) के लिए, एक साथ 10 अनुरोध किए जा चुके हैं. | एक्सपोनेन्शियल बैक-ऑफ़ का इस्तेमाल करके फिर से कोशिश करें. आपको इस व्यू (प्रोफ़ाइल) के लिए, कम से कम एक अनुरोध जारी होने तक इंतज़ार करना होगा. |
500 | internalServerError |
सर्वर में अचानक कोई गड़बड़ी हुई. | इस क्वेरी को एक से ज़्यादा बार फिर से न आज़माएं. |
503 | backendError |
सर्वर ने कोई गड़बड़ी दिखाई है. | इस क्वेरी को एक से ज़्यादा बार फिर से न आज़माएं. |
500 या 503 जवाबों को मैनेज करना
बहुत ज़्यादा लोड होने के दौरान या ज़्यादा मुश्किल अनुरोधों की वजह से, 500
या 503
गड़बड़ी हो सकती है. बड़े अनुरोधों के लिए, कम अवधि के डेटा का अनुरोध करें. एक्स्पोनेंशियल बैकऑफ़ लागू करने के बारे में भी सोचें.
इन गड़बड़ियों की फ़्रीक्वेंसी, व्यू (प्रोफ़ाइल) और उस व्यू से जुड़े रिपोर्टिंग डेटा की रकम पर निर्भर हो सकती है. यह ज़रूरी नहीं है कि अगर किसी क्वेरी की वजह से एक व्यू (प्रोफ़ाइल) में 500
या 503
गड़बड़ी हो, तो ज़रूरी नहीं है कि उस क्वेरी के लिए अलग व्यू (प्रोफ़ाइल) वाली क्वेरी में गड़बड़ी दिखे.
एक्सपोनेन्शियल बैकऑफ़ लागू करना
एक्सपोनेंशियल बैकऑफ़ एक ऐसी प्रोसेस है जिसमें कोई क्लाइंट, समय-समय पर फ़ेल हो चुके अनुरोध को बार-बार प्रोसेस करने की कोशिश करता है. यह नेटवर्क ऐप्लिकेशन के लिए, गड़बड़ियों को मैनेज करने की मानक रणनीति है. मैनेजमेंट एपीआई को इस उम्मीद को ध्यान में रखकर डिज़ाइन किया गया है कि जो क्लाइंट पूरे न होने वाले अनुरोधों के लिए फिर से कोशिश करते हैं वे ऐसा एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करके करते हैं. एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करने के साथ-साथ, "ज़रूरी" होने के अलावा, बैंडविथ के इस्तेमाल को बेहतर तरीके से किया जा सकता है. यह कामयाब रिस्पॉन्स पाने के लिए ज़रूरी अनुरोधों की संख्या कम करता है और एक साथ काम करने वाली जगहों पर अनुरोधों की संख्या बढ़ाता है.
सिंपल एक्स्पोनेंशियल बैकऑफ़ को लागू करने का फ़्लो नीचे दिया गया है.
- एपीआई से अनुरोध करें
- कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
- 1 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
- 2 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
- 4 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
- 8 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
- 16 सेकंड +
random_number_milliseconds
सेकंड इंतज़ार करें - फिर से अनुरोध करें
- अगर आपको अब भी गड़बड़ी का कोई मैसेज मिलता है, तो उसे रोककर उसकी जानकारी डालें.
ऊपर दिए गए फ़्लो में, random_number_milliseconds
, 1,000 से कम या उसके बराबर मिलीसेकंड की एक रैंडम संख्या है. यह ज़रूरी है,
ताकि एक साथ लागू किए जाने वाले कुछ बदलावों को लॉक करने से जुड़ी कुछ गड़बड़ियों से बचा जा सके.
हर इंतज़ार के बाद, random_number_milliseconds
को फिर से तय करना होगा.
ध्यान दें: इंतज़ार हमेशा
(2 ^ n) + random_number_milliseconds
होता है, जहां
n एक बार में 0 के तौर पर तय किया गया एक पूर्णांक से बढ़ने वाला पूर्णांक होता है. हर अनुरोध (हर अनुरोध) के लिए, n को 1 से बढ़ाया जाता है.
n 5 के होने पर एल्गोरिदम खत्म हो जाता है. यह सीमा सिर्फ़ इसलिए बनाई गई है, ताकि क्लाइंट किसी समस्या को हल करने की कोशिश बार-बार न कर पाएं. इस वजह से, अनुरोध को "ठीक नहीं की जा सकने वाली गड़बड़ी" के तौर पर माने जाने में, करीब 32 सेकंड लग सकते हैं.
नीचे दिया गया Python कोड, ऊपर दिए गए फ़्लो को लागू करता है. इससे, makeRequest
नाम के तरीके से होने वाली गड़बड़ियों को ठीक किया जा सकता है.
import random import time from apiclient.errors import HttpError def makeRequestWithExponentialBackoff(analytics): """Wrapper to request Google Analytics data with exponential backoff. The makeRequest method accepts the analytics service object, makes API requests and returns the response. If any error occurs, the makeRequest method is retried using exponential backoff. Args: analytics: The analytics service object Returns: The API response from the makeRequest method. """ for n in range(0, 5): try: return makeRequest(analytics) except HttpError, error: if error.resp.reason in ['userRateLimitExceeded', 'quotaExceeded', 'internalServerError', 'backendError']: time.sleep((2 ** n) + random.random()) else: break print "There has been an error, the request never succeeded."