என் பெயர் அன்டன் பேடரின். நான் உயர் தொழில்நுட்ப மையத்தில் பணிபுரிகிறேன் மற்றும் கணினி நிர்வாகம் செய்கிறேன். ஒரு மாதத்திற்கு முன்பு, எங்கள் நிறுவன மாநாடு முடிந்தது, அங்கு எங்கள் நகரத்தின் தகவல் தொழில்நுட்ப சமூகத்துடன் எங்கள் திரட்டப்பட்ட அனுபவத்தைப் பகிர்ந்து கொண்டோம். வலை பயன்பாடுகளை கண்காணிப்பது பற்றி பேசினேன். இந்த செயல்முறையை புதிதாக உருவாக்காத ஜூனியர் அல்லது நடுத்தர நிலைக்கு பொருள் நோக்கம் கொண்டது.
எந்தவொரு கண்காணிப்பு அமைப்பின் அடிப்படையிலும் அடிப்படையானது வணிகச் சிக்கல்களைத் தீர்ப்பதாகும். கண்காணிப்புக்காக கண்காணிப்பது யாருக்கும் ஆர்வமில்லை. வணிகத்திற்கு என்ன வேண்டும்? அதனால் எல்லாம் விரைவாகவும் பிழைகள் இல்லாமல் செயல்படும். சேவையில் உள்ள சிக்கல்களை நாமே கண்டறிந்து அவற்றை விரைவில் சரிசெய்வதற்கு வணிகங்கள் செயலூக்கத்துடன் இருக்க விரும்புகின்றன. உண்மையில், எங்கள் வாடிக்கையாளர்களில் ஒருவருக்கான திட்டத்தில் கடந்த ஆண்டு நான் தீர்த்த சிக்கல்கள் இவை.
திட்டம் பற்றி
இந்தத் திட்டம் நாட்டின் மிகப்பெரிய விசுவாசத் திட்டங்களில் ஒன்றாகும். போனஸ் கார்டுகள் போன்ற பல்வேறு சந்தைப்படுத்தல் கருவிகள் மூலம் விற்பனையின் அதிர்வெண்ணை அதிகரிக்க சில்லறை சங்கிலிகளுக்கு நாங்கள் உதவுகிறோம். மொத்தத்தில், திட்டத்தில் பத்து சேவையகங்களில் இயங்கும் 14 பயன்பாடுகள் உள்ளன.
நேர்காணல் செயல்பாட்டின் போது, நிர்வாகிகள் எப்போதும் கண்காணிப்பு வலை பயன்பாடுகளை சரியாக அணுகுவதில்லை என்பதை நான் மீண்டும் மீண்டும் கவனித்தேன்: பலர் இன்னும் இயக்க முறைமை அளவீடுகளில் கவனம் செலுத்துகிறார்கள் மற்றும் அவ்வப்போது சேவைகளை கண்காணிக்கிறார்கள்.
என் விஷயத்தில், வாடிக்கையாளரின் கண்காணிப்பு அமைப்பு முன்பு ஐசிங்காவை அடிப்படையாகக் கொண்டது. மேற்கூறிய பிரச்சனைகளை அது எந்த வகையிலும் தீர்க்கவில்லை. பெரும்பாலும் வாடிக்கையாளர் தானே சிக்கல்களைப் பற்றி எங்களுக்குத் தெரிவித்தார், மேலும் பெரும்பாலும், காரணத்தின் அடிப்பகுதியைப் பெற எங்களிடம் போதுமான தரவு இல்லை.
கூடுதலாக, அதன் மேலும் வளர்ச்சியின் பயனற்ற தன்மை பற்றிய தெளிவான புரிதல் இருந்தது. இசிங்காவைப் பற்றி நன்கு தெரிந்தவர்கள் என்னைப் புரிந்து கொள்வார்கள் என்று நினைக்கிறேன். எனவே, திட்டத்திற்கான இணைய பயன்பாட்டு கண்காணிப்பு அமைப்பை முழுமையாக மறுவடிவமைப்பு செய்ய முடிவு செய்தோம்.
பிரமீதீயஸ்
மூன்று முக்கிய குறிகாட்டிகளின் அடிப்படையில் நாங்கள் ப்ரோமிதியஸைத் தேர்ந்தெடுத்தோம்:
- ஏராளமான அளவீடுகள் கிடைக்கின்றன. எங்கள் விஷயத்தில், அவர்களில் 60 ஆயிரம் பேர் உள்ளனர். நிச்சயமாக, அவற்றில் பெரும்பாலானவை (அநேகமாக 95%) நாங்கள் பயன்படுத்துவதில்லை என்பது குறிப்பிடத்தக்கது. மறுபுறம், அவை அனைத்தும் ஒப்பீட்டளவில் மலிவானவை. எங்களைப் பொறுத்தவரை, இது முன்பு பயன்படுத்தப்பட்ட Icinga உடன் ஒப்பிடும்போது மற்றொரு தீவிரம். அதில், அளவீடுகளைச் சேர்ப்பது ஒரு குறிப்பிட்ட வலி: ஏற்கனவே உள்ளவை விலை உயர்ந்தவை (எந்தவொரு செருகுநிரலின் மூலக் குறியீட்டைப் பாருங்கள்). எந்தவொரு செருகுநிரலும் பாஷ் அல்லது பைத்தானில் ஒரு ஸ்கிரிப்டாக இருந்தது, அதன் வெளியீடு நுகரப்படும் வளங்களின் அடிப்படையில் விலை உயர்ந்தது.
- இந்த அமைப்பு ஒப்பீட்டளவில் சிறிய அளவிலான வளங்களை பயன்படுத்துகிறது. 600 MB ரேம், 15% ஒரு கோர் மற்றும் இரண்டு டஜன் IOPS ஆகியவை எங்கள் எல்லா அளவீடுகளுக்கும் போதுமானது. நிச்சயமாக, நீங்கள் அளவீடுகள் ஏற்றுமதியாளர்களை இயக்க வேண்டும், ஆனால் அவை அனைத்தும் Go இல் எழுதப்பட்டுள்ளன, மேலும் அவை அதிக சக்திக்கு பசியற்றவை. நவீன யதார்த்தங்களில் இது ஒரு பிரச்சனை என்று நான் நினைக்கவில்லை.
- குபெர்னெட்டஸுக்கு இடம்பெயர்வதற்கான திறனை வழங்குகிறது. வாடிக்கையாளரின் திட்டங்களைக் கருத்தில் கொண்டு, தேர்வு தெளிவாக உள்ளது.
ELK
முன்பு, நாங்கள் பதிவுகளை சேகரிக்கவோ அல்லது செயலாக்கவோ இல்லை. குறைபாடுகள் அனைவருக்கும் தெளிவாக உள்ளன. இந்த அமைப்பில் எங்களுக்கு ஏற்கனவே அனுபவம் இருந்ததால் ELKஐத் தேர்ந்தெடுத்தோம். நாங்கள் அங்கு விண்ணப்பப் பதிவுகளை மட்டுமே சேமித்து வைக்கிறோம். முக்கிய தேர்வு அளவுகோல் முழு உரை தேடல் மற்றும் அதன் வேகம்.
க்ளிக்ஹவுஸ்
ஆரம்பத்தில், தேர்வு InfluxDB இல் விழுந்தது. Nginx பதிவுகள், pg_stat_statements இலிருந்து புள்ளிவிவரங்கள் மற்றும் Prometheus வரலாற்றுத் தரவைச் சேமிப்பதன் அவசியத்தை நாங்கள் உணர்ந்தோம். எங்களுக்கு இன்ஃப்ளக்ஸ் பிடிக்கவில்லை, ஏனெனில் அது அவ்வப்போது அதிக அளவு நினைவகத்தை உட்கொள்ளத் தொடங்கியது மற்றும் செயலிழந்தது. கூடுதலாக, நான் remote_addr மூலம் வினவல்களைக் குழுவாக்க விரும்பினேன், ஆனால் இந்த DBMS இல் குறிச்சொற்கள் மூலம் மட்டுமே குழுவாக்கப்படும். குறிச்சொற்கள் விலை உயர்ந்தவை (நினைவகம்), அவற்றின் எண்ணிக்கை நிபந்தனைக்குட்பட்டது.
மீண்டும் தேடலை ஆரம்பித்தோம். தேவையானது குறைந்தபட்ச ஆதார நுகர்வு கொண்ட ஒரு பகுப்பாய்வு தரவுத்தளமாகும், முன்னுரிமை வட்டில் தரவு சுருக்கத்துடன்.
கிளிக்ஹவுஸ் இந்த அனைத்து நிபந்தனைகளையும் பூர்த்தி செய்கிறது, மேலும் எங்கள் தேர்வுக்கு நாங்கள் ஒருபோதும் வருத்தப்படவில்லை. நாங்கள் அதில் எந்த அசாதாரணமான தரவையும் எழுதவில்லை (செருகுகளின் எண்ணிக்கை நிமிடத்திற்கு ஐந்தாயிரம் மட்டுமே).
நியூரெலிக்
NewRelic வரலாற்று ரீதியாக எங்களுடன் இருந்து வருகிறது, ஏனெனில் அது வாடிக்கையாளரின் விருப்பமாக இருந்தது. நாங்கள் அதை APM ஆகப் பயன்படுத்துகிறோம்.
Zabbix
பல்வேறு APIகளின் பிளாக் பாக்ஸைக் கண்காணிக்க நாங்கள் பிரத்தியேகமாக Zabbix ஐப் பயன்படுத்துகிறோம்.
ஒரு கண்காணிப்பு அணுகுமுறையை வரையறுத்தல்
பணியை சிதைத்து அதன் மூலம் கண்காணிப்பதற்கான அணுகுமுறையை முறைப்படுத்த விரும்பினோம்.
இதைச் செய்ய, எங்கள் கணினியை பின்வரும் நிலைகளாகப் பிரித்தேன்:
- வன்பொருள் மற்றும் VMS;
- இயக்க முறைமை;
- கணினி சேவைகள், மென்பொருள் அடுக்கு;
- விண்ணப்பம்;
- வணிக தர்க்கம்.
இந்த அணுகுமுறை ஏன் வசதியானது:
- ஒவ்வொரு மட்டத்தின் பணிக்கும் யார் பொறுப்பு என்பதை நாங்கள் அறிவோம், இதன் அடிப்படையில், நாங்கள் விழிப்பூட்டல்களை அனுப்பலாம்;
- விழிப்பூட்டல்களை அடக்கும்போது நாம் கட்டமைப்பைப் பயன்படுத்தலாம் - ஒட்டுமொத்தமாக மெய்நிகர் இயந்திரம் கிடைக்காதபோது தரவுத்தள கிடைக்காதது பற்றிய எச்சரிக்கையை அனுப்புவது விசித்திரமாக இருக்கும்.
அமைப்பின் செயல்பாட்டில் உள்ள மீறல்களைக் கண்டறிவதே எங்கள் பணி என்பதால், ஒவ்வொரு மட்டத்திலும் எச்சரிக்கை விதிகளை எழுதும்போது கவனம் செலுத்த வேண்டிய ஒரு குறிப்பிட்ட அளவீடுகளை முன்னிலைப்படுத்த வேண்டும். அடுத்து, "விஎம்எஸ்", "ஆப்பரேட்டிங் சிஸ்டம்" மற்றும் "சிஸ்டம் சர்வீசஸ், சாஃப்ட்வேர் ஸ்டேக்" ஆகிய நிலைகளுக்கு செல்லலாம்.
மெய்நிகர் இயந்திரங்கள்
ஹோஸ்டிங் நமக்கு ஒரு செயலி, வட்டு, நினைவகம் மற்றும் நெட்வொர்க்கை ஒதுக்குகிறது. முதல் இரண்டிலும் எங்களுக்கு சிக்கல்கள் இருந்தன. எனவே, அளவீடுகள்:
CPU திருடப்பட்ட நேரம் - நீங்கள் Amazon இல் ஒரு மெய்நிகர் இயந்திரத்தை வாங்கும்போது (உதாரணமாக, t2.micro), உங்களுக்கு முழு செயலி மையமும் ஒதுக்கப்படவில்லை, ஆனால் அதன் நேரத்தின் ஒதுக்கீடு மட்டுமே என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். நீங்கள் அதை தீர்ந்துவிட்டால், செயலி உங்களிடமிருந்து பறிக்கப்படும்.
இந்த மெட்ரிக் அத்தகைய தருணங்களைக் கண்காணிக்கவும் முடிவுகளை எடுக்கவும் உங்களை அனுமதிக்கிறது. எடுத்துக்காட்டாக, அதிக கட்டணத்தை எடுக்க வேண்டுமா அல்லது பின்னணி பணிகள் மற்றும் API கோரிக்கைகளின் செயலாக்கத்தை வெவ்வேறு சேவையகங்களுக்கு விநியோகிப்பது அவசியமா?
IOPS + CPU iowait நேரம் - சில காரணங்களால், பல கிளவுட் ஹோஸ்டிங்கள் போதுமான IOPS ஐ வழங்காமல் பாவம் செய்கின்றன. மேலும், குறைந்த IOPS கொண்ட அட்டவணை அவர்களுக்கு ஒரு வாதம் அல்ல. எனவே, CPU iowait ஐ சேகரிப்பது மதிப்பு. இந்த ஜோடி வரைபடங்களுடன் - குறைந்த IOPS மற்றும் அதிக I/O காத்திருப்புடன் - நீங்கள் ஏற்கனவே ஹோஸ்டிங்குடன் பேசி சிக்கலைத் தீர்க்கலாம்.
இயங்கு
இயக்க முறைமை அளவீடுகள்:
- % இல் கிடைக்கும் நினைவகத்தின் அளவு;
- இடமாற்று பயன்பாட்டு செயல்பாடு: vmstat swapin, swapout;
- % இல் கோப்பு முறைமையில் கிடைக்கும் ஐனோட்களின் எண்ணிக்கை மற்றும் இலவச இடம்
- சராசரி சுமை;
- இரண்டு நிலையில் உள்ள இணைப்புகளின் எண்ணிக்கை;
- கான்ட்ராக் அட்டவணை முழுமை;
- நெட்வொர்க்கின் தரத்தை ss பயன்பாடு, iproute2 தொகுப்பைப் பயன்படுத்தி கண்காணிக்க முடியும் - அதன் வெளியீட்டில் இருந்து RTT இணைப்புகளின் குறிகாட்டியைப் பெற்று டெஸ்ட் போர்ட் மூலம் குழுவாக்கவும்.
இயக்க முறைமை மட்டத்தில், செயல்முறைகள் போன்ற ஒரு நிறுவனம் உள்ளது. கணினியில் அதன் செயல்பாட்டில் முக்கிய பங்கு வகிக்கும் செயல்முறைகளின் தொகுப்பை அடையாளம் காண்பது முக்கியம். உதாரணமாக, உங்களிடம் பல பிஜிபூல்கள் இருந்தால், அவை ஒவ்வொன்றின் தகவலையும் நீங்கள் சேகரிக்க வேண்டும்.
அளவீடுகளின் தொகுப்பு பின்வருமாறு:
- 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