Roblox क्लाउडवर नेटवर्क पॅकेट गमावट आणि विलंब मॉनिटरिंग

Roblox नेटवर्क अभियांत्रिकी टीम जगभरात पसरलेल्या डेटा सेंटर आणि पॉईंट ऑफ प्रेझन्स (POP) साइट्ससह मोठे, वेगाने वाढणारे नेटवर्क व्यवस्थापित करते. Roblox प्लॅटफॉर्मवर उत्कृष्ट वापरकर्ता अनुभव देणे या नेटवर्कच्या कार्यक्षमता आणि विश्वसनीयतेवर अवलंबून असते. नेटवर्क ऑपरेटर्सना नेटवर्कमधील समस्या निराकरण आणि शोध घेणे तसेच नेटवर्कच्या कामगिरीवर दृश्यमानता असणे अत्यंत महत्त्वाचे आहे. नेटवर्क मॉनिटरिंग सामान्यतः उपकरणे आकडेवारी, त्रुटी मेट्रिक्स आणि सिस्लॉग्स नियमितपणे गोळा करून आणि त्यांना टाइम सिरीज किंवा लॉग डेटाबेसमध्ये संग्रहित करून साध्य केले जाते. हा डेटा SNMP, Netconf, REST APIs किंवा स्ट्रीमिंग टेलीमेट्री सारख्या मानक प्रोटोकॉलचा वापर करून पुश किंवा पुल मॉडेलद्वारे गोळा केला जातो.

केवळ डिव्हाइस टेलिमेट्रीद्वारे नेटवर्क दोष शोधण्यात अनेक कमतरता आहेत, कारण ही एक निष्क्रिय देखरेख तंत्र आहे. हे नेटवर्क नोड्सच्या क्षमतांवर अवलंबून असते की ते असामान्य परिस्थिती उद्भवताच ओळखून त्याची अहवाल देतील. डिव्हाइस नेहमीच डेटा परत अहवाल देत नाही किंवा काही प्रकरणांमध्ये, त्याची सर्व आरोग्य आकडेवारी सामान्य टेलिमेट्री गोळा करण्याच्या पद्धतींना उपलब्ध नसते. याव्यतिरिक्त, नेटवर्क उपकरणे कधीकधी चुकीचा डेटा देऊ शकतात किंवा गुपचूपपणे ट्रॅफिक ब्लॅक-होल करू शकतात. डिव्हाइस टेलीमेट्रीची एक मोठी मर्यादा म्हणजे ती नेटवर्कच्या एंड-टू-एंड पोहोच, पॅकेट ड्रॉप आणि विलंब आकडेवारीबद्दल फारच कमी दृश्यमानता प्रदान करते.

नेटवर्कचे सक्रियपणे निरीक्षण करण्याचा एक उत्तम मार्ग म्हणजे खालील आकृत्यांमध्ये दाखविल्याप्रमाणे मेषवर नियमितपणे संश्लेषित प्रोब्स प्रसारित करणे.

उत्पादन अडचणींचे निराकरण करताना, नेटवर्क ऑपरेटरांना वारंवार "नेटवर्क पॅकेट्स ड्रॉप करत आहे का?" किंवा "सेवा कनेक्टिव्हिटीवर परिणाम करणारी कोणतीही चालू नेटवर्क त्रुटी आहे का?" असे प्रश्न विचारले जातात. ऐतिहासिक पॅकेट लॉस आणि विलंब डेटा उपलब्ध नसताना अशा प्रश्नांची उत्तरे देण्यासाठी त्यांना नेटवर्कमधील मोठ्या संख्येने लिंक आणि नोड्सची तपासणी करावी लागते.

विश्वसनीय आणि स्केलेबल नेटवर्क मेष मॉनिटरिंग सिस्टमचे डिझाइन

ब्लॅक बॉक्स नेटवर्क मॉनिटरिंग सिस्टम पॅकेट लॉस किंवा लेटन्सी स्पाइक्स शोधण्यात प्रभावी ठरण्यासाठी नेटवर्कच्या विविध भागांवर सतत प्रोबिंग करणे आवश्यक असते. डेटा सेंटर नेटवर्क वापरकर्त्यांच्या ट्रॅफिकसाठी नोड्समधील सर्व लिंक वापरतात. प्रोडक्शन नेटवर्क उपकरणे BGP चालवतात आणि एकापेक्षा जास्त समान-किंमतीच्या मार्गांवर ट्रॅफिकचे लोड-बॅलन्सिंग करतात. सामान्य परिस्थितीत नेटवर्क टोपोलॉजीतील बदल राउटिंग टेबल अपडेट्सद्वारे काही सेकंदांत प्रतिबिंबित होतात. नेटवर्क पॅकेट गमावण्याची अचूक मोजणी करण्यासाठी, चाचणी प्रोब्सनी सर्व नेटवर्क नोड्स आणि लिंक्सना व्यापत शक्य तितक्या मार्गांवरून प्रवास करणे आवश्यक आहे. आमच्यासारख्या मोठ्या नेटवर्कमध्ये, जे जगभरातील अनेक ठिकाणी पसरलेले असते, प्रत्येक नोड किंवा रॅकच्या जोडीत चाचणी करणे विस्तारक्षम नसते. दृश्यमानतेच्या पातळीवर तडजोड न करता आम्ही निवडलेले अधिक शाश्वत समाधान म्हणजे प्रत्येक साइटमधील रॅक्समध्ये N² मेषची चाचणी करणे आणि सर्व साइट्समध्ये आणखी एक N² मेषची चाचणी करणे.

नेटवर्कचे परीक्षण आम्ही काय वापरून करतो?

चाचणी प्रोब्सनी प्रोडक्शन नेटवर्कमधून जाणाऱ्या प्रत्यक्ष ट्रॅफिकची अनुकरणे करणे आवश्यक आहे. आमच्या नेटवर्कवरील बहुतेक ट्रॅफिक TCP, UDP किंवा HTTP असते, आणि यापैकी प्रत्येक प्रोबसाठी संभाव्यरित्या वापरता येऊ शकते. TCP प्रोबिंगशी संबंधित एक समस्या अशी आहे की मोठ्या नेटवर्कचे निरीक्षण करण्यासाठी आवश्यक असलेल्या कनेक्शन्सच्या संख्येनुसार स्केल करण्यासाठी ते पुरेसे हलके (lightweight) नसते. TCP बरोबर आणखी एक अडचण म्हणजे त्यातील अंतर्निहित फ्लो-कंट्रोल आणि स्लाइडिंग विंडो-आधारित प्रसारणामुळे प्रोब्सच्या प्रसारण दरात बदल होतो, जो क्षणिक पॅकेट गळतीचे प्रमाणित करणे किंवा शोधणे यासाठी अनुकूल नाही. ICMP, जे ping आणि traceroute द्वारे वापरले जाते, ते सामान्यतः सर्व्हर किंवा नेटवर्क नोडवर दर-मर्यादित असते. यामुळे वापरता येणाऱ्या ICMP प्रोब्सचा एकूण दर मर्यादित होतो. HTTP विनंत्या ऍप्लिकेशन लेयरमध्ये वरच्या स्तरावर असतात आणि त्या सर्व्हर किंवा ऍप्लिकेशनच्या कामगिरीसारख्या नेटवर्कबाहेरील काही घटकांवर अवलंबून असतात. HTTP निकालांमध्ये एक अतिरिक्त बदलणारा घटक जोडतो ज्याला वेगळे करणे कठीण असते. या प्रणालीचा उद्देश OSI लेयर 4 आणि त्याखाली मुख्यत्वे कार्य करणाऱ्या अंतर्निहित नेटवर्क पायाभूत सुविधांच्या कामगिरीचे निरीक्षण करणे हा आहे. या कारणांमुळे आणि आमच्या नेटवर्कवरील प्राथमिक ट्रान्सपोर्ट लेयर प्रोटोकॉल असल्यामुळे आम्ही UDP प्रोब्स निवडले.

आम्ही कुठून प्रोब्स पाठवतो?

मोठ्या एकत्रित प्रोब दरापर्यंत पोहोचण्याचा आणि जास्त संख्येने नेटवर्क मार्गांचा समावेश करण्याचा एक मार्ग म्हणजे प्रोब्स प्रसारित करण्यासाठी शक्य तितक्या कम्प्यूट नोड्सचा वापर करणे. याचे दोन फायदे आहेत: हे प्रोब्स तयार करणाऱ्या सिस्टमवरील लोड वितरीत करण्यात मदत करते, आणि हे त्यांना वाहून नेणाऱ्या नेटवर्क पोर्ट्सची संख्या वाढवते. तथापि, यासाठी एक अतिशय स्थिर आणि होस्ट सिस्टमच्या संसाधनांवर शक्य तितके कमी भार असलेला एजंट आवश्यक आहे. त्याच वेळी, होस्ट सिस्टमवरील CPU, मेमरी किंवा I/O वापरातील चढउतारांचा परिणाम न होता, एजंटला अनेक मार्गांवरील पॅकेट गळती आणि विलंब अचूकपणे मोजता यावेत. एजंटला हलके वजनाचे आणि उच्च कार्यक्षमतेचे हे नाजूक संतुलन सतत राखणे आवश्यक आहे.

नेटवर्क गमावणी आणि विलंब कसे मोजायचे?

हे एका प्रॉब्सच्या प्रवाहावरचे एक साधे गणन वाटू शकते, परंतु मोठ्या प्रमाणात काही आव्हाने उद्भवतात जी लगेच लक्षात येत नाहीत. अशा मोठ्या मेषपर्यंत विस्तार करण्यासाठी, एजंटला एकाच वेळी अनेक प्रवाहांवर वेळ-स्टँपसह जलद आणि अचूक प्रसारण (Tx) आणि प्राप्त (Rx) पॅकेट मोजमाप करणे आवश्यक असते. एजंट चालवणाऱ्या होस्टवरील CPU व्यस्त असताना किंवा नेटवर्क बफर्स ओव्हरफ्लो झाल्यामुळे हरवलेल्या पॅकेट्सना नेटवर्क लॉस मेट्रिक्समध्ये समाविष्ट केले जाऊ नयेत, हे महत्त्वाचे आहे. नेटवर्क विलंब मोजताना प्रोब्स वायरवर किंवा मध्यवर्ती नेटवर्क नोड्सवर घालवलेला एकूण वेळ विचारात घ्यावा, तर I/O बफर्समध्ये प्रतीक्षा करत घालवलेला वेळ आणि एजंट प्रक्रियेचे OS शेड्युलिंगसाठी प्रतीक्षा करत घालवलेला वेळ वगळावा.

Roblox ची Ping Mesh प्रणाली

सार्वजनिक आणि खाजगी क्लाउड पायाभूत सुविधांच्या वाढीपासूनच ब्लॅक बॉक्स नेटवर्क गमावणी आणि विलंबाचे निरीक्षण करण्याची गरज अस्तित्वात आहे. आमच्या मोठ्या नेटवर्कपर्यंत विस्तार करता येईल असा तयार-उपलब्ध उपाय शोधणे अवघड ठरले आहे. अनेक मोठ्या क्लाउड ऑपरेटर आणि नेटवर्क टूलिंग पुरवठादारांनी नेटवर्क गमावणी आणि विलंबाचे निरीक्षण करण्यासाठी स्वतःचे उपाय विकसित केले आहेत. आम्ही काही खुलेपणे उपलब्ध साधने वापरून पाहिली, परंतु स्थिरता आणि विस्तारक्षमतेच्या समस्या आल्या आणि नेटवर्कच्या कामगिरीवर फक्त मर्यादित दृश्यमानता मिळाली. यामुळे आम्हाला आमची स्वतःची मेष मॉनिटरिंग प्रणाली तयार करावी लागली, ज्यामुळे कमी ओव्हरहेडसह कमी वारंवार होणाऱ्या त्रुटींचे उत्तम शोध शक्य झाले. आमच्या प्रणालीची काही ठळक वैशिष्ट्ये आहेत:

• आम्ही आमच्या प्रणालीतील सर्व घटक अंमलबजावण्यासाठी Go भाषा निवडली आणि त्यामुळे कमी प्रणाली संसाधने वापरून उच्च कार्यक्षमता साध्य करण्यात मदत झाली.
• आमचे एजंट अत्यंत स्थिर आहेत आणि उत्पादन होस्टच्या विस्तृत श्रेणीवर चालू शकतात, ज्यात Roblox प्लॅटफॉर्मवर ट्रॅफिक, कॅशिंग आणि अॅप्लिकेशन सर्व्हरसारख्या महत्त्वाच्या सेवा पुरवणाऱ्या होस्टचा समावेश आहे.
• एजंटला Linux sendmmsg() आणि recvmmsg() सिस्टीम कॉल्सवर Go रॅपर फंक्शन्ससह पॅकेट I/O ऑपरेशन्स बॅच करण्यासाठी ऑप्टिमाइझ केले आहे, ज्यामुळे ते कमी ओव्हरहेडसह उच्च दराने प्रोब्स प्रसारित करू शकते. आमच्या तैनातीतील प्रत्येक एजंट एकाच वेळी 100 इतर होस्टपर्यंत 100 पॅकेट प्रति सेकंद (PPS) या दराने प्रोब्स प्रसारित करतो. एजंट प्रत्येक सेकंदाला प्रत्येक गंतव्याकडे पॅकेट बर्स्ट प्रसारित करतो.
• प्रोब्स प्रत्येक गंतव्यस्थानी IP हेडरमधील विविध प्रकार-सेवा (TOS) क्षेत्राचे मूल्य घेऊन जातात आणि नेटवर्कवरील पॅकेट गमावणे व विलंब यासाठी स्वतंत्रपणे मोजले जातात. प्रत्येक पॅकेट बर्स्टमध्ये इतर सर्व गंतव्यांसाठी एकापेक्षा जास्त TOS मूल्यांचा समावेश असतो. हे विविध गुणवत्ता-सेवा (QoS) वर्गांसाठी नेटवर्क कामगिरीचे निरीक्षण करण्यात मदत करते.
• एजंट प्रत्येक प्रोब मार्गावर प्रति मिनिट 6000 पैकी फक्त 1 पॅकेट इतक्या कमी प्रमाणात होणाऱ्या नेटवर्क ड्रॉप्सचेही शोध घेऊ शकतो. नेटवर्कच्या कोअर किंवा एजमध्ये 1 सेकंदापेक्षा कमी काळ टिकणाऱ्या पॅकेट गमावण्याचेही, जसे की BGP फ्लॅप दरम्यान, शोध घेता येते.
• जेव्हा त्रुटींमुळे पॅकेट ड्रॉप होतात, तेव्हा प्रोब पॅकेट ड्रॉप चार्ट्स नेटवर्क उपकरण इंटरफेसच्या त्रुटी दरांसारखे दिसतात. आम्ही नेटवर्कमधील ट्रॅफिक ब्लॅक-होलिंग बग्स शोधण्यात सक्षम झालो आहोत, जे शोधणे कठीण असते.
• एजंट्स नेटवर्क विलंब मोजमापात उच्च अचूकता मिळवण्यासाठी NIC कर्नेल रीड टाइमस्टँप्सचा वापर करतात. होस्ट OS शेड्युलिंग विलंब आणि नेटवर्क क्लॉक ड्रिफ्ट वगळता, साइट-आंतरिक राऊंड ट्रिप विलंब 50–100 मायक्रोसेकंद इतका सातत्याने मोजता येतो.
• कमी CPU वापर आणि मेमरी फूटप्रिंट. एजंट उच्चतम प्रसारण आणि प्राप्त दर (प्रत्येकी 5 kpps) वर एका कोअरच्या 25% पेक्षा कमी वापरतो. तैनात केलेल्या बहुतेक एजंट्स एका कोअरचा फक्त सुमारे 5% वापरतात. एजंटच्या Tx आणि Rx पॅकेट बफर्स आणि काउंटर्स व्यवस्थापित करण्यासाठी फक्त 10MB हीप मेमरी आवश्यक आहे. जेव्हा नेटवर्क वाढते, तेव्हा आम्ही मर्यादा समायोजित करून किंवा अतिरिक्त एजंट्स जोडल्याने उभ्या किंवा आडव्या स्वरूपात स्केल करू शकतो.
• होस्ट सिस्टम ताणाखाली असतानाही एजंटवर फारसा परिणाम होत नाही. अनेक प्रसंगी होस्ट CPU लोड 99% पर्यंत पोहोचल्यावरही आम्हाला अचूक निकाल मिळाले आहेत.
• प्रत्येक एजंटचे आरोग्य तपासण्यासाठी त्याकडून टेलीमेट्री गोळा केली जाते. होस्ट सिस्टम रीबूट झाल्यावर, एजंट प्रक्रिया पुन्हा सुरू झाल्यावर किंवा सॉकेट बफर्स ओव्हरफ्लोमुळे पॅकेट्स गमावल्यावर अशा समस्या निर्माण झाल्याचे एजंट ओळखू शकतात.

नेटवर्क प्रोबिंगमध्ये सहभागी होणाऱ्या नोड्सची मोठी संख्या राखण्यासाठी एजंट्सना Chef वापरून विस्तृत सर्व्हर क्लस्टर्सवर तैनात केले जाते. एजंट बायनरी Linux वर systemd वापरून चालवली आणि व्यवस्थापित केली जाते, ज्यामुळे होस्ट रीबूट किंवा एजंट अपग्रेड झाल्यानंतर ती आपोआप पुन्हा सुरू होते. एखादा एजंट बंद पडल्यास किंवा नवीन एजंट सुरू झाल्यास, मेष शेड्युलर गरजेनुसार स्ट्रीम्सना गतिशीलपणे ओळखतो आणि समायोजित करतो. आमचे शेड्युलर अॅप्लिकेशन ठराविक अंतराने डिव्हाइस इन्व्हेंटरी आणि सेवा शोध प्रणालीकडून माहिती गोळा करते, ज्यामुळे Intra-Pod, Intra-Site आणि Inter-Site प्रोबिंगसाठी लक्ष्ये वाटप करण्यापूर्वी नवीन एजंट्स आणि सर्व्हरच्या आरोग्यस्थितीचा शोध घेता येतो. परीक्षण प्रोब्स प्रसारित करणाऱ्या प्रत्येक एजंटला लक्ष्य होस्टची यादी कळवण्यासाठी संदेश बसचा वापर केला जातो. विशिष्ट रॅकमध्ये सुरू होणाऱ्या किंवा संपणाऱ्या वैयक्तिक स्ट्रिम्स त्या रॅकमधील सर्व उपलब्ध एजंटमध्ये वितरित केल्या जातात. खालील आकृत्यांमध्ये दाखविल्याप्रमाणे, यामुळे आमच्या नेटवर्क फॅब्रिकमधील समान खर्चाच्या मार्गांची मोठ्या प्रमाणात चाचणी करण्यास मदत होते.

आम्ही आमच्या पहिल्या तैनातीत 150 एजंट्ससह सुरुवात केली आणि आता यशस्वीरित्या 10 पट वाढवले आहे. हे मेष आमच्या बॅकबोनला व्यापते आणि जगभरात पसरलेल्या 25 साइट्सना एकमेकांशी जोडते. आमच्या एका प्राथमिक डेटा सेंटर साइटवर, आमच्याकडे 200+ रॅक्सचे आंतर-साइट मेष आहे, ज्यात सुमारे 33,000 स्ट्रीम्स आहेत आणि त्याचा एकूण 1.65 Mpps प्रोब दर आहे. प्रत्येक रॅक इतर रॅक्सकडून 5–10 kpps प्रोब्स प्राप्त करतो. शेड्युलर अॅप्लिकेशन 35,000 पेक्षा जास्त लक्ष्ये गणना करून विविध साइट्समधील सर्व एजंट्समध्ये समान रीतीने वितरित करते.

डेटा संकलन आणि दृश्यीकरण

आम्ही एक स्वतंत्र कलेक्टर अॅप्लिकेशन चालवतो जे नियमितपणे सर्व Ping Mesh एजंट्सकडून पॅकेट लॉस आणि लेटन्सीचे निकाल पोल करते. हे डेटा कलेक्टरवर स्थानिकरित्या कॅश केलेल्या हेल्थ स्टेट्सच्या आधारावर अमान्य निकाल वगळण्यासाठी स्वयंचलितपणे फिल्टर केले जाते. उदाहरणार्थ, आम्ही अशा एजंटचे निकाल वगळतो जे हेल्थ चेक्सला प्रतिसाद देत नाही किंवा नुकतेच रीबूट झालेल्या सर्व्हरवर चालत आहे. आमचा कलेक्टर एकाच वेळी 1,500 पेक्षा जास्त नोड्समधून निकाल पोल आणि फिल्टर करू शकतो आणि नंतर 2 सेकंदांच्या आत हा डेटा टाइम-सीरीज डेटाबेसमध्ये समाविष्ट करतो.

एकत्रित आणि प्रति-स्ट्रीम दोन्ही निकाल Grafana डॅशबोर्डच्या सहाय्याने दृश्यमान केले जातात. मोठ्या डेटा संचांसह, विशेषतः आमच्या मोठ्या डेटा सेंटर साइटसाठी, हीटमॅप ग्रिड वापरणे कठीण असू शकते. हजारो निकालांमध्ये, ज्यापैकी सामान्यतः फक्त काहीच असतात, त्यातल्या हजारो निकालांमध्ये सर्वाधिक वैयक्तिक पॅकेट ड्रॉप असलेले मार्ग प्रदर्शित करण्यासाठी आम्ही Prometheus topk() क्वेरीचा वापर करतो. संकलकाद्वारे वारंवार पोल केलेल्या एजंट आणि होस्ट सिस्टमच्या आरोग्य आकडेवारीशी निकाल सखोलपणे तपासले जातात. यामुळे पॅकेट ड्रॉपच्या बदलांची व्याप्ती कितीही मोठी असली तरीही प्रत्येक वैयक्तिक निकालावर आम्हाला उच्च पातळीचा आत्मविश्वास मिळतो. वैयक्तिक निकाल एकत्र पाहिल्यास नेटवर्कमधील दोष कुठे झाला याबद्दल संकेत मिळू शकतात. आमच्या मेष मॉनिटरिंग सिस्टमने पकडलेल्या काही पॅकेट लॉसची उदाहरणे खाली दाखवली आहेत.

सारांश आणि पुढील पावले

आमची Ping Mesh प्रणाली नेटवर्क अभियांत्रिकी संघासाठी एंड-टू-एंड पॅकेट गळती आणि विलंब (latency) मोजण्यासाठी एक सामर्थ्यवान साधन ठरली आहे. हा डेटा "नेटवर्क पॅकेट्स ड्रॉप करत आहे का?" या प्रश्नाचे त्वरित उत्तर देण्यासाठी वापरता येतो. आमच्या अनुभवावरून, ग्राहकांवर मोठा परिणाम करणाऱ्या नेटवर्क घटना सहसा डिव्हाइस टेलीमेट्री मॉनिटरिंग प्रणालीद्वारे ओळखल्या जातात आणि त्याबाबत सूचना दिली जाते. नेटवर्क बफरिंगमधील कमी परिणामकारक परंतु संभाव्यतः समस्या निर्माण करणारे प्रकरणे किंवा विচ্ছিন্ন ट्रॅफिक ब्लॅक-होलिंग या प्रणालीद्वारे उघडकीस येतात.

आमची प्रणाली Roblox क्लाउड नेटवर्कच्या एकूण विश्वसनीयतेबद्दलही अंतर्दृष्टी प्रदान करू शकते. आमच्या एका प्रमुख डेटा सेंटर साइटवर, आम्ही नेटवर्कच्या आरोग्यावर देखरेख करण्यासाठी दर मिनिटाला 100 दशलक्षाहून अधिक प्रोब्स वापरतो आणि आम्ही क्वचितच दर मिनिटाला 50 पेक्षा जास्त पॅकेट गमावतो. हे आमच्या डेटा सेंटर नेटवर्ककडून सुमारे 6 9's (99.9999%) विश्वसनीयतेचे सूचक आहे. बहुतेक वेळा, 100 दशलक्ष पॅकेटपैकी कोणताही पॅकेट ड्रॉप आढळत नाही. जेव्हा मोठ्या प्रमाणात पॅकेट गमावले जातात, तेव्हा ही प्रणाली पॅकेट ड्रॉप कुठे आणि किती काळ झाला याबद्दल अंतर्दृष्टी प्रदान करते. एक स्वयंचलित निवारण इंजिन नेटवर्कचे स्वतःहून दुरुस्ती करते आणि वापरकर्त्याच्या ट्रॅफिकला नेटवर्कमधील दुसऱ्या मार्गावर पुनर्निर्देशित करून पुढील ड्रॉप होण्यापासून प्रतिबंधित करते. Roblox येथील नेटवर्किंग टीमने अत्यंत विश्वासार्ह क्लाउड नेटवर्क तयार केले आहे.

भविष्यात, आम्ही डिव्हाइस टेलिमेट्री, सिस्लॉग्स आणि इतर डेटा संचांमधील डेटाचे सहसंबंध करण्यासाठी एनालिटिक्स इंजिनचा वापर करण्याचा मानस आहे. नंतर आम्ही नेटवर्कमध्ये दोष कुठे झाला हे शोधण्यासाठी ते पिंग मेष डेटाशी तुलना करण्याची योजना आखतो. जसे Roblox चे क्लाउड नेटवर्क वाढत आणि विकसित होत राहील, तसे आम्ही आमच्या प्रोबिंग यंत्रणेत IPv6 आणि जंबो फ्रेम्स समाविष्ट करण्यासाठी सुधारणा करणार आहोत, तसेच इंटर-साइट कव्हरेज वाढवण्यासाठी अधिक एजंट्स जोडणार आहोत.