రాబ్లాక్స్ క్లౌడ్‌లో నెట్‌వర్క్ ప్యాకెట్ నష్టం & లేటెన్సీ పర్యవేక్షణ

రాబ్లాక్స్ నెట్‌వర్క్ ఇంజనీరింగ్ బృందం ప్రపంచవ్యాప్తంగా పంపిణీ చేయబడిన డేటా సెంటర్ మరియు పాయింట్ ఆఫ్ ప్రెజెన్స్ (POP) సైట్‌లతో ఒక పెద్ద, వేగంగా అభివృద్ధి చెందుతున్న నెట్‌వర్క్‌ను నిర్వహిస్తుంది. రాబ్లాక్స్ ప్లాట్‌ఫారమ్‌పై గొప్ప వినియోగదారు అనుభవాన్ని అందించడం ఈ నెట్‌వర్క్ యొక్క పనితీరు మరియు విశ్వసనీయతపై ఆధారపడి ఉంటుంది. నెట్‌వర్క్ ఆపరేటర్లు నెట్‌వర్క్‌లోని సమస్యలను పరిష్కరించడం మరియు గుర్తించడం, మరియు నెట్‌వర్క్ పనితీరుపై దృశ్యమానతను కలిగి ఉండటం చాలా కీలకం. సాధారణంగా నెట్‌వర్క్ పర్యవేక్షణను, పరికరాల గణాంకాలు, లోపాల కొలమానాలు మరియు సిస్‌లాగ్‌లను క్రమానుగతంగా సేకరించి, వాటిని టైమ్ సిరీస్ లేదా లాగ్ డేటాబేస్‌లో నిల్వ చేయడం ద్వారా సాధిస్తారు. ఈ డేటాను SNMP, నెట్‌కాన్ఫ్, రెస్ట్ APIలు లేదా స్ట్రీమింగ్ టెలిమెట్రీ వంటి ప్రామాణిక ప్రోటోకాల్‌లను ఉపయోగించి పుష్ లేదా పుల్ మోడల్‌తో సేకరిస్తారు.

కేవలం పరికర టెలిమెట్రీ ద్వారా నెట్‌వర్క్ లోపాలను గుర్తించడంలో అనేక లోపాలు ఉన్నాయి, ఎందుకంటే ఇది ఒక నిష్క్రియ పర్యవేక్షణ పద్ధతి. ఇది నెట్‌వర్క్ నోడ్‌లు అసాధారణ పరిస్థితులు ఏర్పడిన వెంటనే వాటిని గుర్తించి, నివేదించగల సామర్థ్యంపై ఆధారపడి ఉంటుంది. పరికరం ఎల్లప్పుడూ డేటాను తిరిగి నివేదించకపోవచ్చు లేదా, కొన్ని సందర్భాల్లో, సాధారణ టెలిమెట్రీ సేకరణ పద్ధతులకు దాని ఆరోగ్య గణాంకాలన్నీ బహిర్గతం కాకపోవచ్చు. అదనంగా, నెట్‌వర్క్ పరికరాలు కొన్నిసార్లు తప్పు డేటాను అందించవచ్చు లేదా ట్రాఫిక్‌ను నిశ్శబ్దంగా బ్లాక్-హోల్ చేయవచ్చు. డివైస్ టెలిమెట్రీతో ఉన్న ఒక ప్రధాన పరిమితి ఏమిటంటే, ఇది నెట్‌వర్క్ యొక్క ఎండ్-టు-ఎండ్ రీచబిలిటీ, ప్యాకెట్ డ్రాప్, మరియు లేటెన్సీ గణాంకాలపై చాలా తక్కువ దృశ్యమానతను అందిస్తుంది.

కింద ఉన్న చిత్రాలలో చూపిన విధంగా, ఒక మెష్ అంతటా క్రమం తప్పకుండా సంశ్లేషిత ప్రోబ్‌లను ప్రసారం చేయడం ద్వారా నెట్‌వర్క్‌ను చురుకుగా పర్యవేక్షించడానికి ఇది ఒక గొప్ప మార్గం.

ఉత్పత్తి అంతరాయాలను పరిష్కరిస్తున్నప్పుడు, నెట్‌వర్క్ ఆపరేటర్లను తరచుగా, "నెట్‌వర్క్ ప్యాకెట్లను డ్రాప్ చేస్తోందా?" లేదా "సేవ కనెక్టివిటీని ప్రభావితం చేసే నెట్‌వర్క్ లోపం ఏదైనా జరుగుతోందా?" వంటి ప్రశ్నలు అడుగుతారు. చారిత్రక ప్యాకెట్ నష్టం మరియు లేటెన్సీ డేటాకు యాక్సెస్ లేకుండా ఈ రకమైన ప్రశ్నకు సమాధానం ఇవ్వడానికి, వారు నెట్‌వర్క్‌లోని పెద్ద సంఖ్యలో లింక్‌లు మరియు నోడ్‌లను పరిశీలించాల్సి ఉంటుంది.

విశ్వసనీయమైన మరియు స్కేలబుల్ నెట్‌వర్క్ మెష్ మానిటరింగ్ సిస్టమ్‌ను రూపొందించడం

ప్యాకెట్ నష్టం లేదా లేటెన్సీ స్పైక్‌లను గుర్తించడంలో ఒక బ్లాక్ బాక్స్ నెట్‌వర్క్ మానిటరింగ్ సిస్టమ్ ప్రభావవంతంగా ఉండాలంటే, నెట్‌వర్క్‌లోని వివిధ భాగాలపై నిరంతర ప్రోబింగ్ అవసరం. డేటా సెంటర్ నెట్‌వర్క్‌లు వినియోగదారుల ట్రాఫిక్ కోసం నోడ్‌ల మధ్య ఉన్న అన్ని లింక్‌లను ఉపయోగిస్తాయి. ప్రొడక్షన్ నెట్‌వర్క్ పరికరాలు BGPని నడుపుతాయి మరియు బహుళ సమాన-ఖర్చు మార్గాలపై ట్రాఫిక్‌ను లోడ్-బ్యాలెన్స్ చేస్తాయి. సాధారణ పరిస్థితులలో, నెట్‌వర్క్ టోపాలజీలో మార్పులు సాధారణంగా సెకన్లలో రూటింగ్ టేబుల్ అప్‌డేట్‌ల ద్వారా ప్రతిబింబిస్తాయి. నెట్‌వర్క్ ప్యాకెట్ నష్టం యొక్క కచ్చితమైన కొలతను పొందడానికి, టెస్ట్ ప్రోబ్స్ అన్ని నెట్‌వర్క్ నోడ్‌లు మరియు లింక్‌లను కవర్ చేస్తూ సాధ్యమైనన్ని ఎక్కువ మార్గాల గుండా ప్రయాణించాలి. ప్రపంచవ్యాప్తంగా బహుళ సైట్‌లలో విస్తరించి ఉన్న మా నెట్‌వర్క్ వంటి పెద్ద నెట్‌వర్క్‌తో, ప్రతి జత నోడ్‌లు లేదా ర్యాక్‌ల మధ్య ప్రోబ్ చేయడం స్కేలబుల్ కాదు. విజిబిలిటీ స్థాయిలో రాజీ పడని, మేము ఎంచుకున్న మరింత స్థిరమైన పరిష్కారం ఏమిటంటే, ప్రతి సైట్‌లోని ర్యాక్‌లలో N² మెష్‌ను మరియు అన్ని సైట్‌లలో మరో N² మెష్‌ను ప్రోబ్ చేయడం.

మనం నెట్‌వర్క్‌ను ఏమిటితో ప్రోబ్ చేయాలి?

టెస్ట్ ప్రోబ్స్ ప్రొడక్షన్ నెట్‌వర్క్ ద్వారా వెళ్లే లైవ్ ట్రాఫిక్‌ను అనుకరించాలి. మా నెట్‌వర్క్‌లోని చాలా ట్రాఫిక్ TCP, UDP, లేదా HTTP, మరియు వీటిలో ప్రతి ఒక్కటి ప్రోబ్స్ కోసం సంభావ్యంగా ఉపయోగించవచ్చు. TCP ప్రోబింగ్‌తో ఉన్న సమస్యలలో ఒకటి ఏమిటంటే, ఒక పెద్ద నెట్‌వర్క్‌ను పర్యవేక్షించడానికి అవసరమైన కనెక్షన్‌ల సంఖ్యకు స్కేల్ చేయడానికి ఇది తగినంత తేలికైనది కాదు. TCPతో ఉన్న మరో సమస్య ఏమిటంటే, దానిలో అంతర్నిర్మిత ఫ్లో-కంట్రోల్ మరియు స్లైడింగ్ విండో-ఆధారిత ప్రసారాలు, ప్రోబ్ ప్రసార రేటును మారుతూ ఉండేలా చేస్తాయి. ఇది క్షణకాల ప్యాకెట్ డ్రాప్‌లను లెక్కించడానికి లేదా గుర్తించడానికి అనువైనది కాదు. పింగ్ మరియు ట్రేసర్‌రూట్ ద్వారా ఉపయోగించబడే ICMP, సాధారణంగా సర్వర్‌లు లేదా నెట్‌వర్క్ నోడ్‌ల వద్ద రేట్-లిమిటెడ్‌గా ఉంటుంది. ఇది ఉపయోగించగల ICMP ప్రోబ్‌ల మొత్తం రేటును పరిమితం చేస్తుంది. HTTP అభ్యర్థనలు అప్లికేషన్ లేయర్‌లో పైభాగంలో ఉంటాయి మరియు సర్వర్ లేదా అప్లికేషన్ పనితీరు వంటి నెట్‌వర్క్ వెలుపలి కొన్ని అంశాలపై ఆధారపడి ఉంటాయి. HTTP ఫలితాలకు ఒక అదనపు వేరియబుల్ అంశాన్ని జోడిస్తుంది, దానిని వేరు చేయడం కష్టం. ఈ వ్యవస్థ యొక్క లక్ష్యం, ప్రాథమికంగా OSI లేయర్ 4 మరియు అంతకంటే దిగువన పనిచేసే అంతర్లీన నెట్‌వర్క్ మౌలిక సదుపాయాల పనితీరును పర్యవేక్షించడం. మా నెట్‌వర్క్‌లో ఇది ప్రాథమిక ట్రాన్స్‌పోర్ట్ లేయర్ ప్రోటోకాల్ అయినప్పటికీ, ఈ కారణాల వల్ల మేము UDP ప్రోబ్స్‌ను ఎంచుకున్నాము.

మేము ఎక్కడ నుండి ప్రోబ్ చేస్తాము?

పెద్ద మొత్తపు ప్రోబ్ రేటును సాధించడానికి మరియు పెద్ద సంఖ్యలో నెట్‌వర్క్ మార్గాలను కవర్ చేయడానికి ఒక మార్గం ఏమిటంటే, ప్రోబ్‌లను ప్రసారం చేయడానికి వీలైనన్ని ఎక్కువ కంప్యూట్ నోడ్‌లను ఉపయోగించడం. దీనికి రెండు ప్రయోజనాలు ఉన్నాయి: ఇది ప్రోబ్‌లను ఉత్పత్తి చేసే సిస్టమ్‌లపై భారాన్ని పంపిణీ చేయడంలో సహాయపడుతుంది, మరియు వాటిని తీసుకువెళ్లే నెట్‌వర్క్ పోర్ట్‌ల సంఖ్యను విస్తరిస్తుంది. అయితే, దీనికి చాలా స్థిరంగా మరియు హోస్ట్ సిస్టమ్ వనరులపై వీలైనంత తక్కువ ప్రభావం చూపే ఏజెంట్ అవసరం. అదే సమయంలో, హోస్ట్ సిస్టమ్‌లోని CPU, మెమరీ, లేదా I/O వినియోగంలోని హెచ్చుతగ్గులతో ప్రభావితం కాకుండా, బహుళ మార్గాలలో ప్యాకెట్ నష్టం మరియు లేటెన్సీని కచ్చితంగా కొలిచే సామర్థ్యం ఏజెంట్‌కు ఉండాలి. ఏజెంట్ తేలికగా ఉండటం మరియు అత్యధిక పనితీరును కనబరచడం మధ్య ఈ సున్నితమైన సమతుల్యతను నిరంతరం కొనసాగించాలి.

నెట్‌వర్క్ నష్టం మరియు లేటెన్సీని మనం ఎలా కొలుస్తాము?

ఇది ఒకే ప్రోబ్స్ స్ట్రీమ్ పై ఒక చిన్న లెక్కింపుగా కనిపించవచ్చు, అయితే, పెద్ద స్థాయిలో కొన్ని సవాళ్లు తలెత్తుతాయి, అవి వెంటనే స్పష్టంగా కనిపించవు. ఇంత పెద్ద మెష్‌కు స్కేల్ చేయడానికి, ఏజెంట్ అనేక స్ట్రీమ్‌లపై ఏకకాలంలో వేగంగా మరియు కచ్చితంగా టైమ్‌స్టాంపులతో ట్రాన్స్‌మిట్ (Tx) మరియు రిసీవ్ (Rx) ప్యాకెట్ కౌంట్‌లను లెక్కించాలి. ఏజెంట్ నడుస్తున్న హోస్ట్ యొక్క CPU బిజీగా ఉన్నప్పుడు లేదా దాని నెట్‌వర్క్ బఫర్‌లు ఓవర్‌ఫ్లో అయినప్పుడు కోల్పోయిన ప్యాకెట్‌లను నెట్‌వర్క్ నష్టం కొలమానాలు చేర్చకపోవడం ముఖ్యం. నెట్‌వర్క్ లేటెన్సీని లెక్కించడానికి, ప్రోబ్స్ వైర్‌లో లేదా మధ్యస్థ నెట్‌వర్క్ నోడ్‌లలో ఉన్న మొత్తం సమయాన్ని పరిగణించాలి, అయితే I/O బఫర్‌లలో వేచి ఉన్న సమయం మరియు ఏజెంట్ ప్రాసెస్ OS షెడ్యూలింగ్ కోసం వేచి ఉన్న సమయాన్ని మినహాయించాలి.

రాబ్లాక్స్ యొక్క పింగ్ మెష్ సిస్టమ్

పబ్లిక్ మరియు ప్రైవేట్ క్లౌడ్ మౌలిక సదుపాయాల అభివృద్ధి నుండి బ్లాక్ బాక్స్ నెట్‌వర్క్ నష్టం మరియు లేటెన్సీని పర్యవేక్షించాల్సిన అవసరం ఉంది. మా పెద్ద నెట్‌వర్క్‌కు స్కేల్ చేయగల ఒక ఆఫ్-ది-షెల్ఫ్ పరిష్కారాన్ని కనుగొనడం కష్టంగా నిరూపించబడింది. అనేక పెద్ద క్లౌడ్ ఆపరేటర్లు మరియు నెట్‌వర్క్ టూలింగ్ ప్రొవైడర్లు నెట్‌వర్క్ నష్టం మరియు లేటెన్సీని పర్యవేక్షించడానికి వారి స్వంత పరిష్కారాలను రూపొందించారు. మేము బహిరంగంగా అందుబాటులో ఉన్న కొన్ని సాధనాలను ప్రయత్నించాము, కానీ నెట్‌వర్క్ పనితీరుపై పరిమిత దృశ్యమానతను మాత్రమే పొందుతూ, స్థిరత్వం మరియు స్కేలబిలిటీతో సమస్యలను ఎదుర్కొన్నాము. ఇది తక్కువ ఓవర్‌హెడ్‌తో తక్కువ-ఆवृत्ति దోషాలను మెరుగ్గా గుర్తించే మా స్వంత మెష్ మానిటరింగ్ సిస్టమ్‌ను నిర్మించడానికి దారితీసింది. మా సిస్టమ్ యొక్క కొన్ని ముఖ్యాంశాలు:

• మా సిస్టమ్‌లోని అన్ని కాంపోనెంట్‌లను అమలు చేయడానికి మేము గోను ఎంచుకున్నాము మరియు అది కనీస సిస్టమ్ వనరులను ఉపయోగిస్తూ అధిక స్థాయి పనితీరును సాధించడానికి సహాయపడింది.
• మా ఏజెంట్లు అత్యంత స్థిరంగా ఉంటాయి మరియు ట్రాఫిక్, క్యాషింగ్, మరియు అప్లికేషన్ సర్వర్‌ల వంటి Roblox ప్లాట్‌ఫారమ్‌పై కీలక సేవలను అందించే వాటితో సహా, విస్తృత శ్రేణి ప్రొడక్షన్ హోస్ట్‌లపై నడపవచ్చు.
• Linux sendmmsg() మరియు recvmmsg() సిస్టమ్ కాల్స్‌పై Go ర్యాపర్ ఫంక్షన్‌లతో ప్యాకెట్ I/O ఆపరేషన్‌లను బ్యాచ్ చేయడానికి ఏజెంట్‌ను ఆప్టిమైజ్ చేసారు, ఇది తక్కువ ఓవర్‌హెడ్‌తో అధిక రేటులో ప్రోబ్స్‌ను ప్రసారం చేయడానికి వీలు కల్పిస్తుంది. మా డిప్లాయ్‌మెంట్‌లోని ప్రతి ఏజెంట్ ఒకేసారి 100 ఇతర హోస్ట్‌లకు సెకనుకు 100 ప్యాకెట్ల (PPS) రేటుతో ప్రోబ్స్‌ను ప్రసారం చేస్తుంది. ఏజెంట్ ప్రతి సెకనుకు ప్రతి గమ్యస్థానానికి ప్యాకెట్ బర్స్ట్‌లను ప్రసారం చేస్తుంది.
• ప్రోబ్స్ IP హెడర్‌లో ప్రతి గమ్యస్థానానికి వేర్వేరు టైప్-ఆఫ్-సర్వీస్ (TOS) ఫీల్డ్ విలువలను తీసుకువెళతాయి మరియు నెట్‌వర్క్‌లో ప్యాకెట్ నష్టం మరియు లేటెన్సీ కోసం వేరుగా లెక్కించబడతాయి. ప్రతి ప్యాకెట్ బర్స్ట్‌లో ప్రతి ఇతర గమ్యస్థానానికి బహుళ TOS విలువల మిశ్రమం ఉంటుంది. ఇది విభిన్న క్వాలిటీ-ఆఫ్-సర్వీస్ (QoS) తరగతుల కోసం నెట్‌వర్క్ పనితీరును పర్యవేక్షించడంలో సహాయపడుతుంది.
• ప్రతి ప్రోబ్ మార్గంలో నిమిషానికి 6000 ప్యాకెట్లలో 1 ప్యాకెట్ అనే తక్కువ స్థాయిలో నెట్‌వర్క్ డ్రాప్‌లను ఏజెంట్ గుర్తించగలదు. BGP ఫ్లాప్ సమయంలో జరిగే విధంగా, నెట్‌వర్క్ యొక్క కోర్ లేదా ఎడ్జ్‌లో 1 సెకను కంటే తక్కువ సమయం ఉండే ప్యాకెట్ నష్టాన్ని గుర్తించవచ్చు.
• లోపాల కారణంగా ప్యాకెట్లు డ్రాప్ అయినప్పుడు, ప్రోబ్ ప్యాకెట్ డ్రాప్ చార్టులు నెట్‌వర్క్ పరికర ఇంటర్‌ఫేస్ లోపాల రేట్లను పోలి ఉంటాయి. గుర్తించడం కష్టంగా ఉండే నెట్‌వర్క్‌లోని ట్రాఫిక్ బ్లాక్-హోలింగ్ బగ్‌లను మేము కనుగొనగలిగాము.
• నెట్‌వర్క్ లేటెన్సీ కొలతలలో అధిక కచ్చితత్వాన్ని సాధించడానికి ఏజెంట్లు NIC కెర్నల్ రీడ్ టైమ్‌స్టాంప్‌లను ఉపయోగిస్తాయి. హోస్ట్ OS షెడ్యూలింగ్ లేటెన్సీ మరియు నెట్‌వర్క్ క్లాక్ డ్రిఫ్ట్‌ను మినహాయిస్తూ, 50–100 మైక్రోసెకన్ల స్థిరమైన రౌండ్ ట్రిప్ ఇంట్రా-సైట్ లేటెన్సీని కొలవవచ్చు.
• తక్కువ CPU వినియోగం మరియు మెమరీ ఫుట్‌ప్రింట్. ఏజెంట్ గరిష్ట ట్రాన్స్‌మిట్ మరియు రిసీవ్ రేట్ల వద్ద (ప్రతి ఒక్కటి 5 kpps) ఒక సింగిల్ కోర్ యొక్క 25% కంటే తక్కువగా ఉపయోగిస్తుంది. అమలు చేయబడిన చాలా ఏజెంట్లు ఒక కోర్ యొక్క సుమారు 5% మాత్రమే ఉపయోగిస్తాయి. ఏజెంట్ యొక్క Tx మరియు Rx ప్యాకెట్ బఫర్లు మరియు కౌంటర్లను నిర్వహించడానికి కేవలం 10MB హీప్ మెమరీ అవసరం. నెట్‌వర్క్ పెరిగినప్పుడు, మేము పరిమితులను సర్దుబాటు చేయడం ద్వారా లేదా అదనపు ఏజెంట్లను జోడించడం ద్వారా నిలువుగా లేదా అడ్డంగా స్కేల్ చేయవచ్చు.
• హోస్ట్ సిస్టమ్ ఒత్తిడిలో ఉన్నప్పుడు ఏజెంట్ చాలా అరుదుగా ప్రభావితమవుతుంది. అనేక సందర్భాల్లో హోస్ట్ CPU లోడ్ 99%కి చేరుకున్నప్పుడు కూడా మేము కచ్చితమైన ఫలితాలను పొందాము.
• ప్రతి ఏజెంట్ యొక్క ఆరోగ్యాన్ని పర్యవేక్షించడానికి దాని నుండి టెలిమెట్రీ సేకరించబడుతుంది. హోస్ట్ సిస్టమ్ రీబూట్ అయినప్పుడు, ఏజెంట్ ప్రాసెస్ రీస్టార్ట్ అయినప్పుడు, లేదా సాకెట్ బఫర్లు ఓవర్‌ఫ్లో అవ్వడం వల్ల ప్యాకెట్లు డ్రాప్ అయినప్పుడు వంటి సమస్యాత్మక పరిస్థితులను ఏజెంట్లు గుర్తించగలవు.

నెట్‌వర్క్ ప్రోబింగ్‌లో పాల్గొనే అధిక సంఖ్యలో నోడ్‌లను నిర్వహించడానికి, ఏజెంట్‌లను విస్తృత శ్రేణి సర్వర్ క్లస్టర్‌లపై చెఫ్ (Chef)తో అమలు చేస్తారు. ఏజెంట్ బైనరీ Linuxలో systemdతో నడుస్తుంది మరియు నిర్వహించబడుతుంది, తద్వారా హోస్ట్ రీబూట్ లేదా ఏజెంట్ అప్‌గ్రేడ్ తర్వాత అది ఆటో-రీస్టార్ట్ అవుతుంది. ఏజెంట్లలో ఏదైనా డౌన్ అయినప్పుడు లేదా కొత్తవి వచ్చినప్పుడు, మెష్ షెడ్యూలర్ అవసరమైన విధంగా స్ట్రీమ్‌లను డైనమిక్‌గా గుర్తించి సర్దుబాటు చేస్తుంది. మా షెడ్యూలర్ అప్లికేషన్, ఇంట్రా-పాడ్, ఇంట్రా-సైట్, మరియు ఇంటర్-సైట్ ప్రోబింగ్ కోసం లక్ష్యాలను కేటాయించే ముందు, కొత్త ఏజెంట్‌లను మరియు సర్వర్ ఆరోగ్య స్థితిని గుర్తించడానికి, క్రమానుగతంగా పరికరాల ఇన్వెంటరీని మరియు సర్వీస్ డిస్కవరీ సిస్టమ్‌ను పోల్ చేస్తుంది. టెస్ట్ ప్రోబ్స్‌ను ప్రసారం చేస్తున్న ప్రతి ఏజెంట్‌కు లక్ష్య హోస్ట్ జాబితాను తెలియజేయడానికి ఒక మెసేజ్ బస్ ఉపయోగించబడుతుంది. ఒక నిర్దిష్ట రాక్‌లో ఉద్భవించే లేదా ముగిసే వ్యక్తిగత స్ట్రీమ్‌లు, ఆ రాక్‌లోని అందుబాటులో ఉన్న ఏజెంట్లందరి మధ్య పంపిణీ చేయబడతాయి. ఇది మా నెట్‌వర్క్ ఫ్యాబ్రిక్‌లో, కింద చిత్రాలలో చూపిన విధంగా, పెద్ద మొత్తంలో సమాన వ్యయ మార్గాలను పరీక్షించడానికి మాకు సహాయపడుతుంది.

మేము మా మొదటి డిప్లాయ్‌మెంట్‌లో 150 ఏజెంట్‌లతో ప్రారంభించాము, మరియు ఇప్పుడు విజయవంతంగా 10 రెట్లు విస్తరించాము. ఈ మెష్ ప్రపంచవ్యాప్తంగా విస్తరించి ఉన్న 25 సైట్‌లను అనుసంధానించే మా బ్యాక్‌బోన్‌ను కవర్ చేస్తుంది. మా ప్రాథమిక డేటా సెంటర్ సైట్‌లలో ఒకదానిలో, 200+ రాక్‌లను కవర్ చేసే ఒక ఇంట్రా-సైట్ మెష్ ఉంది, ఇది సుమారు 33,000 స్ట్రీమ్‌లను 1.65 Mpps ప్రోబ్ రేట్‌కు ఏకీకృతం చేస్తుంది. ప్రతి రాక్ ఇతర రాక్‌ల నుండి 5–10 kpps ప్రోబ్‌లను స్వీకరిస్తుంది. షెడ్యూలర్ అప్లికేషన్ లెక్కించి, వివిధ సైట్‌లలోని మా ఏజెంట్లందరిపై 35,000 కంటే ఎక్కువ టార్గెట్‌లను సమానంగా పంపిణీ చేస్తుంది.

డేటా సేకరణ మరియు దృశ్యమానం

మేము ఒక ప్రత్యేక కలెక్టర్ అప్లికేషన్‌ను నడుపుతాము, ఇది ప్యాకెట్ నష్టం మరియు లేటెన్సీ ఫలితాల కోసం అన్ని పింగ్ మెష్ ఏజెంట్లను క్రమానుగతంగా పోల్ చేస్తుంది. కలెక్టర్‌లో స్థానికంగా క్యాష్ చేయబడిన హెల్త్ స్టేట్‌ల ఆధారంగా చెల్లని ఫలితాలను తొలగించడానికి ఈ డేటాను ఆటోమేటిక్‌గా ఫిల్టర్ చేస్తారు. ఉదాహరణకు, హెల్త్ చెక్‌లకు ప్రతిస్పందించని సర్వర్‌లో నడుస్తున్న ఏజెంట్ నుండి లేదా ఇప్పుడే రీబూట్ అయిన సర్వర్ నుండి వచ్చిన ఫలితాలను మేము మినహాయిస్తాము. మా కలెక్టర్ 1,500 కంటే ఎక్కువ నోడ్‌ల నుండి సింక్రోనస్‌గా ఫలితాలను పోల్ చేసి, ఫిల్టర్ చేసి, ఆపై ఆ డేటాను 2 సెకన్లలోపు టైమ్-సిరీస్ డేటాబేస్‌లోకి ఇన్‌జెస్ట్ చేయగలదు.

సమాకృతం చేయబడిన మరియు ప్రతి స్ట్రీమ్ ఫలితాలు గ్రాఫానా డాష్‌బోర్డ్‌ల సహాయంతో దృశ్యమానం చేయబడతాయి. పెద్ద డేటా సెట్‌లతో హీట్‌మ్యాప్ గ్రిడ్‌లను ఉపయోగించడం కష్టంగా ఉంటుంది, ముఖ్యంగా మా పెద్ద డేటా సెంటర్ సైట్ కోసం. వేలాది ఫలితాలలో, సాధారణంగా కేవలం కొన్ని మాత్రమే ఉండే, అత్యధిక వ్యక్తిగత ప్యాకెట్ డ్రాప్ ఉన్న మార్గాలను ప్రదర్శించడానికి మేము ప్రోమిథియస్ topk() క్వెరీని ఉపయోగిస్తాము. కలెక్టర్ ద్వారా తరచుగా పోల్ చేయబడే ఏజెంట్ మరియు హోస్ట్ సిస్టమ్ ఆరోగ్య గణాంకాలతో ఫలితాలను విస్తృతంగా పరిశీలిస్తారు. ప్యాకెట్ డ్రాప్ వైవిధ్యాలు ఎంత పెద్దవి అయినా, ప్రతి వ్యక్తిగత ఫలితంపై ఇది మాకు అధిక స్థాయి విశ్వాసాన్ని ఇస్తుంది. వ్యక్తిగత ఫలితాలను కలిపి చూసినప్పుడు, నెట్‌వర్క్ లోపం ఎక్కడ జరిగిందో అనే దానిపై మాకు ఆధారాలు అందించగలవు. మా మెష్ మానిటరింగ్ సిస్టమ్ ద్వారా పట్టుబడిన ప్యాకెట్ నష్టానికి కొన్ని ఉదాహరణలు క్రింద చూపబడ్డాయి.

సారాంశం మరియు తదుపరి చర్యలు

మా పింగ్ మెష్ సిస్టమ్, నెట్‌వర్క్ ఇంజనీరింగ్ బృందానికి ఎండ్-టు-ఎండ్ ప్యాకెట్ నష్టం మరియు లేటెన్సీని పర్యవేక్షించడానికి ఒక శక్తివంతమైన సాధనంగా ఉంది. ఈ డేటాను "నెట్‌వర్క్ ప్యాకెట్‌లను డ్రాప్ చేస్తోందా?" అనే ప్రశ్నకు తక్షణమే సమాధానం ఇవ్వడానికి ఉపయోగించవచ్చు. మా అనుభవం ఆధారంగా, వినియోగదారులపై ప్రభావం చూపే ప్రధాన నెట్‌వర్క్ సంఘటనలు సాధారణంగా పరికర టెలిమెట్రీ పర్యవేక్షణ వ్యవస్థ ద్వారా గుర్తించబడి, హెచ్చరించబడతాయి. నెట్‌వర్క్ బఫరింగ్‌తో సంబంధం ఉన్న తక్కువ ప్రభావం చూపే, కానీ సంభావ్య సమస్యాత్మక సమస్యలను ఈ సిస్టమ్ వెలుగులోకి తెస్తుంది.

మా సిస్టమ్ రాబ్లాక్స్ క్లౌడ్ నెట్‌వర్క్ యొక్క మొత్తం విశ్వసనీయతపై కూడా అంతర్దృష్టులను అందించగలదు. మా ప్రధాన డేటా సెంటర్ సైట్‌లలో ఒకదానిలో, నెట్‌వర్క్ ఆరోగ్యాన్ని పర్యవేక్షించడానికి మేము నిమిషానికి 100 మిలియన్లకు పైగా ప్రోబ్స్‌ను కలిగి ఉన్నాము మరియు మేము నిమిషానికి 50 కంటే ఎక్కువ ప్యాకెట్ నష్టాల సంఖ్యను చాలా అరుదుగా చూస్తాము. ఇది మా డేటా సెంటర్ నెట్‌వర్క్ నుండి సుమారు 6 9's విశ్వసనీయతను (99.9999%) సూచిస్తుంది. చాలా తరచుగా, 100 మిలియన్ ప్యాకెట్లలో ఎటువంటి ప్యాకెట్ డ్రాప్ గమనించబడదు. గణనీయమైన సంఖ్యలో ప్యాకెట్లు కోల్పోయినప్పుడు, ప్యాకెట్ డ్రాప్ ఎక్కడ మరియు ఎంతకాలం జరిగిందో ఈ సిస్టమ్ అంతర్దృష్టులను అందిస్తుంది. ఒక ఆటో-రిమెడియేషన్ ఇంజిన్ నెట్‌వర్క్‌ను స్వయంగా సరిదిద్దుతుంది మరియు వినియోగదారు ట్రాఫిక్‌ను నెట్‌వర్క్‌లోని వేరొక మార్గం ద్వారా మళ్లించడం ద్వారా అది మరిన్ని డ్రాప్‌లను ఎదుర్కోకుండా నివారిస్తుంది. రాబ్లాక్స్‌లోని నెట్‌వర్కింగ్ బృందం అత్యంత విశ్వసనీయమైన క్లౌడ్ నెట్‌వర్క్‌ను నిర్మించింది.

భవిష్యత్తులో, మేము పరికర టెలిమెట్రీ, సిస్లాగ్‌లు మరియు ఇతర డేటా సెట్‌ల నుండి డేటాను అనుసంధానించడానికి ఒక అనలిటిక్స్ ఇంజిన్‌ను ఉపయోగించాలని భావిస్తున్నాము. అప్పుడు నెట్‌వర్క్ లోపం ఎక్కడ జరిగిందో గుర్తించడంలో సహాయపడటానికి మేము దానిని పింగ్ మెష్ డేటాతో పోల్చాలని ప్లాన్ చేస్తున్నాము. రాబ్లాక్స్ యొక్క క్లౌడ్ నెట్‌వర్క్ విస్తరిస్తూ మరియు అభివృద్ధి చెందుతున్న కొద్దీ, మేము మా ప్రోబింగ్ మెకానిజంలను IPv6 మరియు జంబో ఫ్రేమ్‌లను చేర్చడానికి మెరుగుపరచాలని, అదే సమయంలో ఇంటర్-సైట్ కవరేజీని పెంచడానికి మరిన్ని ఏజెంట్లను జోడించాలని ప్లాన్ చేస్తున్నాము.