సేవగా పర్యవేక్షణ: మైక్రోసర్వీస్ ఆర్కిటెక్చర్ కోసం మాడ్యులర్ సిస్టమ్

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

ఈ పోస్ట్ మాతో నా ప్రసంగం యొక్క లిప్యంతరీకరణ విభాగాలు RIT++ వద్ద. అక్కడ నుండి నివేదికల టెక్స్ట్ వెర్షన్‌లను తయారు చేయమని చాలా మంది మమ్మల్ని కోరారు. మీరు కాన్ఫరెన్స్‌లో ఉన్నట్లయితే లేదా వీడియోను వీక్షించినట్లయితే, మీకు కొత్తగా ఏమీ కనిపించదు. మరియు ప్రతి ఒక్కరూ - పిల్లికి స్వాగతం. మేము అటువంటి సిస్టమ్‌కు ఎలా వచ్చామో, అది ఎలా పని చేస్తుంది మరియు దాన్ని ఎలా అప్‌డేట్ చేయాలని ప్లాన్ చేస్తున్నామో నేను మీకు చెప్తాను.

గతం: పథకాలు మరియు ప్రణాళికలు

మేము ప్రస్తుత పర్యవేక్షణ వ్యవస్థకు ఎలా వచ్చాము? ఈ ప్రశ్నకు సమాధానమివ్వడానికి, మీరు 2015కి వెళ్లాలి. అప్పుడు ఇలా కనిపించింది:

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

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

ప్రమాణం: మానిటరింగ్ 2.0

2015లో ప్రణాళికలు ఇలా ఉన్నాయి. అయితే మేము మౌలిక సదుపాయాలు మరియు సేవను మాత్రమే కాకుండా, దానికి సంబంధించిన డాక్యుమెంటేషన్‌ను కూడా సిద్ధం చేయాల్సి వచ్చింది. మేము మా కోసం కార్పొరేట్ ప్రమాణాన్ని అభివృద్ధి చేసాము, దానిని మేము పర్యవేక్షణ 2.0 అని పిలుస్తాము. సిస్టమ్ అవసరాలు ఏమిటి?

• స్థిరమైన లభ్యత;
• కొలమానాల నిల్వ విరామం = 10 సెకన్లు;
• మెట్రిక్స్ మరియు డాష్‌బోర్డ్‌ల నిర్మాణాత్మక నిల్వ;
• SLA > 99,99%
• UDP (!) ద్వారా ఈవెంట్ మెట్రిక్‌ల సేకరణ

మాకు UDP అవసరం ఎందుకంటే మా వద్ద ట్రాఫిక్ మరియు మెట్రిక్‌లను రూపొందించే ఈవెంట్‌లు ఎక్కువగా ఉన్నాయి. మీరు వాటన్నింటినీ ఒకేసారి గ్రాఫైట్‌లో వ్రాస్తే, నిల్వ కూలిపోతుంది. మేము అన్ని కొలమానాల కోసం మొదటి-స్థాయి ప్రిఫిక్స్‌లను కూడా ఎంచుకున్నాము.

ప్రతి ఉపసర్గకు కొంత ఆస్తి ఉంటుంది. సర్వర్‌లు, నెట్‌వర్క్‌లు, కంటైనర్‌లు, వనరులు, అప్లికేషన్‌లు మొదలైన వాటి కోసం కొలమానాలు ఉన్నాయి. స్పష్టమైన, కఠినమైన, టైప్ చేసిన ఫిల్టరింగ్ అమలు చేయబడింది, ఇక్కడ మేము మొదటి-స్థాయి కొలమానాలను అంగీకరిస్తాము మరియు మిగిలిన వాటిని వదిలివేస్తాము. మేము 2015లో ఈ విధానాన్ని ఇలా ప్లాన్ చేసాము. వర్తమానంలో ఏముంది?

ప్రస్తుతం: పర్యవేక్షణ భాగాల పరస్పర చర్య యొక్క రేఖాచిత్రం

అన్నింటిలో మొదటిది, మేము అప్లికేషన్లను పర్యవేక్షిస్తాము: మా PHP కోడ్, అప్లికేషన్లు మరియు మైక్రోసర్వీసెస్ - సంక్షిప్తంగా, మా డెవలపర్లు వ్రాసే ప్రతిదీ. అన్ని అప్లికేషన్‌లు UDP ద్వారా Brubeck అగ్రిగేటర్‌కి మెట్రిక్‌లను పంపుతాయి (statsd, Cలో తిరిగి వ్రాయబడింది). సింథటిక్ పరీక్షల్లో ఇది అత్యంత వేగవంతమైనదిగా తేలింది. మరియు ఇది TCP ద్వారా గ్రాఫైట్‌కి ఇప్పటికే సమగ్రమైన కొలమానాలను పంపుతుంది.

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

మేము హార్డ్‌వేర్, సాఫ్ట్‌వేర్, సిస్టమ్ మెట్రిక్‌లు మరియు మా పాత మునిన్ మానిటరింగ్ సిస్టమ్ (ఇది 2015 వరకు మా కోసం పని చేసింది)పై కొలమానాల కోసం అగ్రిగేషన్ కూడా కలిగి ఉంది. మేము C డెమోన్ CollectD ద్వారా వీటన్నింటిని సేకరిస్తాము (దీనిలో విభిన్న ప్లగిన్‌ల మొత్తం సమూహాన్ని కలిగి ఉంది, ఇది ఇన్‌స్టాల్ చేయబడిన హోస్ట్ సిస్టమ్ యొక్క అన్ని వనరులను పోల్ చేయగలదు, డేటాను ఎక్కడ వ్రాయాలో కాన్ఫిగరేషన్‌లో పేర్కొనండి) మరియు దాని ద్వారా గ్రాఫైట్‌కు డేటాను వ్రాయండి. ఇది పైథాన్ ప్లగిన్‌లు మరియు షెల్ స్క్రిప్ట్‌లకు కూడా మద్దతు ఇస్తుంది, కాబట్టి మీరు మీ స్వంత కస్టమ్ సొల్యూషన్‌లను వ్రాయవచ్చు: CollectD ఈ డేటాను స్థానిక లేదా రిమోట్ హోస్ట్ నుండి సేకరించి (కర్ల్ ఊహించి) గ్రాఫైట్‌కి పంపుతుంది.

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

కార్బన్-సి-రిలే అప్పుడు గ్రాఫైట్ క్లస్టర్‌కు కొలమానాలను పంపుతుంది. మేము Goలో తిరిగి వ్రాయబడిన కార్బన్-కాష్‌ని మెట్రిక్‌ల యొక్క ప్రధాన నిల్వగా ఉపయోగిస్తాము. గో-కార్బన్, దాని మల్టీథ్రెడింగ్ కారణంగా, కార్బన్-కాష్‌ని మించిపోయింది. ఇది డేటాను స్వీకరిస్తుంది మరియు విష్పర్ ప్యాకేజీని ఉపయోగించి డిస్క్‌లకు వ్రాస్తుంది (ప్రామాణికం, పైథాన్‌లో వ్రాయబడింది). మా నిల్వల నుండి డేటాను చదవడానికి, మేము గ్రాఫైట్ APIని ఉపయోగిస్తాము. ఇది ప్రామాణిక గ్రాఫైట్ WEB కంటే చాలా వేగంగా ఉంటుంది. తదుపరి డేటాకు ఏమి జరుగుతుంది?

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

మరింత ముందుకు వెళ్దాం: హెచ్చరిక. ఇది బలమైన వ్యవస్థను ఉపయోగించి నిర్వహించబడుతుంది - మోయిరా. హుడ్ కింద దాని స్వంత గ్రాఫైట్ ఉన్నందున ఇది స్వతంత్రంగా ఉంటుంది. పూర్తిగా ఓపెన్ సోర్స్‌లో పైథాన్ మరియు గోలో వ్రాయబడిన SKB "కొంటూర్" కుర్రాళ్లచే అభివృద్ధి చేయబడింది. మోయిరా గ్రాఫైట్‌లలోకి వెళ్ళే అదే ప్రవాహాన్ని అందుకుంటుంది. కొన్ని కారణాల వల్ల మీ స్టోరేజ్ చనిపోతే, మీ అలర్ట్ చేయడం ఇప్పటికీ పని చేస్తుంది.

మేము మోయిరాను కుబెర్నెటెస్‌లో నియమించాము; ఇది ప్రధాన డేటాబేస్‌గా Redis సర్వర్‌ల క్లస్టర్‌ను ఉపయోగిస్తుంది. ఫలితంగా తప్పులను తట్టుకునే వ్యవస్థ ఏర్పడింది. ఇది మెట్రిక్‌ల స్ట్రీమ్‌ను ట్రిగ్గర్‌ల జాబితాతో పోలుస్తుంది: అందులో ప్రస్తావనలు లేకుంటే, అది మెట్రిక్‌ను తగ్గిస్తుంది. కాబట్టి ఇది నిమిషానికి గిగాబైట్ల కొలమానాలను జీర్ణం చేయగలదు.

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

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

సరే, మేము ప్రగతిశీల సంస్థ కాబట్టి, మేము ఈ సిస్టమ్‌లో కుబెర్నెట్‌లను కూడా పర్యవేక్షించాము. మేము క్లస్టర్‌లో ఇన్‌స్టాల్ చేసిన హీప్‌స్టర్‌ని ఉపయోగించి సిస్టమ్‌లో చేర్చాము, ఇది డేటాను సేకరిస్తుంది మరియు గ్రాఫైట్‌కు పంపుతుంది. ఫలితంగా, రేఖాచిత్రం ఇలా కనిపిస్తుంది:

మానిటరింగ్ భాగాలు

ఈ టాస్క్ కోసం మేము ఉపయోగించిన భాగాలకు లింక్‌ల జాబితా ఇక్కడ ఉంది. అవన్నీ ఓపెన్ సోర్స్.

గ్రాఫైట్:

• గో-కార్బన్: github.com/lomik/go-carbon
• గుసగుస: github.com/graphite-project/whisper
• గ్రాఫైట్-api: github.com/brutasse/graphite-api

కార్బన్-సి-రిలే:

github.com/grobian/carbon-c-relay

బ్రూబెక్:

github.com/github/brubeck

సేకరించినవి:

సేకరించిన.org

మొయిరా:

github.com/moira-alert

గ్రాఫానా:

grafana.com

హీప్‌స్టర్:

github.com/kubernetes/heapster

గణాంకాలు

మరియు సిస్టమ్ మాకు ఎలా పని చేస్తుందనే దాని గురించి ఇక్కడ కొన్ని సంఖ్యలు ఉన్నాయి.

అగ్రిగేటర్ (బ్రూబెక్)

కొలమానాల సంఖ్య: ~300/సెక
గ్రాఫైట్‌కి మెట్రిక్‌లను పంపడానికి విరామం: 30 సె
సర్వర్ వనరుల వినియోగం: ~ 6% CPU (మేము పూర్తి స్థాయి సర్వర్‌ల గురించి మాట్లాడుతున్నాము); ~ 1Gb RAM; ~3 Mbps LAN

గ్రాఫైట్ (గో-కార్బన్)

కొలమానాల సంఖ్య: ~ 1 / నిమి
కొలమానాల నవీకరణ విరామం: 30 సెకన్లు
మెట్రిక్స్ స్టోరేజ్ స్కీమ్: 30సెకన్ 35డి, 5నిమి 90డి, 10నిమి 365డి (దీర్ఘకాలం పాటు సేవకు ఏమి జరుగుతుందో మీకు అవగాహన కల్పిస్తుంది)
సర్వర్ వనరుల వినియోగం: ~10% CPU; ~ 20Gb RAM; ~30 Mbps LAN

వశ్యత

Avito వద్ద మేము మా పర్యవేక్షణ సేవలో వశ్యతను నిజంగా విలువైనదిగా చేస్తాము. అసలు ఎందుకు ఇలా మారిపోయాడు? మొదట, దాని భాగాలు పరస్పరం మార్చుకోగలవు: భాగాలు మరియు వాటి సంస్కరణలు రెండూ. రెండవది, మద్దతు. మొత్తం ప్రాజెక్ట్ ఓపెన్ సోర్స్ అయినందున, మీరు కోడ్‌ను మీరే సవరించవచ్చు, మార్పులు చేయవచ్చు మరియు బాక్స్ వెలుపల అందుబాటులో లేని ఫంక్షన్‌లను అమలు చేయవచ్చు. చాలా సాధారణ స్టాక్‌లు ఉపయోగించబడతాయి, ప్రధానంగా గో మరియు పైథాన్, కాబట్టి ఇది చాలా సరళంగా చేయబడుతుంది.

ఇక్కడ నిజమైన సమస్య యొక్క ఉదాహరణ. గ్రాఫైట్‌లో మెట్రిక్ అనేది ఫైల్. దానికి ఒక పేరు ఉంది. ఫైల్ పేరు = మెట్రిక్ పేరు. మరియు అక్కడికి చేరుకోవడానికి ఒక మార్గం ఉంది. Linuxలో ఫైల్ పేర్లు 255 అక్షరాలకు పరిమితం చేయబడ్డాయి. మరియు మేము డేటాబేస్ డిపార్ట్‌మెంట్ నుండి ("అంతర్గత కస్టమర్‌లుగా") అబ్బాయిలను కలిగి ఉన్నాము. వారు మాకు ఇలా చెప్పారు: “మేము మా SQL ప్రశ్నలను పర్యవేక్షించాలనుకుంటున్నాము. మరియు అవి 255 అక్షరాలు కాదు, ఒక్కొక్కటి 8 MB. మేము వాటిని గ్రాఫానాలో ప్రదర్శించాలనుకుంటున్నాము, ఈ అభ్యర్థన కోసం పారామితులను చూడండి మరియు ఇంకా ఉత్తమంగా, మేము అటువంటి అభ్యర్థనలలో ఎగువన చూడాలనుకుంటున్నాము. ఇది నిజ సమయంలో ప్రదర్శించబడితే చాలా బాగుంటుంది. వారిని అప్రమత్తంగా ఉంచడం చాలా బాగుంది. ”

ఉదాహరణ SQL ప్రశ్న నుండి ఉదాహరణగా తీసుకోబడింది సైట్ postgrespro.ru

మేము Redis సర్వర్‌ని సెటప్ చేస్తాము మరియు మా సేకరించిన ప్లగిన్‌లను ఉపయోగిస్తాము, అవి పోస్ట్‌గ్రెస్‌కి వెళ్లి అక్కడ నుండి మొత్తం డేటాను తీసుకుని, గ్రాఫైట్‌కి కొలమానాలను పంపుతాము. కానీ మేము మెట్రిక్ పేరును హాష్‌లతో భర్తీ చేస్తాము. మేము ఏకకాలంలో అదే హాష్‌ని Redisకి కీగా మరియు మొత్తం SQL ప్రశ్నను విలువగా పంపుతాము. మేము చేయాల్సిందల్లా గ్రాఫానా రెడిస్‌కి వెళ్లి ఈ సమాచారాన్ని తీసుకోగలదని నిర్ధారించుకోవడం. మేము గ్రాఫైట్ APIని తెరుస్తున్నాము ఎందుకంటే... గ్రాఫైట్‌తో అన్ని మానిటరింగ్ భాగాల పరస్పర చర్యకు ఇది ప్రధాన ఇంటర్‌ఫేస్, మరియు మేము అక్కడ అలియాస్‌బైహాష్() అనే కొత్త ఫంక్షన్‌ని నమోదు చేస్తాము - గ్రాఫానా నుండి మనకు మెట్రిక్ పేరు వస్తుంది మరియు దానిని రెడిస్‌కి చేసిన అభ్యర్థనలో కీగా ఉపయోగిస్తాము. ప్రతిస్పందన మేము కీ యొక్క విలువను పొందుతాము, ఇది మా “SQL ప్రశ్న” " అందువలన, మేము గ్రాఫానాలో ఒక SQL ప్రశ్న యొక్క ప్రదర్శనను ప్రదర్శించాము, సిద్ధాంతపరంగా దానిపై గణాంకాలతో పాటు (కాల్స్, అడ్డు వరుసలు, మొత్తం_సమయం, ...) ప్రదర్శించడం అసాధ్యం.

ఫలితాలు

లభ్యత. మా పర్యవేక్షణ సేవ ఏదైనా అప్లికేషన్ మరియు ఏదైనా కోడ్ నుండి 24/7 అందుబాటులో ఉంటుంది. మీకు నిల్వ సౌకర్యాలకు ప్రాప్యత ఉంటే, మీరు సేవకు డేటాను వ్రాయవచ్చు. భాష ముఖ్యం కాదు, నిర్ణయాలు ముఖ్యం కాదు. మీరు సాకెట్‌ను ఎలా తెరవాలో మాత్రమే తెలుసుకోవాలి, అక్కడ ఒక మెట్రిక్ ఉంచండి మరియు సాకెట్‌ను మూసివేయండి.

విశ్వసనీయత. అన్ని భాగాలు తప్పులను తట్టుకోగలవు మరియు మా లోడ్‌లను బాగా నిర్వహిస్తాయి.

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

స్వాతంత్ర్యం. DevOps ఇంజనీర్ల సహాయం లేకుండా మీరు ఇవన్నీ మీరే చేయవచ్చు. మరియు ఇది ఒక ప్రయోజనం, ఎందుకంటే మీరు ప్రస్తుతం మీ ప్రాజెక్ట్‌ను పర్యవేక్షించగలరు, మీరు ఎవరినీ అడగవలసిన అవసరం లేదు - పనిని ప్రారంభించడానికి లేదా మార్పులు చేయడానికి.

మనం దేనిని లక్ష్యంగా చేసుకున్నాము?

క్రింద జాబితా చేయబడినవన్నీ కేవలం నైరూప్య ఆలోచనలు మాత్రమే కాదు, కనీసం మొదటి అడుగులు వేయబడినవి.

1. అనోమలీ డిటెక్టర్. మేము మా గ్రాఫైట్ స్టోరేజ్‌లకు వెళ్లి వివిధ అల్గారిథమ్‌లను ఉపయోగించి ప్రతి మెట్రిక్‌ని తనిఖీ చేసే సేవను సృష్టించాలనుకుంటున్నాము. మేము చూడాలనుకుంటున్న అల్గారిథమ్‌లు ఇప్పటికే ఉన్నాయి, డేటా ఉంది, దానితో ఎలా పని చేయాలో మాకు తెలుసు.
2. మెటాడేటా. మాకు చాలా సేవలు ఉన్నాయి, వారితో పనిచేసే వ్యక్తుల మాదిరిగానే అవి కాలానుగుణంగా మారుతాయి. మాన్యువల్‌గా డాక్యుమెంటేషన్‌ను నిరంతరం నిర్వహించడం ఒక ఎంపిక కాదు. అందుకే మేము ఇప్పుడు మా మైక్రోసర్వీస్‌లలో మెటాడేటాను పొందుపరుస్తున్నాము. దీన్ని ఎవరు అభివృద్ధి చేశారో, దానితో సంభాషించే భాషలు, SLA అవసరాలు, నోటిఫికేషన్‌లు ఎక్కడ మరియు ఎవరికి పంపబడాలి అని ఇది పేర్కొంది. సేవను అమలు చేస్తున్నప్పుడు, మొత్తం ఎంటిటీ డేటా స్వతంత్రంగా సృష్టించబడుతుంది. ఫలితంగా, మీరు రెండు లింక్‌లను పొందుతారు - ఒకటి ట్రిగ్గర్‌లకు, మరొకటి గ్రాఫానాలోని డాష్‌బోర్డ్‌లకు.
3. ప్రతి ఇంటిలో పర్యవేక్షణ. డెవలపర్‌లందరూ అలాంటి వ్యవస్థను ఉపయోగించాలని మేము విశ్వసిస్తున్నాము. ఈ సందర్భంలో, మీ ట్రాఫిక్ ఎక్కడ ఉందో, దానికి ఏమి జరుగుతుంది, ఎక్కడ పడిపోతుంది, దాని బలహీనతలు ఎక్కడ ఉన్నాయో మీరు ఎల్లప్పుడూ అర్థం చేసుకుంటారు. ఉదాహరణకు, ఏదైనా వచ్చి మీ సేవను క్రాష్ చేస్తే, మీరు దాని గురించి మేనేజర్ నుండి కాల్ సమయంలో కాకుండా హెచ్చరిక నుండి నేర్చుకుంటారు మరియు మీరు వెంటనే తాజా లాగ్‌లను తెరిచి అక్కడ ఏమి జరిగిందో చూడవచ్చు.
4. అధిక పనితీరు. మా ప్రాజెక్ట్ నిరంతరం పెరుగుతోంది మరియు నేడు ఇది నిమిషానికి 2 మెట్రిక్ విలువలను ప్రాసెస్ చేస్తుంది. ఒక సంవత్సరం క్రితం, ఈ సంఖ్య 000. మరియు పెరుగుదల కొనసాగుతుంది మరియు దీని అర్థం కొంత సమయం తర్వాత గ్రాఫైట్ (విష్పర్) డిస్క్ సబ్‌సిస్టమ్‌ను భారీగా లోడ్ చేయడం ప్రారంభిస్తుంది. నేను ఇప్పటికే చెప్పినట్లుగా, భాగాల పరస్పర మార్పిడి కారణంగా ఈ పర్యవేక్షణ వ్యవస్థ చాలా సార్వత్రికమైనది. ఎవరైనా గ్రాఫైట్ కోసం ప్రత్యేకంగా తమ మౌలిక సదుపాయాలను నిర్వహిస్తారు మరియు నిరంతరం విస్తరింపజేస్తున్నారు, కానీ మేము వేరే మార్గంలో వెళ్లాలని నిర్ణయించుకున్నాము: ఉపయోగించండి క్లిక్హౌస్ మా కొలమానాలకు రిపోజిటరీగా. ఈ పరివర్తన దాదాపు పూర్తయింది మరియు ఇది ఎలా జరిగిందో త్వరలో నేను మీకు మరింత వివరంగా చెబుతాను: ఏ ఇబ్బందులు ఉన్నాయి మరియు అవి ఎలా అధిగమించబడ్డాయి, వలస ప్రక్రియ ఎలా సాగింది, బైండింగ్‌గా ఎంచుకున్న భాగాలు మరియు వాటి కాన్ఫిగరేషన్‌లను నేను వివరిస్తాను.

మీరు ఆసక్తి చూపినందుకు ధన్యవాదములు! అంశంపై మీ ప్రశ్నలను అడగండి, నేను ఇక్కడ లేదా క్రింది పోస్ట్‌లలో సమాధానం ఇవ్వడానికి ప్రయత్నిస్తాను. బహుశా ఎవరైనా ఇలాంటి మానిటరింగ్ సిస్టమ్‌ను నిర్మించడం లేదా ఇలాంటి పరిస్థితిలో క్లిక్‌హౌస్‌కి మారడం వంటి అనుభవం కలిగి ఉండవచ్చు - దీన్ని వ్యాఖ్యలలో భాగస్వామ్యం చేయండి.

మూలం: www.habr.com