Google Home Vitals (Cloud)

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

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

  1. Google to Partner Metrics - इससे Google से आपके क्लाउड बैकएंड तक किए गए कॉल की परफ़ॉर्मेंस का पता चलता है.

  2. सिस्टम की परफ़ॉर्मेंस - Google के मेट्रिक पार्टनर - इससे आपके सिस्टम से Google को किए गए कॉल की परफ़ॉर्मेंस का पता चलता है.

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

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

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

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

Google से पार्टनर को भेजी जाने वाली मेट्रिक

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

"सफलता" किसे माना जाता है?

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

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

"विफल" किसे माना जाता है?

प्लेटफ़ॉर्म के सामान्य गड़बड़ी कोड में मिली गड़बड़ियों को "विफलताओं" के तौर पर माना जाता है. इन गड़बड़ियों को पार्टनर के लिए कार्रवाई ज़रूरी है के तौर पर मार्क किया जाता है. ऐसा QUERY और EXECUTE के पूरा होने की दर का हिसाब लगाते समय किया जाता है. इसके अलावा, गड़बड़ियां और अपवाद टैब में मिली गड़बड़ियों को भी "फ़ेल" के तौर पर दिखाया जाता है. हालांकि, इनमें ये अपवाद शामिल हैं:

गड़बड़ी के अपवाद
aboveMaximumLightEffectsDuration armLevelNeeded inOffMode
alreadyArmed bagFull lockedToRange
alreadyAtMax belowMinimumLightEffectsDuration lowBattery
alreadyAtMin binFull maxSpeedReached
alreadyClosed cancelArmingRestricted minSpeedReached
alreadyDisarmed deadBattery notSupported
alreadyDocked degreesOutOfRange अॉफ़लाइन
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) की लेटेन्सी को ट्रैक करता है. यह "सबसे धीमे" उपयोगकर्ताओं के अनुभव को दिखाता है. उदाहरण के लिए, 800 मि॰से॰ का P90 का मतलब है कि 90% अनुरोधों को 800 मि॰से॰ या उससे कम समय में स्वीकार किया जाता है.

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

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

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

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

2. EXECUTE Latency (Action)

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

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

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

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

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

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

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

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

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

  2. जियो-लोकेशन के हिसाब से डीएनएस (जियोडीएनएस)

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

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

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

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

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

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

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

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

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

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

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

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

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

सिस्टम की परफ़ॉर्मेंस - पार्टनर से Google को भेजी जाने वाली मेट्रिक

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

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

"सफलता" किसे माना जाता है?

  • 2xx (Success): The state update was successfully received and processed by Home Graph.

"विफल" किसे माना जाता है?

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

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

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

क्वालिटी डैशबोर्ड, हर घंटे के हिसाब से इन मेट्रिक को ट्रैक करता है: कुल सटीकता और सबसे कम टाइप/ट्रेट कॉम्बिनेशन.

1. सटीकता से जुड़े कॉम्पोनेंट

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

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

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

व्यू 1: कुल सटीकता (ग्लोबल औसत)

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

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

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

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

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