కాబట్టి మీరు కొలమానాలను సేకరించండి. మనం ఉన్నాం. మేము కొలమానాలను కూడా సేకరిస్తాము. వాస్తవానికి, వ్యాపారానికి అవసరం. ఈ రోజు మనం మా మానిటరింగ్ సిస్టమ్ యొక్క మొదటి లింక్ గురించి మాట్లాడుతాము - statsd-అనుకూల అగ్రిగేషన్ సర్వర్ , మేము దీన్ని ఎందుకు వ్రాసాము మరియు బ్రూబెక్‌ను ఎందుకు విడిచిపెట్టాము.
మా మునుపటి కథనాల నుండి (, ) మేము ఉపయోగించి మార్కులు సేకరించిన కొంత సమయం వరకు మీరు తెలుసుకోవచ్చు . ఇది C లో వ్రాయబడింది. కోడ్ కోణం నుండి, ఇది ప్లగ్ వలె చాలా సులభం (మీరు సహకారం అందించాలనుకున్నప్పుడు ఇది ముఖ్యమైనది) మరియు, ముఖ్యంగా, ఇది గరిష్టంగా సెకనుకు 2 మిలియన్ మెట్రిక్‌ల (MPS) మా వాల్యూమ్‌లను నిర్వహిస్తుంది ఏ సమస్యలు లేకుండా. డాక్యుమెంటేషన్ నక్షత్రంతో 4 మిలియన్ MPSకి మద్దతునిస్తుంది. దీనర్థం మీరు Linuxలో నెట్‌వర్క్‌ను సరిగ్గా కాన్ఫిగర్ చేస్తే పేర్కొన్న ఫిగర్ మీకు లభిస్తుంది. (మీరు నెట్‌వర్క్‌ను అలాగే వదిలేస్తే మీరు ఎన్ని MPSలను పొందవచ్చో మాకు తెలియదు). ఈ ప్రయోజనాలు ఉన్నప్పటికీ, బ్రూబెక్ గురించి మాకు చాలా తీవ్రమైన ఫిర్యాదులు ఉన్నాయి.
దావా 1. ప్రాజెక్ట్ యొక్క డెవలపర్ అయిన గితుబ్ దీనికి మద్దతు ఇవ్వడం ఆపివేసారు: ప్యాచ్‌లు మరియు పరిష్కారాలను ప్రచురించడం, మాది మరియు (మాది మాత్రమే కాదు) PRని అంగీకరించడం. గత కొన్ని నెలల్లో (ఫిబ్రవరి-మార్చి 2018 నుండి ఎక్కడో), కార్యాచరణ తిరిగి ప్రారంభమైంది, కానీ అంతకు ముందు దాదాపు 2 సంవత్సరాల పూర్తి ప్రశాంతత ఉంది. అదనంగా, ప్రాజెక్ట్ అభివృద్ధి చేయబడింది , ఇది కొత్త ఫీచర్ల పరిచయంకి తీవ్రమైన అడ్డంకిగా మారవచ్చు.
దావా 2. లెక్కల ఖచ్చితత్వం. బ్రూబెక్ అగ్రిగేషన్ కోసం మొత్తం 65536 విలువలను సేకరిస్తుంది. మా విషయంలో, కొన్ని కొలమానాల కోసం, అగ్రిగేషన్ వ్యవధిలో (30 సెకన్లు), చాలా ఎక్కువ విలువలు రావచ్చు (పీక్‌లో 1). ఈ నమూనా ఫలితంగా, గరిష్ట మరియు కనిష్ట విలువలు పనికిరానివిగా కనిపిస్తాయి. ఉదాహరణకు, ఇలా:
ఉన్నట్టుండి
ఎలా వుండాలి
అదే కారణంతో, మొత్తాలు సాధారణంగా తప్పుగా లెక్కించబడతాయి. 32-బిట్ ఫ్లోట్ ఓవర్‌ఫ్లో ఉన్న బగ్‌ను ఇక్కడ జోడించండి, ఇది సాధారణంగా అమాయకమైన మెట్రిక్‌ను స్వీకరించినప్పుడు సర్వర్‌ను సెగ్‌ఫాల్ట్‌కు పంపుతుంది మరియు ప్రతిదీ గొప్పగా మారుతుంది. బగ్, మార్గం ద్వారా, పరిష్కరించబడలేదు.
చివరకు క్లెయిమ్ X. వ్రాస్తున్న సమయంలో, మేము కనుగొనగలిగిన మొత్తం 14 ఎక్కువ లేదా అంతకంటే తక్కువ పని చేస్తున్న గణాంకాల అమలులకు దీన్ని అందించడానికి మేము సిద్ధంగా ఉన్నాము. కొన్ని సింగిల్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లు ఎంతగా పెరిగిపోయాయంటే 4 మిలియన్ MPSని అంగీకరించడం ఇక సరిపోదని ఊహించుకుందాం. లేదా అది ఇంకా పెరగనప్పటికీ, కొలమానాలు మీకు ఇప్పటికే చాలా ముఖ్యమైనవి, చార్ట్‌లలో చిన్న, 2-3 నిమిషాల డిప్‌లు కూడా ఇప్పటికే క్లిష్టంగా మారవచ్చు మరియు మేనేజర్‌లలో అధిగమించలేని నిరాశను కలిగిస్తాయి. నిరాశకు చికిత్స చేయడం కృతజ్ఞత లేని పని కాబట్టి, సాంకేతిక పరిష్కారాలు అవసరం.
ముందుగా, తప్పు సహనం, తద్వారా సర్వర్‌లో ఆకస్మిక సమస్య ఆఫీసులో మనోవిక్షేప జోంబీ అపోకలిప్స్‌కు కారణం కాదు. రెండవది, Linux నెట్‌వర్క్ స్టాక్‌ను లోతుగా త్రవ్వకుండా మరియు అవసరమైన పరిమాణానికి "వెడల్పు"లో ప్రశాంతంగా పెరగకుండా, 4 మిలియన్ కంటే ఎక్కువ MPSని ఆమోదించగలిగేలా స్కేలింగ్.
మేము స్కేలింగ్ కోసం స్థలాన్ని కలిగి ఉన్నందున, మేము తప్పు సహనంతో ప్రారంభించాలని నిర్ణయించుకున్నాము. "గురించి! తప్పు సహనం! ఇది చాలా సులభం, మేము దీన్ని చేయగలము, ”మేము ఆలోచించి 2 సర్వర్‌లను ప్రారంభించాము, ప్రతిదానిపై బ్రూబెక్ కాపీని పెంచాము. దీన్ని చేయడానికి, మేము రెండు సర్వర్‌లకు మెట్రిక్‌లతో ట్రాఫిక్‌ను కాపీ చేయాల్సి వచ్చింది మరియు దీని కోసం కూడా వ్రాయాలి . మేము దీనితో తప్పు సహనం సమస్యను పరిష్కరించాము, కానీ... బాగా లేదు. మొదట ప్రతిదీ గొప్పగా అనిపించింది: ప్రతి బ్రూబెక్ దాని స్వంత అగ్రిగేషన్ సంస్కరణను సేకరిస్తుంది, ప్రతి 30 సెకన్లకు ఒకసారి గ్రాఫైట్‌కు డేటాను వ్రాస్తుంది, పాత విరామాన్ని భర్తీ చేస్తుంది (ఇది గ్రాఫైట్ వైపు చేయబడుతుంది). ఒక సర్వర్ అకస్మాత్తుగా విఫలమైతే, మేము ఎల్లప్పుడూ సమగ్ర డేటా యొక్క స్వంత కాపీతో రెండవదాన్ని కలిగి ఉంటాము. కానీ ఇక్కడ సమస్య ఉంది: సర్వర్ విఫలమైతే, గ్రాఫ్‌లలో “సా” కనిపిస్తుంది. బ్రూబెక్ యొక్క 30-సెకన్ల విరామాలు సమకాలీకరించబడకపోవడం మరియు క్రాష్ సమయంలో వాటిలో ఒకటి భర్తీ చేయబడకపోవడం దీనికి కారణం. రెండవ సర్వర్ ప్రారంభమైనప్పుడు, అదే జరుగుతుంది. చాలా సహించదగినది, కానీ నాకు మంచి కావాలి! స్కేలబిలిటీ సమస్య కూడా తీరలేదు. అన్ని కొలమానాలు ఇప్పటికీ ఒకే సర్వర్‌కు "ఎగురుతున్నాయి", కాబట్టి మేము నెట్‌వర్క్ స్థాయిని బట్టి అదే 2-4 మిలియన్ MPSకి పరిమితం చేస్తాము.
మీరు సమస్య గురించి కొంచెం ఆలోచించి, అదే సమయంలో పారతో మంచును త్రవ్విస్తే, ఈ క్రింది స్పష్టమైన ఆలోచన గుర్తుకు రావచ్చు: మీకు పంపిణీ మోడ్‌లో పని చేసే statsd అవసరం. అంటే, సమయం మరియు మెట్రిక్‌లలో నోడ్‌ల మధ్య సమకాలీకరణను అమలు చేసేది. "అయితే, అటువంటి పరిష్కారం బహుశా ఇప్పటికే ఉంది," అని మేము చెప్పాము మరియు Googleకి వెళ్ళాము…. మరియు వారు ఏమీ కనుగొనలేదు. వివిధ గణాంకాల కోసం డాక్యుమెంటేషన్ ద్వారా వెళ్ళిన తర్వాత ( డిసెంబర్ 11.12.2017, XNUMX నాటికి), మేము ఖచ్చితంగా ఏమీ కనుగొనలేదు. స్పష్టంగా, ఈ పరిష్కారాల డెవలపర్‌లు లేదా వినియోగదారులు ఇంకా చాలా కొలమానాలను ఎదుర్కోలేదు, లేకుంటే వారు ఖచ్చితంగా ఏదో ఒకదానితో ముందుకు వస్తారు.
ఆపై మేము జస్ట్ ఫర్ ఫన్ హ్యాకథాన్‌లో వ్రాసిన “బొమ్మ” స్టాట్స్‌డి - బయోయినో గురించి జ్ఞాపకం చేసుకున్నాము (ప్రాజెక్ట్ పేరు హ్యాకథాన్ ప్రారంభానికి ముందు స్క్రిప్ట్ ద్వారా రూపొందించబడింది) మరియు మాకు అత్యవసరంగా మా స్వంత స్టాట్స్‌డి అవసరమని గ్రహించాము. దేనికోసం?
- ఎందుకంటే ప్రపంచంలో చాలా తక్కువ statsd క్లోన్‌లు ఉన్నాయి,
- ఎందుకంటే కోరుకున్న లేదా కావలసిన తప్పు సహనం మరియు స్కేలబిలిటీకి దగ్గరగా అందించడం సాధ్యమవుతుంది (సర్వర్‌ల మధ్య సమగ్ర కొలమానాలను సమకాలీకరించడం మరియు వైరుధ్యాలను పంపే సమస్యను పరిష్కరించడంతో సహా),
- ఎందుకంటే బ్రూబెక్ కంటే కొలమానాలను మరింత ఖచ్చితంగా లెక్కించడం సాధ్యమవుతుంది,
- ఎందుకంటే బ్రూబెక్ ఆచరణాత్మకంగా మాకు అందించని మరింత వివరణాత్మక గణాంకాలను మీరే సేకరించవచ్చు,
- ఎందుకంటే నా స్వంత హైపర్‌పెర్‌ఫార్మెన్స్ డిస్ట్రిబ్యూటెడ్ స్కేల్ ల్యాబ్ అప్లికేషన్‌ను ప్రోగ్రామ్ చేసే అవకాశం నాకు ఉంది, ఇది మరొక సారూప్య హైపర్‌ఫర్ ఆర్కిటెక్చర్‌ను పూర్తిగా పునరావృతం చేయదు... సరే, అంతే.
దేనిపై వ్రాయాలి? వాస్తవానికి, రస్ట్‌లో. ఎందుకు?
- ఎందుకంటే ఇప్పటికే ఒక నమూనా పరిష్కారం ఉంది,
- ఎందుకంటే వ్యాసం రచయితకు ఆ సమయంలో రస్ట్ గురించి తెలుసు మరియు ఓపెన్ సోర్స్‌లో ఉంచే అవకాశంతో ఉత్పత్తి కోసం దానిలో ఏదైనా వ్రాయడానికి ఆసక్తి కలిగి ఉన్నాడు,
- ఎందుకంటే అందుకున్న ట్రాఫిక్ (దాదాపు నిజ సమయంలో) మరియు GC పాజ్‌లు ఆచరణాత్మకంగా ఆమోదయోగ్యం కాని కారణంగా GC ఉన్న భాషలు మనకు సరిపోవు,
- ఎందుకంటే మీకు సితో పోల్చదగిన గరిష్ట పనితీరు అవసరం
- ఎందుకంటే రస్ట్ మనకు నిర్భయమైన సమ్మతిని అందిస్తుంది, మరియు మేము దానిని C/C++లో రాయడం ప్రారంభించినట్లయితే, మేము బ్రూబెక్ కంటే మరింత దుర్బలత్వం, బఫర్ ఓవర్‌ఫ్లోలు, రేస్ పరిస్థితులు మరియు ఇతర భయానక పదాలను ఎదుర్కొంటాము.
రస్ట్‌కు వ్యతిరేకంగా వాదన కూడా జరిగింది. రస్ట్‌లో ప్రాజెక్ట్‌లను రూపొందించడంలో కంపెనీకి అనుభవం లేదు మరియు ఇప్పుడు మేము దానిని ప్రధాన ప్రాజెక్ట్‌లో ఉపయోగించడానికి కూడా ప్లాన్ చేయము. అందువల్ల, ఏమీ పని చేయదని తీవ్రమైన భయాలు ఉన్నాయి, కాని మేము ఒక అవకాశం తీసుకోవాలని నిర్ణయించుకున్నాము మరియు ప్రయత్నించాము.
సమయం ముగిసింది...
చివరగా, అనేక విఫల ప్రయత్నాల తర్వాత, మొదటి పని వెర్షన్ సిద్ధంగా ఉంది. ఏం జరిగింది? ఇదే జరిగింది.
ప్రతి నోడ్ దాని స్వంత కొలమానాలను అందుకుంటుంది మరియు వాటిని సంచితం చేస్తుంది మరియు తుది అగ్రిగేషన్ కోసం వాటి పూర్తి సెట్ అవసరమయ్యే రకానికి కొలమానాలను సమగ్రపరచదు. నోడ్‌లు ఒకదానికొకటి పంపిణీ చేయబడిన లాక్ ప్రోటోకాల్ ద్వారా ఒకదానికొకటి అనుసంధానించబడి ఉంటాయి, ఇది గ్రేట్ వన్‌కు కొలమానాలను పంపడానికి అర్హమైన వాటిని మాత్రమే (ఇక్కడ మేము అరిచాము) ఎంచుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. ఈ సమస్య ప్రస్తుతం పరిష్కరించబడుతోంది , కానీ భవిష్యత్తులో రచయిత ఆశయాలు విస్తరించాయి తెప్ప, ఇక్కడ అత్యంత విలువైన వ్యక్తి ఏకాభిప్రాయ నాయకుని నోడ్‌గా ఉంటాడు. ఏకాభిప్రాయంతో పాటు, నోడ్‌లు చాలా తరచుగా (డిఫాల్ట్‌గా సెకనుకు ఒకసారి) తమ పొరుగువారికి ఆ సెకనులో సేకరించగలిగిన ప్రీ-అగ్రిగేటెడ్ మెట్రిక్‌ల భాగాలను పంపుతాయి. స్కేలింగ్ మరియు ఫాల్ట్ టాలరెన్స్ సంరక్షించబడిందని తేలింది - ప్రతి నోడ్ ఇప్పటికీ పూర్తి స్థాయి కొలమానాలను కలిగి ఉంది, అయితే కొలమానాలు ఇప్పటికే TCP ద్వారా సమగ్రంగా పంపబడతాయి మరియు బైనరీ ప్రోటోకాల్‌లోకి ఎన్‌కోడ్ చేయబడతాయి, కాబట్టి UDPతో పోలిస్తే నకిలీ ఖర్చులు గణనీయంగా తగ్గుతాయి. చాలా పెద్ద సంఖ్యలో ఇన్‌కమింగ్ మెట్రిక్‌లు ఉన్నప్పటికీ, సంచితం చాలా తక్కువ మెమరీ మరియు తక్కువ CPU అవసరం. మా అత్యంత కంప్రెసిబుల్ మెర్టిక్స్ కోసం, ఇది కొన్ని పదుల మెగాబైట్ల డేటా మాత్రమే. అదనపు బోనస్‌గా, బర్బెక్‌లో జరిగినట్లుగా గ్రాఫైట్‌లో అనవసరమైన డేటా రీరైట్‌లను మేము పొందలేము.
మెట్రిక్‌లతో కూడిన UDP ప్యాకెట్‌లు సాధారణ రౌండ్ రాబిన్ ద్వారా నెట్‌వర్క్ పరికరాల్లో నోడ్‌ల మధ్య అసమతుల్యతతో ఉంటాయి. వాస్తవానికి, నెట్‌వర్క్ హార్డ్‌వేర్ ప్యాకెట్ల కంటెంట్‌లను అన్వయించదు మరియు అందువల్ల సెకనుకు 4M ప్యాకెట్ల కంటే ఎక్కువ లాగగలదు, దాని గురించి ఏమీ తెలియని కొలమానాలను ప్రత్యేకంగా చెప్పనక్కర్లేదు. ప్రతి ప్యాకెట్‌లో కొలమానాలు ఒకదానికొకటి రావని మేము పరిగణనలోకి తీసుకుంటే, ఈ స్థలంలో పనితీరు సమస్యలను మేము ఊహించలేము. సర్వర్ క్రాష్ అయినట్లయితే, నెట్‌వర్క్ పరికరం త్వరగా (1-2 సెకన్లలోపు) ఈ వాస్తవాన్ని గుర్తించి, క్రాష్ అయిన సర్వర్‌ను భ్రమణ నుండి తొలగిస్తుంది. దీని ఫలితంగా, చార్ట్‌లలో డ్రాడౌన్‌లను గమనించకుండా నిష్క్రియ (అంటే, నాన్-లీడర్) నోడ్‌లను ఆచరణాత్మకంగా ఆన్ మరియు ఆఫ్ చేయవచ్చు. మనం కోల్పోయే గరిష్టం చివరి సెకనులో వచ్చిన కొలమానాలలో భాగం. లీడర్ యొక్క ఆకస్మిక నష్టం/షట్‌డౌన్/స్విచ్ ఇప్పటికీ చిన్న క్రమరాహిత్యాన్ని సృష్టిస్తుంది (30 సెకన్ల విరామం ఇప్పటికీ సమకాలీకరించబడలేదు), కానీ నోడ్‌ల మధ్య కమ్యూనికేషన్ ఉంటే, ఈ సమస్యలను తగ్గించవచ్చు, ఉదాహరణకు, సింక్రొనైజేషన్ ప్యాకెట్‌లను పంపడం ద్వారా .
అంతర్గత నిర్మాణం గురించి కొంచెం. అప్లికేషన్, వాస్తవానికి, మల్టీథ్రెడ్ చేయబడింది, అయితే థ్రెడింగ్ ఆర్కిటెక్చర్ బ్రూబెక్‌లో ఉపయోగించిన దానికంటే భిన్నంగా ఉంటుంది. బ్రూబెక్‌లోని థ్రెడ్‌లు ఒకే విధంగా ఉంటాయి - వాటిలో ప్రతి ఒక్కటి సమాచార సేకరణ మరియు సంకలనం రెండింటికీ బాధ్యత వహిస్తుంది. బయోయినోలో, కార్మికులు రెండు గ్రూపులుగా విభజించబడ్డారు: నెట్‌వర్క్‌కు బాధ్యులు మరియు అగ్రిగేషన్‌కు బాధ్యులు. మెట్రిక్‌ల రకాన్ని బట్టి అనువర్తనాన్ని మరింత సరళంగా నిర్వహించడానికి ఈ విభాగం మిమ్మల్ని అనుమతిస్తుంది: ఇంటెన్సివ్ అగ్రిగేషన్ అవసరమైన చోట, మీరు అగ్రిగేటర్‌లను జోడించవచ్చు, నెట్‌వర్క్ ట్రాఫిక్ ఎక్కువగా ఉన్న చోట, మీరు నెట్‌వర్క్ ప్రవాహాల సంఖ్యను జోడించవచ్చు. ప్రస్తుతానికి, మా సర్వర్‌లలో మేము 8 నెట్‌వర్క్ మరియు 4 అగ్రిగేషన్ ఫ్లోలలో పని చేస్తాము.
లెక్కింపు (అగ్రిగేషన్‌కు బాధ్యత) భాగం చాలా బోరింగ్‌గా ఉంది. నెట్‌వర్క్ ప్రవాహాల ద్వారా నిండిన బఫర్‌లు లెక్కింపు ప్రవాహాల మధ్య పంపిణీ చేయబడతాయి, ఇక్కడ అవి తరువాత అన్వయించబడతాయి మరియు సమగ్రపరచబడతాయి. అభ్యర్థనపై, ఇతర నోడ్‌లకు పంపడానికి కొలమానాలు ఇవ్వబడతాయి. నోడ్‌ల మధ్య డేటాను పంపడం మరియు కాన్సుల్‌తో పని చేయడంతో సహా ఇవన్నీ ఫ్రేమ్‌వర్క్‌లో అమలవుతాయి. .
మెట్రిక్‌లను స్వీకరించడానికి బాధ్యత వహించే నెట్‌వర్క్ భాగం వల్ల అభివృద్ధి సమయంలో చాలా సమస్యలు తలెత్తాయి. నెట్‌వర్క్ ప్రవాహాలను వేర్వేరు ఎంటిటీలుగా విభజించే ప్రధాన లక్ష్యం ప్రవాహం గడిపే సమయాన్ని తగ్గించాలనే కోరిక కాదు సాకెట్ నుండి డేటాను చదవడానికి. అసమకాలిక UDP మరియు సాధారణ recvmsgని ఉపయోగించే ఎంపికలు త్వరగా అదృశ్యమయ్యాయి: మొదటిది ఈవెంట్ ప్రాసెసింగ్ కోసం చాలా ఎక్కువ యూజర్-స్పేస్ CPUని వినియోగిస్తుంది, రెండవదానికి చాలా సందర్భ స్విచ్‌లు అవసరం. అందుకే ఇప్పుడు వాడుతున్నారు పెద్ద బఫర్‌లతో (మరియు బఫర్‌లు, పెద్దమనుషులు అధికారులు, మీకు ఏమీ కాదు!). recvmmsg అవసరం లేని లైట్ కేసుల కోసం సాధారణ UDP కోసం సపోర్ట్ రిజర్వ్ చేయబడింది. మల్టీమెసేజ్ మోడ్‌లో, ప్రధాన విషయం సాధించడం సాధ్యపడుతుంది: ఎక్కువ సమయం, నెట్‌వర్క్ థ్రెడ్ OS క్యూను రేక్ చేస్తుంది - సాకెట్ నుండి డేటాను రీడ్ చేస్తుంది మరియు యూజర్‌స్పేస్ బఫర్‌కు బదిలీ చేస్తుంది, అప్పుడప్పుడు మాత్రమే నింపిన బఫర్‌ను ఇవ్వడానికి మారుతుంది అగ్రిగేటర్లు. సాకెట్‌లోని క్యూ ఆచరణాత్మకంగా పేరుకుపోదు, పడిపోయిన ప్యాకెట్ల సంఖ్య ఆచరణాత్మకంగా పెరగదు.
వ్యాఖ్య
డిఫాల్ట్ సెట్టింగ్‌లలో, బఫర్ పరిమాణం చాలా పెద్దదిగా సెట్ చేయబడింది. మీరు అకస్మాత్తుగా సర్వర్‌ను మీరే ప్రయత్నించాలని నిర్ణయించుకుంటే, తక్కువ సంఖ్యలో కొలమానాలను పంపిన తర్వాత, అవి నెట్‌వర్క్ స్ట్రీమ్ బఫర్‌లో మిగిలి ఉన్న గ్రాఫైట్‌లో చేరవు అనే వాస్తవాన్ని మీరు ఎదుర్కోవచ్చు. తక్కువ సంఖ్యలో కొలమానాలతో పని చేయడానికి, మీరు కాన్ఫిగర్‌లో బఫ్‌సైజ్ మరియు టాస్క్-క్యూ-సైజ్‌ని చిన్న విలువలకు సెట్ చేయాలి.
చివరగా, చార్ట్ ప్రియుల కోసం కొన్ని చార్ట్‌లు.
ప్రతి సర్వర్‌కు ఇన్‌కమింగ్ మెట్రిక్‌ల సంఖ్యపై గణాంకాలు: 2 మిలియన్ కంటే ఎక్కువ MPS.
నోడ్‌లలో ఒకదానిని నిలిపివేయడం మరియు ఇన్‌కమింగ్ మెట్రిక్‌లను పునఃపంపిణీ చేయడం.
అవుట్‌గోయింగ్ మెట్రిక్‌లపై గణాంకాలు: ఎల్లప్పుడూ ఒక నోడ్ మాత్రమే పంపుతుంది - రైడ్ బాస్.
ప్రతి నోడ్ యొక్క ఆపరేషన్ యొక్క గణాంకాలు, వివిధ సిస్టమ్ మాడ్యూళ్ళలో లోపాలను పరిగణనలోకి తీసుకుంటాయి.
ఇన్‌కమింగ్ మెట్రిక్‌ల వివరాలు (మెట్రిక్ పేర్లు దాచబడ్డాయి).
వీటన్నింటితో మనం తదుపరి ఏమి చేయాలని ప్లాన్ చేస్తున్నాము? అఫ్ కోర్స్ కోడ్ రాయండి పాడు...! ప్రాజెక్ట్ మొదట ఓపెన్ సోర్స్‌గా ప్లాన్ చేయబడింది మరియు దాని జీవితాంతం అలాగే ఉంటుంది. మా తక్షణ ప్రణాళికలలో మా స్వంత రాఫ్ట్ వెర్షన్‌కు మారడం, పీర్ ప్రోటోకాల్‌ను మరింత పోర్టబుల్‌గా మార్చడం, అదనపు అంతర్గత గణాంకాలను పరిచయం చేయడం, కొత్త రకాల కొలమానాలు, బగ్ పరిష్కారాలు మరియు ఇతర మెరుగుదలలు ఉన్నాయి.
వాస్తవానికి, ప్రాజెక్ట్ అభివృద్ధిలో సహాయం చేయడానికి ప్రతి ఒక్కరూ స్వాగతం పలుకుతారు: PR, సమస్యలను సృష్టించండి, వీలైతే మేము ప్రతిస్పందిస్తాము, మెరుగుపరుస్తాము, మొదలైనవి.
ఇలా చెప్పుకుంటూ పోతే, మా ఏనుగులను కొనుక్కోండి అంతే!
మూలం: www.habr.com