నా పేరు అంటోన్ బాడెరిన్. నేను హై టెక్నాలజీ సెంటర్‌లో పని చేస్తున్నాను మరియు సిస్టమ్ అడ్మినిస్ట్రేషన్ చేస్తాను. ఒక నెల క్రితం, మా కార్పొరేట్ కాన్ఫరెన్స్ ముగిసింది, ఇక్కడ మేము మా నగరం యొక్క IT సంఘంతో మా పేరుకుపోయిన అనుభవాన్ని పంచుకున్నాము. నేను వెబ్ అప్లికేషన్‌లను పర్యవేక్షించడం గురించి మాట్లాడాను. మెటీరియల్ జూనియర్ లేదా మధ్య స్థాయి కోసం ఉద్దేశించబడింది, వారు ఈ ప్రక్రియను మొదటి నుండి నిర్మించలేదు.
ఏదైనా పర్యవేక్షణ వ్యవస్థలో మూలస్తంభం వ్యాపార సమస్యలను పరిష్కరించడం. పర్యవేక్షణ కోసం పర్యవేక్షణ ఎవరికీ ఆసక్తి లేదు. వ్యాపారానికి ఏమి కావాలి? తద్వారా ప్రతిదీ త్వరగా మరియు లోపాలు లేకుండా పనిచేస్తుంది. వ్యాపారాలు చురుగ్గా ఉండాలని కోరుకుంటున్నాము, తద్వారా సేవలోని సమస్యలను మనమే గుర్తించి, వీలైనంత త్వరగా వాటిని పరిష్కరించాలి. వాస్తవానికి, మా కస్టమర్‌లలో ఒకరి కోసం ప్రాజెక్ట్‌లో నేను గత సంవత్సరం పరిష్కరించిన సమస్యలు ఇవి.
ప్రాజెక్ట్ గురించి
ఈ ప్రాజెక్ట్ దేశంలోనే అతిపెద్ద లాయల్టీ ప్రోగ్రామ్‌లలో ఒకటి. బోనస్ కార్డ్‌ల వంటి వివిధ మార్కెటింగ్ సాధనాల ద్వారా విక్రయాల ఫ్రీక్వెన్సీని పెంచుకోవడానికి మేము రిటైల్ చెయిన్‌లకు సహాయం చేస్తాము. మొత్తంగా, ప్రాజెక్ట్‌లో పది సర్వర్‌లపై పనిచేసే 14 అప్లికేషన్‌లు ఉన్నాయి.
ఇంటర్వ్యూ ప్రక్రియలో, నిర్వాహకులు ఎల్లప్పుడూ వెబ్ అప్లికేషన్‌లను సరిగ్గా పర్యవేక్షించరని నేను పదే పదే గమనించాను: చాలా మంది ఇప్పటికీ ఆపరేటింగ్ సిస్టమ్ మెట్రిక్‌లపై దృష్టి పెడతారు మరియు అప్పుడప్పుడు సేవలను పర్యవేక్షిస్తారు.
నా విషయంలో, కస్టమర్ యొక్క పర్యవేక్షణ వ్యవస్థ గతంలో ఐసింగాపై ఆధారపడి ఉండేది. ఇది పై సమస్యలను ఏ విధంగానూ పరిష్కరించలేదు. తరచుగా క్లయింట్ స్వయంగా సమస్యల గురించి మాకు తెలియజేసారు మరియు చాలా తరచుగా, కారణం యొక్క దిగువకు వెళ్లడానికి మా వద్ద తగినంత డేటా లేదు.
అదనంగా, దాని తదుపరి అభివృద్ధి యొక్క వ్యర్థం గురించి స్పష్టమైన అవగాహన ఉంది. ఐసింగతో పరిచయం ఉన్నవారు నన్ను అర్థం చేసుకుంటారని నేను భావిస్తున్నాను. కాబట్టి, మేము ప్రాజెక్ట్ కోసం వెబ్ అప్లికేషన్ మానిటరింగ్ సిస్టమ్‌ను పూర్తిగా రీడిజైన్ చేయాలని నిర్ణయించుకున్నాము.
ప్రోమేతియస్
మేము మూడు ప్రధాన సూచికల ఆధారంగా ప్రోమేతియస్‌ని ఎంచుకున్నాము:
- భారీ సంఖ్యలో అందుబాటులో ఉన్న కొలమానాలు. మా విషయంలో 60 వేల మంది ఉన్నారు. వాస్తవానికి, మేము వాటిలో ఎక్కువ భాగం (బహుశా దాదాపు 95%) ఉపయోగించకపోవడం గమనించదగ్గ విషయం. మరోవైపు, అవన్నీ సాపేక్షంగా చౌకగా ఉంటాయి. మాకు, ఇది మునుపు ఉపయోగించిన Icingaతో పోల్చితే ఇది ఇతర తీవ్రత. అందులో, కొలమానాలను జోడించడం ఒక నిర్దిష్ట నొప్పి: ఇప్పటికే ఉన్నవి ఖరీదైనవి (ఏదైనా ప్లగ్ఇన్ యొక్క సోర్స్ కోడ్‌ను చూడండి). ఏదైనా ప్లగ్ఇన్ బాష్ లేదా పైథాన్‌లో స్క్రిప్ట్‌గా ఉంటుంది, వినియోగించే వనరుల పరంగా దీని లాంచ్ ఖరీదైనది.
- ఈ వ్యవస్థ సాపేక్షంగా తక్కువ మొత్తంలో వనరులను వినియోగిస్తుంది. 600 MB RAM, 15% ఒక కోర్ మరియు రెండు డజన్ల IOPSలు మా అన్ని కొలమానాలకు సరిపోతాయి. అయితే, మీరు కొలమానాల ఎగుమతిదారులను అమలు చేయాలి, కానీ అవన్నీ గోలో వ్రాయబడ్డాయి మరియు చాలా శక్తి ఆకలితో ఉండవు. ఆధునిక వాస్తవాలలో ఇది ఒక సమస్య అని నేను అనుకోను.
- కుబెర్నెట్‌లకు వలస వెళ్ళే సామర్థ్యాన్ని అందిస్తుంది. కస్టమర్ యొక్క ప్రణాళికలను పరిశీలిస్తే, ఎంపిక స్పష్టంగా ఉంటుంది.
ELK
ఇంతకు ముందు, మేము లాగ్లను సేకరించలేదు లేదా ప్రాసెస్ చేయలేదు. లోపాలు అందరికీ స్పష్టంగా కనిపిస్తాయి. ఈ సిస్టమ్‌తో మాకు ఇప్పటికే అనుభవం ఉన్నందున మేము ELKని ఎంచుకున్నాము. మేము అక్కడ అప్లికేషన్ లాగ్లను మాత్రమే నిల్వ చేస్తాము. ప్రధాన ఎంపిక ప్రమాణాలు పూర్తి-వచన శోధన మరియు దాని వేగం.
లిక్‌హౌస్
ప్రారంభంలో, ఎంపిక InfluxDBపై పడింది. మేము Nginx లాగ్లను, pg_stat_statements నుండి గణాంకాలను సేకరించి, Prometheus చారిత్రక డేటాను నిల్వ చేయవలసిన అవసరాన్ని గ్రహించాము. మేము ఇన్‌ఫ్లక్స్‌ని ఇష్టపడలేదు ఎందుకంటే ఇది క్రమానుగతంగా పెద్ద మొత్తంలో మెమరీని వినియోగించడం ప్రారంభించి క్రాష్ అవుతుంది. అదనంగా, నేను remote_addr ద్వారా ప్రశ్నలను సమూహపరచాలనుకుంటున్నాను, అయితే ఈ DBMSలో గ్రూపింగ్ అనేది ట్యాగ్‌ల ద్వారా మాత్రమే. ట్యాగ్‌లు ఖరీదైనవి (మెమరీ), వాటి సంఖ్య షరతులతో పరిమితం చేయబడింది.
మేము మళ్ళీ శోధన ప్రారంభించాము. డిస్క్‌లో డేటా కంప్రెషన్‌తో పాటు కనీస వనరుల వినియోగంతో కూడిన విశ్లేషణాత్మక డేటాబేస్ అవసరం.
Clickhouse ఈ ప్రమాణాలన్నింటికి అనుగుణంగా ఉంటుంది మరియు మా ఎంపికపై మేము ఎప్పుడూ చింతించలేదు. మేము దానిలో అసాధారణమైన డేటాను వ్రాయము (ఇన్సర్షన్ల సంఖ్య నిమిషానికి ఐదు వేలు మాత్రమే).
న్యూరెలిక్
NewRelic చారిత్రాత్మకంగా మాతో ఉంది ఎందుకంటే ఇది కస్టమర్ యొక్క ఎంపిక. మేము దానిని APMగా ఉపయోగిస్తాము.
Zabbix
మేము వివిధ APIల బ్లాక్ బాక్స్‌ను పర్యవేక్షించడానికి ప్రత్యేకంగా Zabbixని ఉపయోగిస్తాము.
పర్యవేక్షణ విధానాన్ని నిర్వచించడం
మేము విధిని విచ్ఛిన్నం చేయాలని మరియు తద్వారా పర్యవేక్షణ విధానాన్ని క్రమబద్ధీకరించాలని కోరుకున్నాము.
దీన్ని చేయడానికి, నేను మా సిస్టమ్‌ను క్రింది స్థాయిలుగా విభజించాను:
- హార్డ్వేర్ మరియు VMS;
- ఆపరేటింగ్ సిస్టమ్;
- సిస్టమ్ సేవలు, సాఫ్ట్‌వేర్ స్టాక్;
- అప్లికేషన్;
- వ్యాపార తర్కం.
ఈ విధానం ఎందుకు సౌకర్యవంతంగా ఉంటుంది:
- ప్రతి స్థాయి పనికి ఎవరు బాధ్యత వహిస్తారో మాకు తెలుసు మరియు దీని ఆధారంగా మేము హెచ్చరికలను పంపవచ్చు;
- హెచ్చరికలను అణిచివేసేటప్పుడు మేము నిర్మాణాన్ని ఉపయోగించవచ్చు - వర్చువల్ మెషీన్ మొత్తం అందుబాటులో లేనప్పుడు డేటాబేస్ లభ్యత గురించి హెచ్చరికను పంపడం వింతగా ఉంటుంది.
సిస్టమ్ యొక్క ఆపరేషన్‌లో ఉల్లంఘనలను గుర్తించడం మా పని కాబట్టి, మేము ప్రతి స్థాయిలో హెచ్చరిక నియమాలను వ్రాసేటప్పుడు శ్రద్ధ వహించాల్సిన నిర్దిష్ట కొలమానాలను హైలైట్ చేయాలి. తరువాత, "VMS", "ఆపరేటింగ్ సిస్టమ్" మరియు "సిస్టమ్ సేవలు, సాఫ్ట్‌వేర్ స్టాక్" స్థాయిల ద్వారా వెళ్దాం.
వర్చువల్ యంత్రాలు
హోస్టింగ్ మాకు ప్రాసెసర్, డిస్క్, మెమరీ మరియు నెట్‌వర్క్‌ను కేటాయిస్తుంది. మరియు మేము మొదటి రెండింటితో సమస్యలను ఎదుర్కొన్నాము. కాబట్టి, కొలమానాలు:
CPU దొంగిలించబడిన సమయం - మీరు అమెజాన్‌లో వర్చువల్ మెషీన్‌ను కొనుగోలు చేసినప్పుడు (t2.micro, ఉదాహరణకు), మీకు మొత్తం ప్రాసెసర్ కోర్ కేటాయించబడలేదని మీరు అర్థం చేసుకోవాలి, కానీ దాని సమయం యొక్క కోటా మాత్రమే. మరియు మీరు దానిని అయిపోయినప్పుడు, ప్రాసెసర్ మీ నుండి తీసివేయబడుతుంది.
ఈ మెట్రిక్ అటువంటి క్షణాలను ట్రాక్ చేయడానికి మరియు నిర్ణయాలు తీసుకోవడానికి మిమ్మల్ని అనుమతిస్తుంది. ఉదాహరణకు, ఫటర్ టారిఫ్ తీసుకోవడం లేదా బ్యాక్‌గ్రౌండ్ టాస్క్‌లు మరియు API అభ్యర్థనల ప్రాసెసింగ్‌ను వివిధ సర్వర్‌లకు పంపిణీ చేయడం అవసరమా?
IOPS + CPU iowait సమయం - కొన్ని కారణాల వల్ల, చాలా క్లౌడ్ హోస్టింగ్‌లు తగినంత IOPSని అందించకపోవడం ద్వారా పాపం చేస్తాయి. అంతేకాకుండా, తక్కువ IOPS ఉన్న షెడ్యూల్ వారికి వాదన కాదు. అందువల్ల, CPU iowaitని సేకరించడం విలువైనది. ఈ జత గ్రాఫ్‌లతో - తక్కువ IOPS మరియు అధిక I/O నిరీక్షణతో - మీరు ఇప్పటికే హోస్టింగ్‌తో మాట్లాడి సమస్యను పరిష్కరించవచ్చు.
ఆపరేటింగ్ సిస్టమ్
ఆపరేటింగ్ సిస్టమ్ మెట్రిక్స్:
- %లో అందుబాటులో ఉన్న మెమరీ మొత్తం;
- స్వాప్ వినియోగ కార్యాచరణ: vmstat స్వాపిన్, స్వాప్ అవుట్;
- అందుబాటులో ఉన్న ఐనోడ్‌ల సంఖ్య మరియు ఫైల్ సిస్టమ్‌లో ఖాళీ స్థలం %లో
- సగటు లోడ్;
- tw రాష్ట్రంలో కనెక్షన్ల సంఖ్య;
- కాంట్రాక్ టేబుల్ సంపూర్ణత;
- నెట్‌వర్క్ నాణ్యతను ss యుటిలిటీ, iproute2 ప్యాకేజీని ఉపయోగించి పర్యవేక్షించవచ్చు - దాని అవుట్‌పుట్ నుండి RTT కనెక్షన్ల సూచికను పొందండి మరియు దానిని డెస్ట్ పోర్ట్ ద్వారా సమూహం చేయండి.
ఆపరేటింగ్ సిస్టమ్ స్థాయిలో కూడా మనకు ప్రాసెస్‌ల వంటి ఎంటిటీ ఉంది. సిస్టమ్‌లో దాని ఆపరేషన్‌లో ముఖ్యమైన పాత్ర పోషిస్తున్న ప్రక్రియల సమితిని గుర్తించడం చాలా ముఖ్యం. ఉదాహరణకు, మీరు అనేక pgpools కలిగి ఉంటే, మీరు వాటిలో ప్రతిదాని కోసం సమాచారాన్ని సేకరించాలి.
కొలమానాల సమితి క్రింది విధంగా ఉంది:
- CPUలు;
- మెమరీ ప్రధానంగా నివాసి;
- IO - ప్రాధాన్యంగా IOPSలో;
- FileFd - ఓపెన్ మరియు పరిమితి;
- ముఖ్యమైన పేజీ వైఫల్యాలు - ఈ విధంగా మీరు ఏ ప్రక్రియ మార్పిడి చేయబడుతుందో అర్థం చేసుకోవచ్చు.
మేము డాకర్‌లో అన్ని మానిటరింగ్‌లను అమలు చేస్తాము మరియు కొలమానాల డేటాను సేకరించడానికి మేము సలహాదారుని ఉపయోగిస్తాము. ఇతర యంత్రాలపై మేము ప్రాసెస్-ఎగుమతిదారుని ఉపయోగిస్తాము.
సిస్టమ్ సేవలు, సాఫ్ట్‌వేర్ స్టాక్
ప్రతి అప్లికేషన్ దాని స్వంత ప్రత్యేకతలను కలిగి ఉంటుంది మరియు నిర్దిష్టమైన కొలమానాలను గుర్తించడం కష్టం.
సార్వత్రిక సెట్:
- అభ్యర్థన రేటు;
- తప్పుల సంఖ్య;
- జాప్యం;
- సంతృప్తత.
ఈ స్థాయిలో మానిటరింగ్ యొక్క మా అత్యంత అద్భుతమైన ఉదాహరణలు Nginx మరియు PostgreSQL.
మా సిస్టమ్‌లో అత్యధికంగా లోడ్ చేయబడిన సేవ డేటాబేస్. గతంలో, డేటాబేస్ ఏమి చేస్తుందో గుర్తించడంలో మేము తరచుగా సమస్యను ఎదుర్కొంటాము.
మేము డిస్క్‌లలో అధిక లోడ్‌ని చూశాము, కానీ నెమ్మదిగా లాగ్‌లు నిజంగా ఏమీ చూపించలేదు. ప్రశ్న గణాంకాలను సేకరించే వీక్షణ అయిన pg_stat_statementsని ఉపయోగించి మేము ఈ సమస్యను పరిష్కరించాము.
అడ్మిన్‌కి కావాల్సింది అంతే.
మేము అభ్యర్థనలను చదవడం మరియు వ్రాయడం యొక్క కార్యాచరణ యొక్క గ్రాఫ్‌లను రూపొందిస్తాము:
ప్రతిదీ సరళమైనది మరియు స్పష్టంగా ఉంది, ప్రతి అభ్యర్థనకు దాని స్వంత రంగు ఉంటుంది.
సమానంగా అద్భుతమైన ఉదాహరణ Nginx లాగ్‌లు. కొంతమంది వ్యక్తులు వాటిని అన్వయించడం లేదా తప్పనిసరిగా కలిగి ఉండవలసిన జాబితాలో వాటిని పేర్కొనడంలో ఆశ్చర్యం లేదు. ప్రామాణిక ఆకృతి చాలా సమాచారంగా లేదు మరియు విస్తరించాల్సిన అవసరం ఉంది.
వ్యక్తిగతంగా, నేను request_time, upstream_response_time, body_bytes_sent, request_length, request_idని జోడించాను. మేము ప్రతిస్పందన సమయం మరియు లోపాల సంఖ్యను ప్లాట్ చేస్తాము:
మేము ప్రతిస్పందన సమయం మరియు లోపాల సంఖ్య యొక్క గ్రాఫ్‌లను రూపొందిస్తాము. గుర్తుందా? నేను వ్యాపార పనుల గురించి మాట్లాడానా? త్వరగా మరియు లోపాలు లేకుండా? మేము ఇప్పటికే ఈ సమస్యలను రెండు చార్ట్‌లతో కవర్ చేసాము. మరియు మీరు ఇప్పటికే విధుల్లో ఉన్న నిర్వాహకులను వాటిని ఉపయోగించి కాల్ చేయవచ్చు.
కానీ మరొక సమస్య మిగిలి ఉంది - సంఘటన యొక్క కారణాలను వేగంగా తొలగించడాన్ని నిర్ధారించడానికి.
సంఘటన పరిష్కారం
సమస్యను గుర్తించడం నుండి పరిష్కరించడం వరకు మొత్తం ప్రక్రియను అనేక దశలుగా విభజించవచ్చు:
- సమస్యను గుర్తించడం;
- విధి నిర్వాహకుడికి నోటిఫికేషన్;
- ఒక సంఘటనకు ప్రతిస్పందన;
- కారణాల తొలగింపు.
మనం దీన్ని వీలైనంత త్వరగా చేయడం ముఖ్యం. మరియు సమస్యను గుర్తించడం మరియు నోటిఫికేషన్ పంపడం వంటి దశల్లో మనం ఎక్కువ సమయం పొందలేకపోతే - ఏ సందర్భంలోనైనా వాటి కోసం రెండు నిమిషాలు వెచ్చించబడతాయి, ఆపై తదుపరి వాటిని మెరుగుదలల కోసం అన్‌ప్లోడ్ ఫీల్డ్‌గా ఉంటుంది.
డ్యూటీ ఆఫీసర్ ఫోన్ మోగినట్లు ఊహించుకుందాం. ఏం చేస్తాడు? ప్రశ్నలకు సమాధానాల కోసం చూడండి - ఏది విరిగింది, ఎక్కడ విరిగింది, ఎలా స్పందించాలి? మేము ఈ ప్రశ్నలకు ఎలా సమాధానమిస్తాము:
మేము నోటిఫికేషన్ యొక్క టెక్స్ట్‌లో ఈ మొత్తం సమాచారాన్ని చేర్చుతాము, ఈ సమస్యకు ఎలా స్పందించాలో, దాన్ని ఎలా పరిష్కరించాలో మరియు దాన్ని ఎలా పెంచాలో వివరించే వికీ పేజీకి లింక్‌ను ఇస్తాము.
అప్లికేషన్ లేయర్ మరియు బిజినెస్ లాజిక్ గురించి నేను ఇంకా ఏమీ చెప్పలేదు. దురదృష్టవశాత్తూ, మా అప్లికేషన్‌లు ఇంకా కొలమానాల సేకరణను అమలు చేయలేదు. ఈ స్థాయిల నుండి ఏదైనా సమాచారం యొక్క ఏకైక మూలం లాగ్‌లు.
పాయింట్ల జంట.
ముందుగా, నిర్మాణాత్మక లాగ్లను వ్రాయండి. సందేశం యొక్క వచనంలో సందర్భాన్ని చేర్చవలసిన అవసరం లేదు. ఇది వాటిని సమూహపరచడం మరియు విశ్లేషించడం కష్టతరం చేస్తుంది. వీటన్నింటినీ సాధారణీకరించడానికి లాగ్‌స్టాష్ చాలా సమయం పడుతుంది.
రెండవది, తీవ్రత స్థాయిలను సరిగ్గా ఉపయోగించండి. ఒక్కో భాషకు ఒక్కో ప్రమాణం ఉంటుంది. వ్యక్తిగతంగా, నేను నాలుగు స్థాయిలను వేరు చేస్తున్నాను:
- లోపం లేదు;
- క్లయింట్ వైపు లోపం;
- తప్పు మన వైపు ఉంది, మేము డబ్బును కోల్పోము, మేము నష్టాలను భరించము;
- తప్పు మన వైపు ఉంది, మేము డబ్బు కోల్పోతాము.
నేను సంగ్రహంగా చెప్పనివ్వండి. మీరు వ్యాపార తర్కం ఆధారంగా పర్యవేక్షణను రూపొందించడానికి ప్రయత్నించాలి. అప్లికేషన్‌ను స్వయంగా పర్యవేక్షించడానికి ప్రయత్నించండి మరియు విక్రయాల సంఖ్య, కొత్త వినియోగదారు రిజిస్ట్రేషన్‌ల సంఖ్య, ప్రస్తుతం యాక్టివ్‌గా ఉన్న వినియోగదారుల సంఖ్య మొదలైన కొలమానాలతో పనిచేయడానికి ప్రయత్నించండి.
మీ మొత్తం వ్యాపారం బ్రౌజర్‌లో ఒక బటన్ అయితే, అది క్లిక్ చేసి సరిగ్గా పనిచేస్తుందో లేదో మీరు పర్యవేక్షించాలి. మిగిలినవన్నీ పట్టింపు లేదు.
మీకు ఇది లేకుంటే, మేము చేసినట్లుగా మీరు అప్లికేషన్ లాగ్‌లు, Nginx లాగ్‌లు మొదలైనవాటిలో దాన్ని తెలుసుకోవడానికి ప్రయత్నించవచ్చు. మీరు అప్లికేషన్‌కు వీలైనంత దగ్గరగా ఉండాలి.
ఆపరేటింగ్ సిస్టమ్ మెట్రిక్‌లు చాలా ముఖ్యమైనవి, కానీ వ్యాపారం వాటిపై ఆసక్తి చూపదు, వాటి కోసం మాకు చెల్లించబడదు.
మూలం: www.habr.com