Google Home Vitals (Cloud)

डैशबोर्ड और चेतावनियों का यह सुइट, Google Home के इकोसिस्टम के साथ अच्छी क्वालिटी का इंटिग्रेशन बनाए रखने में आपकी मदद करता है. Google, सभी ग्राहकों के लिए अच्छी क्वालिटी का इकोसिस्टम तैयार करने में पार्टनर की मदद करने के लिए प्रतिबद्ध है

डैशबोर्ड में तीन सेक्शन होते हैं. हर सेक्शन में, इंटिग्रेशन की क्वालिटी को बेहतर बनाने में मदद करने वाले अहम हिस्से के बारे में जानकारी दी जाती है.

1. Google से पार्टनर के लिए मेट्रिक - इससे यह पता चलता है कि Google से आपके क्लाउड बैकएंड पर किए जाने वाले कॉल की क्वालिटी कैसी है.

2. सिस्टम की क्वालिटी - पार्टनर से Google के लिए मेट्रिक - इससे यह पता चलता है कि आपके सिस्टम से Google पर किए जाने वाले कॉल की क्वालिटी कैसी है.

3. डिवाइस की क्वालिटी - डिवाइस की स्थिति की सटीक जानकारी - इससे Google के सिस्टम में सेव की गई स्थितियों की सटीक जानकारी मिलती है. इनका इस्तेमाल, उपयोगकर्ता की क्वेरी के जवाब देने के लिए किया जाता है.

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

अगर नीचे दिया गया बटन आपको सीधे डैशबोर्ड पर नहीं ले जाता है, तो खास जानकारी पेज को चुनकर डैशबोर्ड पर जाया जा सकता है. इसके बाद, डैशबोर्ड को चुनें. फिर, मेरे डैशबोर्ड की सूची में जाकर, Google Home Vitals Dashboard (Cloud) को चुनें. इससे आपको अपना डैशबोर्ड दिखेगा.

डैशबोर्ड पर जाएं

Google से पार्टनर के लिए मेट्रिक

क्वेरी/कार्रवाई पूरी होने की दर >= 99.5% मेट्रिक से यह पता चलता है कि उपयोगकर्ताओं के निर्देश कितनी बार सही तरीके से पूरे किए जाते हैं. इससे Assistant के ऐसे जवाबों से बचा जा सकता है, जैसे कि "मैं डिवाइस से कनेक्ट नहीं हो पा रहा/रही हूं" या ऐसे निर्देश की गलत तरीके से पुष्टि करना जो पूरा नहीं हुआ है.

"कार्रवाई पूरी हुई" का क्या मतलब है?

किसी ट्रांज़ैक्शन को 'कार्रवाई पूरी हुई' के तौर पर मार्क तब किया जाता है, जब Google Home प्लैटफ़ॉर्म को कोई मान्य जवाब मिलता है. इससे यह पता चलता है कि तय की गई कार्रवाई पूरी हो गई है या अनुरोधित स्थिति वापस मिल गई है.

ऐसे जवाब जिनमें नॉन-ब्लॉकिंग अपवाद शामिल होते हैं (उदाहरण के लिए, SUCCESS स्टेटस के साथ lowBattery अपवाद), उन्हें 'कार्रवाई पूरी हुई' के तौर पर गिना जाता है. चेतावनी के बावजूद, निर्देश डिवाइस तक पहुंच गया और मकसद पूरा हो गया.

"कार्रवाई पूरी नहीं हुई" का क्या मतलब है?

QUERY और EXECUTE की दरें तय करते समय, Common platform error codes पर मिली गड़बड़ियों को "कार्रवाई पूरी नहीं हुई" माना जाता है. इन गड़बड़ियों को पार्टनर के लिए कार्रवाई ज़रूरी है के तौर पर मार्क किया जाता है. इसके अलावा, Errors and exeptions पर मिली गड़बड़ियों को भी "कार्रवाई पूरी नहीं हुई" माना जाता है. हालांकि, इनके लिए ये अपवाद लागू होते हैं:

कार्रवाई पूरी न होने के अपवाद
aboveMaximumLightEffectsDuration	armLevelNeeded	inOffMode
alreadyArmed	bagFull	lockedToRange
alreadyAtMax	belowMinimumLightEffectsDuration	lowBattery
alreadyAtMin	binFull	maxSpeedReached
alreadyClosed	cancelArmingRestricted	minSpeedReached
alreadyDisarmed	deadBattery	notSupported
alreadyDocked	degreesOutOfRange	offline
alreadyInState	deviceJammingDetected	percentOutOfRange
alreadyLocked	deviceNotMounted	rangeTooClose
alreadyOff	deviceNotReady	remoteSetDisabled
alreadyOn	deviceOffline	safetyShutOff
alreadyOpen	deviceTurnedOff	targetAlreadyReached
alreadyPaused	discreteOnlyOpenClose	tooManyFailedAttempts
alreadyStarted	functionNotSupported	valueOutOfRange
alreadyStopped	inAutoMode
alreadyUnlocked	inEcoMode

क्वेरी/कार्रवाई के लिए इंतज़ार का समय (p90) <= 1000 मिसेकंड मेट्रिक से, अनुरोध की गई कार्रवाई के लिए इंतज़ार के समय का पता चलता है. इससे यह पक्का करने में मदद मिलती है कि उपयोगकर्ताओं को ज़्यादा इंतज़ार न करना पड़े. उदाहरण के लिए, लाइट बंद होने के लिए कुछ सेकंड इंतज़ार करना.

इंतज़ार के समय की मेट्रिक

इंतज़ार का समय, यह जानने का अहम इंडिकेटर है कि आपका इंटिग्रेशन, एंड-यूज़र के लिए कितना रिस्पॉन्सिव है. डैशबोर्ड, 90वें पर्सेंटाइल (P90) के इंतज़ार के समय को ट्रैक करता है. इससे आपके "सबसे धीमे" उपयोगकर्ताओं के अनुभव के बारे में पता चलता है. उदाहरण के लिए, P90 का 800 मिसेकंड का मतलब है कि 90% अनुरोधों को 800 मिसेकंड या उससे कम समय में स्वीकार किया जाता है.

Google, तकनीकी तौर पर सटीक जानकारी देने के लिए, स्टेटस की जांच और डिवाइस के निर्देशों के लिए, इंतज़ार के समय को अलग-अलग तरीके से मापता है.

1. क्वेरी के लिए इंतज़ार का समय (पूछताछ)

इससे, Cloud-to-cloud राउंड ट्रिप टाइम का पता चलता है. यह तब होता है, जब Google किसी डिवाइस की मौजूदा स्थिति के बारे में पूछता है .

• शुरुआत: Google, आपके फ़ुलफ़िलमेंट यूआरएल पर action.devices.QUERY अनुरोध भेजता है.
• मेज़रमेंट विंडो: आपके क्लाउड को पूरा एचटीटीपी रिस्पॉन्स पाने, प्रोसेस करने, और वापस Google को भेजने में लगने वाला समय.
• खत्म होने का समय: Google को आपकी सेवा से, फ़ाइनल रिस्पॉन्स पेलोड मिलता है और वह उसे स्वीकार करता है.

2. कार्रवाई के लिए इंतज़ार का समय (कार्रवाई)

इससे, निर्देश को स्वीकार करने में लगने वाले समय का पता चलता है. यह तब होता है, जब Google किसी डिवाइस को कंट्रोल करने का अनुरोध भेजता है.

• शुरुआत: Google, आपके फ़ुलफ़िलमेंट यूआरएल पर action.devices.EXECUTE अनुरोध भेजता है.
• मेज़रमेंट विंडो: आपके क्लाउड को निर्देश पाने और उसे स्वीकार करने का जवाब देने में लगने वाला समय.
• खत्म होने का समय: Google को SUCCESS, PENDING या OFFLINE स्टेटस का जवाब मिलता है.
• तकनीकी दायरा: इस मेट्रिक से, Google के क्लाउड और आपके क्लाउड के बीच "रिस्पॉन्स को स्वीकार करने" में लगने वाले समय का पता चलता है. इससे, फ़िज़िकल हार्डवेयर (उदाहरण के लिए, लाइट बल्ब) को फ़िज़िकल स्टेटस में बदलाव करने में लगने वाले समय का पता नहीं चलता. ऐसा इसलिए, क्योंकि इसमें अक्सर क्लाउड-टू-क्लाउड पाथ के बाहर, लोकल मेश नेटवर्क के इंतज़ार का समय शामिल होता है.

इंतज़ार का समय कम करने के विकल्प

जियो-राउटिंग के लिए आर्किटेक्चर से जुड़े सुझाव

अगर Anycast IP को लागू करना मुमकिन नहीं है, तो हमारा सुझाव है कि लागत के हिसाब से फ़ायदेमंद इन विकल्पों का इस्तेमाल किया जाए. इससे यह पक्का किया जा सकेगा कि उपयोगकर्ताओं को उनके सबसे नज़दीकी रीजनल डेटा सेंटर से सेवा मिले.

1. ग्लोबल लोड बैलेंसिंग (जीएलबी)

   स्टैटिक राउटिंग के बजाय, ग्लोबल ऐप्लिकेशन लोड बैलेंसर का इस्तेमाल करें. यह ज़्यादातर बड़े क्लाउड प्रोवाइडर से उपलब्ध है.

   • यह कैसे काम करता है: आपको एक ग्लोबल एंट्री पॉइंट (यूआरएल) कॉन्फ़िगर करना होता है, जो नेटवर्क एज पर मौजूद होता है. लोड बैलेंसर, Google के फ़ुलफ़िलमेंट क्लस्टर से मिले अनुरोध के भौगोलिक मूल का पता अपने-आप लगा लेता है. साथ ही, ट्रैफ़िक को आपके सबसे नज़दीकी रीजनल और सही तरीके से काम कर रहे बैकएंड पर भेज देता है.

   • फ़ायदा: इससे Anycast की परफ़ॉर्मेंस मिलती है. साथ ही, इसे कॉन्फ़िगर करने में कम समय लगता है और यह सस्ता भी है.

2. जियो-लोकेशन अवेयर डीएनएस (जियोडीएनएस)

   • यह कैसे काम करता है: अपने डीएनएस प्रोवाइडर को कॉन्फ़िगर करें, ताकि वह डीएनएस क्वेरी की भौगोलिक जगह के हिसाब से, आपके फ़ुलफ़िलमेंट यूआरएल को अलग-अलग आईपी पतों पर रिज़ॉल्व करे.

   • लागू करना: पक्का करें कि आपका डीएनएस प्रोवाइडर, Google के इग्रेस पॉइंट के लिए ऑप्टिमाइज़ किया गया हो. जब Google की रीजनल फ़ुलफ़िलमेंट सेवाएं (उदाहरण के लिए, अमेरिका, यूरोपीय संघ या एशिया में), आपके डोमेन को रिज़ॉल्व करती हैं, तो उन्हें उस खास इलाके में मौजूद डेटा सेंटर का आईपी पता मिलता है.

ऐप्लिकेशन लेयर पर ऑप्टिमाइज़ेशन की रणनीतियां

इन्फ़्रास्ट्रक्चर-लेवल राउटिंग के अलावा, अनुरोधों को प्रोसेस करने में लगने वाले समय को कम करने के लिए, ऐप्लिकेशन लेयर पर ये रणनीतियां लागू की जा सकती हैं.

1. "ट्रैम्पोलिन" प्रॉक्सी तरीका

   अगर आपको प्राइमरी डेटा सेंटर बनाए रखना है, तो शुरुआती हैंडशेक को मैनेज करने के लिए, रीजनल लाइटवेट प्रॉक्सी सर्वर (ट्रैम्पोलिन) का इस्तेमाल करें.

   1. Google, आपके ग्लोबल यूआरएल पर हिट करता है.

   2. किसी रीजनल प्रॉक्सी (उदाहरण के लिए, लाइटवेट Nginx या Lambda फ़ंक्शन) को अनुरोध मिलता है.

   3. प्रॉक्सी, पेलोड को आपके इंटरनल, हाई-स्पीड बैकबोन के ज़रिए प्राइमरी डेटाबेस पर फ़ॉरवर्ड करता है.

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

2. ऐक्सेस टोकन के लिए रीजनल हिंट

   खाता लिंक करने (OAuth) की प्रोसेस के दौरान, आपका सिस्टम उपयोगकर्ता के होम रीजन की पहचान कर सकता है.

   लागू करना: Google को जारी किए गए access_token में, रीजन आइडेंटिफ़ायर को एनकोड करें. जब Google, फ़ुलफ़िलमेंट का अनुरोध भेजता है, तो आपका गेटवे तुरंत टोकन की जांच कर सकता है. साथ ही, डेटाबेस लुकअप की ज़रूरत के बिना, अनुरोध को सही रीजनल क्लस्टर पर भेज सकता है.

सिस्टम की क्वालिटी - पार्टनर से Google के लिए मेट्रिक

सक्सेस रेट >= 99.5% बनाए रखने से यह पक्का करने में मदद मिलती है कि Google Home में डिवाइस की स्थितियां सही हों, डिवाइस जोड़े और हटाए जाएं, ऑटोमेशन ट्रिगर हों, और इतिहास के इवेंट, Google Home app (GHA)'s 'गतिविधि' टैब में दिखें.

सक्सेस रेट का हिसाब, Google की ओर से लौटाए गए एचटीटीपी रिस्पॉन्स कोड के आधार पर लगाया जाता है. यह तब होता है, जब आपका क्लाउड, स्टेटस के अपडेट पुश करता है. यह पक्का करने के लिए कि Google के इन्फ़्रास्ट्रक्चर से जुड़ी समस्याओं के लिए, पार्टनर को दंड न दिया जाए, मेट्रिक में गड़बड़ी की संख्या से Google की इंटरनल गड़बड़ियों को शामिल नहीं किया जाता. हिसाब में शामिल किए गए एपीआई कॉल, HomeGraph API रेफ़रंसमें मौजूद होते हैं.

"कार्रवाई पूरी हुई" का क्या मतलब है?

• 2xx (कार्रवाई पूरी हुई): Home Graph को स्टेटस का अपडेट मिल गया है और उसने इसे प्रोसेस कर लिया है.

"कार्रवाई पूरी नहीं हुई" का क्या मतलब है?

• 4xx (पार्टनर की गड़बड़ी): इनसे यह पता चलता है कि कार्रवाई पूरी नहीं हुई है. साथ ही, यह भी पता चलता है कि आपके क्लाउड से भेजे गए अनुरोध में कोई समस्या है. आम तौर पर इस्तेमाल होने वाले कोड में ये शामिल हैं:
  • 400 Bad Request: अमान्य सिंटैक्स की वजह से, सर्वर अनुरोध को प्रोसेस नहीं कर सका. आम तौर पर, इसकी वजह गलत तरीके से बनाया गया JSON या स्ट्रिंग वैल्यू के लिए "" के बजाय null का इस्तेमाल करना होता है.
  • 404 Not Found: अनुरोध किया गया संसाधन नहीं मिला. आम तौर पर, इसका मतलब है कि Google को अनुरोध किया गया डिवाइस नहीं मिल रहा है. इसका मतलब यह भी हो सकता है कि उपयोगकर्ता का खाता लिंक नहीं है या अमान्य agentUserId मिला है. पक्का करें कि agentUserId, आपके SYNC रिस्पॉन्स में दी गई वैल्यू से मेल खाता हो. साथ ही, यह भी पक्का करें कि आप DISCONNECT इंटेंट को सही तरीके से मैनेज कर रहे हों.
  • 429 Resource Exhausted: आपके इंटिग्रेशन ने, तय किए गए कोटा की सीमा को पार कर लिया है. कोटा मैनेज करने के लिए, डैशबोर्ड में ऊपर मौजूद "पहला चरण" सेक्शन में दिए गए निर्देश देखें.

डिवाइस की क्वालिटी - डिवाइस की स्थिति की सटीक जानकारी

डिवाइस की स्थिति की सटीक जानकारी >= 99.5% होने या इससे ज़्यादा होने पर, यह पक्का करने में मदद मिलती है कि उपयोगकर्ताओं को डिवाइस की स्थितियां देखने या एआई की सुविधाओं (जैसे, Ask Home) का इस्तेमाल करने पर सही नतीजे दिखें. अगर डिवाइस की स्थिति की सटीक जानकारी कम है, तो हो सकता है कि ऑटोमेशन ट्रिगर न हों और इतिहास की एंट्री, GHA के 'गतिविधि' टैब में सही समय पर न दिखें. ज़्यादा जानकारी के लिए, स्टेटस की रिपोर्ट करना लेख पढ़ें.

क्वालिटी डैशबोर्ड, हर घंटे के हिसाब से इसकी जानकारी ट्रैक करता है. इसके लिए, दो अलग-अलग मेट्रिक का इस्तेमाल किया जाता है: डिवाइस की स्थिति की कुल सटीक जानकारी और सबसे कम सटीक जानकारी वाला टाइप/ट्रेट कॉम्बिनेशन.

1. डिवाइस की स्थिति की सटीक जानकारी के कॉम्पोनेंट

यह मेट्रिक, "सैंपल" से ली जाती है. इनमें Google, रिपोर्ट किए गए स्टेटस की पुष्टि, तय किए गए इंटेंट के नतीजे के हिसाब से कर सकता है.

2. डैशबोर्ड मेट्रिक (हर घंटे के हिसाब से कैलकुलेशन)

डैशबोर्ड, एक घंटे के इंटरवल के आधार पर डिवाइस की स्थिति की सटीक जानकारी का हिसाब लगाता है. अगर किसी घंटे में कुल 100 से कम सैंपल (S_Total < 100) हैं, तो उस घंटे के लिए डिवाइस की स्थिति की सटीक जानकारी N/A पर सेट की जाती है.

पहला व्यू: डिवाइस की स्थिति की कुल सटीक जानकारी (ग्लोबल औसत)

इससे, सभी डिवाइस टाइप और ट्रेट के लिए, आपके इंटिग्रेशन की कुल सटीक जानकारी मिलती है. इससे, आपके पूरे इकोसिस्टम की क्वालिटी का वेटेड ऐवरेज मिलता है.

• कैलकुलेशन: सभी डिवाइसों के लिए, डिवाइस की स्थिति की कुल सटीक जानकारी / सभी डिवाइसों के लिए, डिवाइस की स्थिति की कुल संख्या.

दूसरा व्यू: सबसे कम सटीक जानकारी वाला टाइप/ट्रेट कॉम्बिनेशन

इससे, आपके इंटिग्रेशन में सबसे कम भरोसेमंद खास कैटगरी की पहचान होती है. इससे, अच्छी क्वालिटी वाले ज़्यादा वॉल्यूम वाले डिवाइस, कम क्वालिटी वाले कम वॉल्यूम वाले डिवाइसों को छिपा नहीं पाते. उदाहरण के लिए, अगर आपके पास 99.5% से ज़्यादा डिवाइस की स्थिति की सटीक जानकारी वाली ज़्यादा वॉल्यूम वाली लाइट हैं, लेकिन कम डिवाइस की स्थिति की सटीक जानकारी वाले कम वॉल्यूम वाले स्विच हैं, तो इससे स्विच में किए जाने वाले सुधारों के बारे में पता चलता है. ऐसा इसलिए, क्योंकि औसत वैल्यू में ये सुधार दिखना मुश्किल है.

• कैलकुलेशन: सभी ट्रेट / डिवाइस कॉम्बिनेशन के लिए, डिवाइस की स्थिति की सटीक जानकारी/डिवाइस की स्थिति की कुल संख्या.