गड़बड़ी के जवाब

गड़बड़ी के स्टैंडर्ड रिस्पॉन्स

अगर मल्टी चैनल फ़नल रिपोर्टिंग एपीआई अनुरोध पूरा हो जाता है, तो एपीआई एक 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	इससे पता चलता है कि कोर रिपोर्टिंग एपीआई में, हर व्यू (प्रोफ़ाइल) के लिए एक साथ 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."