गड़बड़ियों के जवाब

मानक गड़बड़ी जवाब

मैनेजमेंट एपीआई का अनुरोध स्वीकार होने पर, एपीआई 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. एपीआई से अनुरोध करें
  2. कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
  3. 1 सेकंड + random_number_milliseconds सेकंड इंतज़ार करें
  4. फिर से अनुरोध करें
  5. कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
  6. 2 सेकंड + random_number_milliseconds सेकंड इंतज़ार करें
  7. फिर से अनुरोध करें
  8. कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
  9. 4 सेकंड + random_number_milliseconds सेकंड इंतज़ार करें
  10. फिर से अनुरोध करें
  11. कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
  12. 8 सेकंड + random_number_milliseconds सेकंड इंतज़ार करें
  13. फिर से अनुरोध करें
  14. कोई ऐसी गड़बड़ी का रिस्पॉन्स मिलना जिसमें कोई ऐसा गड़बड़ी कोड हो जिसे फिर से कोशिश किया जा सके
  15. 16 सेकंड + random_number_milliseconds सेकंड इंतज़ार करें
  16. फिर से अनुरोध करें
  17. अगर आपको अब भी गड़बड़ी का कोई मैसेज मिलता है, तो उसे रोककर उसकी जानकारी डालें.

ऊपर दिए गए फ़्लो में, 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."